微服务架构

从单体到微服务的拆分逻辑

亚马逊 2001 年左右将单体电商系统拆分，传说 Jeff Bezos 发了一封著名的「API 授权令」：所有团队必须通过 API 暴露数据和功能，不允许直接访问他人数据库，违者开除。这次强制解耦催生了后来的 AWS。Netflix 2009-2012 年将 DVD 时代的单体系统迁移到 AWS 上的微服务架构，历时三年，是业界最详细记录的迁移案例之一。

微服务的理论依据是康威定律：系统架构与组织结构同构。100 人的单一团队跑一个大系统，和 10 个 10 人团队各自负责一个微服务，产生的系统架构截然不同。[1]

治理工具与常见陷阱

• 服务发现：Consul、Eureka 让服务动态注册、彼此找到对方
• 链路追踪：一个请求经过 8 个服务，Jaeger、Zipkin、SkyWalking 把全链路调用串联可视化
• 熔断器：Netflix Hystrix（现为 Resilience4j）在下游服务超时时快速失败，防止级联故障

常见踩坑：过早微服务化（业务不清晰就拆，拆完依赖更乱）；分布式事务（拆成多个服务后，一个业务操作横跨多个数据库，2PC/Saga 模式复杂度高）；测试困难（本地跑需要启动十几个服务）。Martin Fowler 明确说过：微服务是「复杂度的交换」，不是万能药。