3、架构演进路线图：从单体到垂直拆分、再到微服务的典型路径，以及各阶段的优缺点

聊到架构演进，我经常跟团队说一句话：没有一步到位的架构，只有不断妥协的艺术。

你想想看，一个系统刚上线时，用户可能就几百人。这时候搞微服务？那不是给自己找麻烦吗？我见过太多初创团队，一上来就搞十几个服务，结果半年过去了，业务逻辑还没跑通，光服务间通信就折腾得够呛。

所以，咱们今天聊聊一条比较务实的演进路线：单体 → 垂直拆分 → 微服务。这条路我走过好几遍，踩过的坑也不少，希望能帮你少走些弯路。

第一阶段：单体架构（Monolithic）

说白了，就是把所有代码都塞进一个工程里。前端、后端、数据库访问、业务逻辑，全在一个包里。

优点：

• 开发速度快——我刚入行那会儿，一个人三天就能搭出一个完整的单体应用。调试也方便，IDE里直接跑就行。
• 部署简单——打个war包扔到Tomcat里，完事。运维同学最喜欢这种。
• 事务好处理——本地事务，ACID稳稳的。我在项目中遇到过好几次因为分布式事务搞出数据不一致，最后发现还是单体最省心。

缺点：

• 牵一发动全身——改一行代码，整个应用都得重新部署。我记得有一次，我只是改了个日志级别，结果把整个系统重启了，线上挂了3分钟。
• 扩展性差——你想给某个功能单独加机器？不行，得整个应用一起扩。资源浪费严重。
• 技术栈锁定——用了Java就是Java，想混用Python做点AI计算？没门。

第二阶段：垂直拆分（Vertical Split）

当业务复杂到一定程度，你会发现：其实可以把不同业务模块拆成独立的应用。比如电商系统，把用户、商品、订单拆成三个独立应用。

我个人习惯把这种拆分叫做「按业务领域切蛋糕」。每个应用有自己的数据库，独立部署，独立扩展。

优点：

• 团队自治——每个团队只管自己的应用，互不干扰。我见过一个团队，拆完之后，前端和后端终于不用在同一个代码库里打架了。
• 独立扩展——订单模块压力大？单独给订单应用加机器就行。其他模块不受影响。
• 技术选型灵活——用户模块用Java，商品模块用Go，没问题。只要接口约定好就行。

缺点：

• 数据孤岛——每个应用有自己的数据库，跨库查询变得很麻烦。我曾经为了查一个用户的订单详情，得调两次接口，再在代码里做join，性能差得离谱。
• 分布式事务——用户下单扣库存，涉及两个应用。用两阶段提交？性能太差。用最终一致性？又怕数据对不上。嗯，这里要注意，分布式事务是垂直拆分后第一个要面对的硬骨头。
• 接口耦合——应用之间通过HTTP或RPC通信，接口变了就得通知所有调用方。我遇到过好几次，因为接口字段没对齐，线上出了P0故障。

第三阶段：微服务架构（Microservices）

微服务，说白了就是垂直拆分的「极致版」。每个服务只做一件事，做得足够小、足够独立。

你想想看，一个订单服务，可能拆成：订单创建服务、订单查询服务、订单状态机服务、订单超时处理服务……每个服务都有自己的数据库，甚至可以用不同的存储引擎。

优点：

• 极致弹性——哪个服务压力大，就单独扩哪个。我见过一个系统，订单查询服务高峰期需要20台机器，但订单创建服务只要2台。微服务模式下，资源利用率高得多。
• 独立部署——改一行代码，只部署一个服务。风险范围极小。我记得有一次，订单状态机服务出了bug，只影响了状态流转，其他功能完全正常。
• 技术多样性——每个服务可以用最适合的技术栈。比如订单查询用Elasticsearch，订单创建用MySQL，订单分析用ClickHouse。这在单体里根本做不到。

缺点：

• 复杂度爆炸——服务多了，服务发现、配置管理、链路追踪、熔断降级……这些基础设施一个都不能少。我刚开始搞微服务时，光搭建这些基础设施就花了两个月。
• 调试困难——一个请求可能要经过十几个服务。出问题了，日志散落在各个机器上。没有好的链路追踪工具，你根本不知道问题出在哪。
• 数据一致性更难——每个服务都有自己的数据库，跨服务的事务几乎不可能用传统方式实现。Saga模式、事件溯源……这些概念听起来高大上，但落地起来坑特别多。

各阶段对比总结

维度	单体架构	垂直拆分	微服务
开发效率	初期高，后期低	中等	初期低，后期高
部署复杂度	低	中等	高
扩展性	差	中等	好
数据一致性	容易	中等	困难
团队协作	差（代码冲突多）	中等	好（团队自治）
运维成本	低	中等	高

好了，这一章就聊到这儿。下一章咱们聊聊「服务拆分的具体策略」，到时候我会分享一些我在实际项目中用过的拆分方法，以及那些「拆完就后悔」的教训。