一个电商系统从 0 到千万级用户的架构演进，每一次拆分都是业务和技术双重驱动的决策。

一、阶段 1：单体架构——一切的起点

  • 1.1 单体架构的形态——一个 war 包打天下
  • 1.2 优点——开发简单、部署方便、调试容易
  • 1.3 单体的瓶颈——代码膨胀、模块耦合、扩展困难
  • 1.4 单体何时开始”痛”——团队 > 20 人、模块 > 50 个

二、阶段 2：垂直拆分——按业务域分离

  • 2.1 拆分原则——按业务边界（商品/订单/用户/支付）
  • 2.2 拆分后的架构——多个独立应用
  • 2.3 带来的新问题——数据一致性、接口调用、前端聚合
  • 2.4 这个阶段的取舍

三、阶段 3：服务化改造——Dubbo/Spring Cloud

  • 3.1 服务化 vs 微服务的区别
  • 3.2 引入注册中心——Nacos / ZooKeeper
  • 3.3 RPC 调用替代 HTTP 调用
  • 3.4 服务治理——限流、熔断、降级

四、阶段 4：微服务化——更细粒度的拆分

  • 4.1 拆分到微服务级别的考虑——团队结构对应微服务
  • 4.2 数据库拆分——每个服务独立数据库
  • 4.3 分布式事务的挑战
  • 4.4 链路追踪——SkyWalking / Zipkin

五、阶段 5：云原生化——容器与编排

  • 5.1 Docker 容器化部署
  • 5.2 K8s 编排——自动扩缩容
  • 5.3 Service Mesh——Istio 的引入

六、每个阶段的决策回顾

  • 6.1 拆分的时机判断——业务复杂度、团队规模、性能瓶颈
  • 6.2 拆分的粒度把握——过粗和过细都是问题
  • 6.3 不要为了微服务而微服务

七、总结

  • 架构演进的驱动力——从来不是技术，是业务
  • 每个阶段的”痛”是下一次进化的信号