第2章：架构演进之路：从单体到SOA再到微服务、服务拆分原则、康威定律
大家好，我是你们的老朋友。今天咱们聊聊架构的演进史。
说实话，我见过太多团队一上来就搞微服务，结果把自己搞崩了。为什么？因为没搞懂架构为什么要演进。你想想看，如果连单体都没玩明白，直接上微服务，那不是找死吗？
2.1 单体架构：那个“一个包打天下”的年代
先说说单体架构。说白了，就是把所有功能都塞进一个进程里。我记得2010年我刚入行时，做的第一个项目就是典型的单体应用——一个电商网站，订单、用户、商品、支付，全在一个WAR包里。
单体架构的好处很明显：
- 开发简单：一个IDE，一个项目，搞定
- 部署方便：打个包扔到Tomcat里就行
- 测试容易：启动一次，所有功能都能测
- 调用开销小：方法调用，没有网络开销
但问题也来了。我在项目中遇到过这样一个场景：团队从5个人扩张到50个人，代码库从10万行膨胀到200万行。这时候，单体架构的痛点就暴露无遗了。
- 代码耦合严重，改一行代码可能影响整个系统
- 构建时间越来越长，从30秒变成30分钟
- 无法独立扩展，流量大了只能整体扩容
- 技术栈锁定，想换语言？重写吧
嗯，这里要注意。不是说单体架构就不好。对于小团队、小项目，单体反而是最优解。我见过太多人为了“微服务而微服务”，结果把简单问题复杂化了。
2.2 SOA架构：服务化的第一次尝试
后来大家发现，单体不行，得拆。于是SOA（面向服务架构）就来了。
SOA的核心思想是什么？就是把系统拆成多个服务，每个服务提供特定的业务能力。服务之间通过ESB（企业服务总线）通信。
我2013年参与过一个SOA改造项目。当时我们用了Oracle的SOA套件，那叫一个重啊。每个服务都要注册到ESB上，服务调用要经过ESB路由、转换、编排。你想想看，一个简单的查询请求，要经过三层转发，性能能好吗？
| 对比维度 | 单体架构 | SOA架构 |
|---|---|---|
| 服务粒度 | 无 | 粗粒度（业务模块） |
| 通信方式 | 方法调用 | ESB/WebService |
| 数据存储 | 单库 | 多库（但常共享） |
| 部署方式 | 单进程 | 多进程 |
| 治理能力 | 无 | 有（ESB） |
SOA的问题在哪？我个人觉得，ESB成了新的单点瓶颈。而且服务拆分粒度太粗，本质上还是“大泥球”的变种。我曾经见过一个SOA项目，一个“订单服务”里包含了订单创建、支付、物流、售后……这不就是换个名字的单体吗？
2.3 微服务架构：终于找到了正确的打开方式
2014年，Martin Fowler和James Lewis提出了微服务架构。说白了，就是把SOA的“粗粒度”变成“细粒度”，把“重量级”变成“轻量级”。
微服务的核心特征：
- 单一职责：每个服务只做一件事，并且做好
- 独立部署：每个服务可以独立发布、升级、回滚
- 去中心化：没有ESB，服务之间直接通信（HTTP/RPC）
- 技术多样性：不同服务可以用不同语言、不同数据库
我2016年开始做微服务改造。当时我们有个核心系统，拆成了30多个微服务。说实话，刚开始那半年，我每天都在踩坑。服务发现、配置管理、链路追踪、熔断降级……每个都是新问题。
2.4 服务拆分原则：怎么拆才不翻车？
好，现在你决定要拆了。那怎么拆？我总结了几个原则：
2.4.1 业务领域驱动
这是最核心的原则。说白了，就是按业务边界来拆。比如电商系统，可以拆成：用户服务、商品服务、订单服务、支付服务、库存服务。
我在项目中遇到过最典型的反面案例：有人按“功能”来拆，把“用户登录”拆成一个服务，“用户注册”拆成一个服务，“用户信息修改”又拆成一个服务。结果呢？一个用户操作要调3个服务，数据一致性根本没法保证。
2.4.2 闭包原则
一个服务内部的变化，不应该影响其他服务。比如订单服务改了内部逻辑，只要接口不变，其他服务就不需要改。
2.4.3 数据独立原则
每个服务要有自己的数据库。千万别共享数据库！我见过一个项目，服务拆了，但数据库还是共用的。结果一个服务的慢查询，把整个系统拖垮了。
2.4.4 服务粒度适中
拆得太粗，还是单体；拆得太细，变成“微服务地狱”。我个人习惯：一个服务应该能在两周内完成开发，并且由一个小团队（2-5人）独立维护。
2.5 康威定律：组织架构决定系统架构
聊架构，不能不提康威定律。1968年，Melvin Conway提出了一个观点：
“设计系统的组织，其产生的设计等价于组织之间的沟通结构。”
说白了，就是你的团队怎么组织，你的系统就长什么样。
我举个例子。假设你的团队是按“前端组”、“后端组”、“测试组”来划分的。那你的系统大概率会拆成“前端应用”、“后端API”、“测试环境”。但如果你的团队是按“订单组”、“支付组”、“用户组”来划分的，那你的系统就会拆成“订单服务”、“支付服务”、“用户服务”。
为什么会这样？因为团队之间的沟通成本，会直接反映在系统接口上。两个团队如果经常需要沟通，那他们负责的模块之间就会有紧密的耦合。
我记得有个经典案例：亚马逊在2002年推行微服务时，CEO Jeff Bezos下了一个命令：所有团队必须通过API通信，不允许直接访问数据库，不允许共享代码库。这个命令的本质，就是通过组织变革来推动架构演进。
2.6 总结：架构演进的核心逻辑
好了，咱们回顾一下：
- 单体架构：适合小团队、小项目，简单直接
- SOA架构：第一次服务化尝试，但ESB成了新瓶颈
- 微服务架构：细粒度、独立部署、去中心化
- 服务拆分：按业务领域、闭包、数据独立、粒度适中
- 康威定律：组织架构决定系统架构，别忽视人的因素
最后说一句：架构没有银弹。不要为了微服务而微服务，也不要因为害怕复杂度而固守单体。根据你的团队规模、业务复杂度、技术能力，选择最适合的架构。这才是架构师的智慧。
下一章，咱们聊聊微服务的核心组件：服务发现与注册中心。到时候见。