围绕微服务入门、微服务技术栈、微服务开发教程、服务治理、服务网格、API网关和微服务部署组织内容，帮助读者从架构概念逐步进入生产治理。
建议按阶段阅读：先看推荐先读，再通过延伸内容补齐本阶段知识点。
先理解微服务、单体架构、云原生架构和服务拆分边界。
学习Spring Cloud、注册中心、配置、调用、缓存、消息队列和中间件能力。
从服务拆分进入容器化、Kubernetes部署、发布流程和多服务协同。
补齐注册发现、熔断限流、链路追踪、API网关、服务网格和安全通信。
优先学习微服务拆分、技术栈、部署和服务治理。
优先关注微服务容器化部署、Kubernetes发布、运行保障、链路追踪和故障定位。
优先判断是否适合拆微服务、如何划分边界、如何规划治理平台和服务网格演进。
先理解微服务解决什么问题、什么时候不适合拆分，以及服务边界、数据一致性和团队协作成本。不要一开始只背技术栈，微服务首先是架构和组织协作问题。
可以按服务开发、注册发现、配置管理、服务调用、消息队列、缓存、网关、链路追踪和部署治理来学习。技术栈不是越多越好，关键是理解每个组件解决哪类协作或运行问题。
通常在业务边界清晰、团队协作复杂、发布节奏差异明显、单体变更风险过高时再考虑拆分。如果系统规模不大、团队很小或领域边界不清晰，过早拆分会增加部署、排障和数据一致性成本。
微服务通常需要多实例运行、服务发现、弹性扩缩容、灰度发布和故障恢复，Kubernetes正好提供这些运行时能力。但Kubernetes不能替代架构设计，服务边界和治理策略仍要先设计清楚。
服务治理是一组能力，包括注册发现、限流熔断、重试、超时、路由、观测和安全通信；服务网格是实现这些能力的一种基础设施方式，适合服务数量和治理复杂度较高的场景。
两者解决的问题不同。Spring Cloud更贴近应用开发和服务调用，Kubernetes更关注运行、调度和发布。入门时可以先理解服务拆分、接口调用和配置治理，再学习容器化部署和Kubernetes运行时。
API网关通常承担统一入口、路由转发、认证鉴权、限流、协议转换和灰度入口等职责。它不应该承载过多业务逻辑，否则会变成新的中心化瓶颈。
微服务不建议简单共享一个数据库来规避一致性问题。常见做法是按服务边界管理数据，通过事件、消息、补偿、幂等和最终一致性设计降低跨服务事务复杂度。
优先看请求入口、错误率、延迟、调用链、依赖服务、数据库和消息队列状态。微服务排障不能只看单个服务日志，需要结合链路追踪、指标监控和发布变更记录定位问题。
不会。学习路径承接微服务入门、技术栈和教程型搜索，微服务架构标签页承接具体架构概念、治理实践和问题查找，两者通过强相关内链互相支撑。