微服务架构：从拆分到运行治理¶

微服务不是“服务数量很多”，而是围绕业务能力把系统划分为可独立开发、部署、扩缩容和演进的服务。每个服务拥有清晰边界，通过网络协议协作，并对自己的运行质量和数据负责。

客户端
  → API Gateway
  → 订单服务 ──同步调用──> 库存服务
       │                    │
       └──事件──> 消息队列 ─┴──> 通知服务

注册发现 / 配置 / 身份认证 / 限流熔断
日志 / 指标 / Trace / 告警 / 发布记录

它解决什么问题¶

单体扩大后的问题	微服务可能带来的能力
每次修改都要发布整个系统	服务可独立发布和回滚
局部热点只能整体扩容	对热点服务单独扩容
团队修改互相阻塞	以业务边界划分职责
技术和数据模型难以演进	服务内部可独立演进

微服务也会引入网络故障、分布式事务、版本兼容、观测困难、环境数量增加和运维复杂度。业务规模、团队和交付能力不足时，结构清晰的模块化单体往往更合适。拆分不是目标，独立演进能力才是目标。

完整学习路径¶

顺序	章节	核心问题
1	服务边界与拆分	哪些功能属于一个服务，怎样避免分布式单体
2	服务通信与 API 网关	REST、gRPC、消息怎样选择，入口怎样治理
3	注册发现与配置治理	实例变化后怎样发现，配置怎样安全更新
4	超时、重试、熔断与限流	怎样控制故障扩散和重试风暴
5	数据一致性与消息	服务独立数据库后怎样保证业务最终正确
6	身份与安全边界	用户身份、服务身份、权限和密钥怎样管理
7	部署、可观测性与排障	怎样发布、观测和沿调用链定位故障

运维视角的核心原则¶

每个服务必须能明确回答：负责人是谁、依赖谁、SLO 是什么、怎样发布和回滚。
所有网络调用必须设置超时；重试必须有限、退避并判断幂等性。
API 和事件都要考虑版本兼容，不能假设所有服务同时发布。
日志、指标和 Trace 使用一致的 service.name、环境、版本和 Trace ID。
数据库变更、消息格式和配置变更必须兼容滚动发布。
先建立自动化交付和可观测性，再扩大服务数量。

Java 项目可使用 Spring Boot/Spring Cloud 实现部分能力，但微服务原则不依赖某一种语言或框架。容器编排参见 Kubernetes，运行观测参见可观测性。