见过两种惨痛的架构失败。一种是小团队、业务还没验证，就花几个月搭了一套「可扩展的微服务架构」，结果业务方向一变，整套架构白搭。另一种是业务已经长到几十个团队、几千万日活，还死守着一个巨大的单体，改一行代码牵连一片，发布要全组协调到半夜。
两种失败的根因是同一个，架构和业务的阶段不匹配。健康的架构不是一开始就设计完美的，它是跟着业务演进的。这篇讲这条演进路径，以及每一步该在什么信号下迈出去。
图：架构演进是状态机——单体起步，按信号（冲突、扩容、迭代差异）渐进迈步，每次拆稳了再拆下一个，绝不一次性大拆。
单体是合理的起点，不是落后的代名词
业务早期，团队就几个人，需求还在天天变，这时候单体是性价比最高的选择。
它简单、开发快、部署容易、调试方便。一个应用把所有功能打包在一起，改了什么本地跑一下就能看效果，不用搭一整套分布式基础设施。团队小、业务没定型的时候，这种快速验证的能力比什么都重要。
很多人把单体当成「落后」的架构，这是偏见。单体适不适合，取决于业务阶段和团队规模，不取决于它听起来先不先进。Twitter、Shopify 这些大厂早期都是单体起步的。
真正的问题是，单体不是终点。业务长大了，单体就会从「简单」变成「臃肿」，这时候该演进。
演进的桥梁，模块化单体
单体变臃肿的第一个信号，是多人改同一个代码库频繁冲突。这时候还不到拆服务的时候，先做模块化。
把单体内部按业务划出清晰的模块边界，订单模块、商品模块、用户模块，模块之间通过接口交互，而不是直接互相扒对方的内部实现。这一步保留了单体的简单性，又给内部加了结构。
模块化单体的价值在于，它是未来拆服务的前奏。模块边界划清楚了，将来要拆，就沿着这些边界拆。模块边界没划清，直接拆服务，只会把单体里的耦合变成分布式耦合，更难搞。
什么时候该拆服务
图：拆服务必须由明确信号驱动——协作冲突、独立扩容、迭代频率差异、技术栈差异。没有驱动就拆是徒增复杂度。
这是最关键的决策，拆早了是浪费，拆晚了是负担。有几个明确的信号。
团队协作冲突频繁。几十个人改同一个代码库，合并冲突天天发生，发布互相阻塞。这时候按团队边界拆服务，让各团队独立开发部署。康威定律说系统架构反映组织架构，按团队边界拆是最自然的。
某个模块需要独立扩容。比如秒杀模块在大促时流量是其他模块的几百倍，如果绑在单体里，整个应用都得按秒杀的规格扩容，浪费。拆出来独立扩容才合理。
某个模块迭代频率明显不同。营销活动模块天天改，账户核心模块几个月不动。绑在一起，营销的高频迭代会拖累账户的稳定性。拆开，各走各的发布节奏。
技术栈有真实差异。某个模块用 Python 做机器学习效果更好，硬塞进 Java 单体里别扭。这种情况按技术栈拆。
微服务有实打实的代价，分布式复杂度、运维负担、网络开销、调试困难。没有上面这些明确驱动就拆，是徒增复杂度。一个判断，如果某个服务拆出来还是一个人维护，那它就是个披着服务外衣的模块，拆了反而增加沟通成本。一个人维护的「微服务」是反模式。
拆分里最难的部分，是数据
图：共享数据库是「分布式单体」比纯单体还难维护；真正的服务化要求每个服务独占数据，跨服务取数据走 API 或事件同步。
服务拆分，代码好拆，数据难拆。
最常见的坑是共享数据库。多个服务连同一个库，看起来拆了服务，数据耦合还在。改一个表结构影响好几个服务，数据一致性要跨服务协调。这不叫服务化，叫「分布式单体」，比纯单体还难维护。
真正的服务化要求每个服务管自己的数据，数据所有权独立。服务之间要拿对方的数据，走 API 调用，或者用 CQRS、事件同步这些手段，绝不能直接 join 对方的表。
数据拆分是服务化真正的门槛。代码拆开只要几周，数据彻底拆干净可能要几个月甚至更久，因为要处理历史数据迁移、双写过渡、一致性保证。很多人卡在这一步，最后退回到共享数据库，服务化就名存实亡了。
微服务的代价，得有底气才接
拆成微服务之后，你会面对一整套新的问题。
分布式复杂度。网络调用会失败、会超时，消息会丢、会重复，这些在单体里不存在的麻烦全冒出来了。一致性要从单机事务变成分布式事务或者最终一致性。
运维负担。几十个服务要部署、要监控、要扩缩容，没有完善的 CI/CD 和容器化基础设施，根本玩不转。性能开销。进程间通信比进程内调用慢几个数量级，序列化反序列化都是成本。调试困难。一个请求穿过五六个服务，出了问题没链路追踪根本定位不了。
这些代价只有在「单体确实扛不住」的时候才值得承受。没有成熟的工程基建（CI/CD、监控、链路追踪、服务治理）就上微服务，会陷入混乱。
演进是渐进的，不是一步到位
正确的演进节奏是，单体起步验证业务，模块化加结构，然后拆第一个最痛的服务，观察稳定之后再拆下一个。一次拆一个，每次拆完都让它跑稳了再动下一个。
一次性大拆风险极高。见过一个团队为了「上微服务」把单体一次性拆成二十几个服务，结果两个月内系统各种不稳定，最后花了半年才收拾回来。渐进演进的最大好处是，每一步的风险可控，错了能及时回头。
服务化的成熟度也是渐进积累的。先把基础设施（CI/CD、监控、链路追踪）建起来，再补服务治理（注册中心、配置中心、网关、熔断降级），同时培养团队的 DevOps 文化和服务 ownership。没有这些配套，微服务就是一堆散落的孤岛。
架构服务于业务
回到最根本的一点，架构是手段，业务才是目的。
匹配业务阶段的架构就是好架构，和它先不先进没关系。业务早期用单体快速验证，验证成功后渐进拆分，规模到了再上微服务。每一步都对应业务的真实需求，不为先进而先进，不为拆而拆。
最忌讳的是两种心态。一是技术虚荣，觉得用微服务、用云原生才显得高级，脱离业务硬上。二是路径依赖，业务已经变了架构却不动，让团队在新需求上持续踩旧架构的坑。
架构演进的本质是持续地让系统和业务保持匹配。它不是一次性的设计，是一个长期的、动态的过程。能驾驭这个过程的人，才是真正的架构师。
