微服务入门：为什么要把一个大系统拆开

刚开始做一个新产品，几乎不用犹豫：一个代码库、一个部署包、一份数据，几个人围着它转，改起来快，上线也快。这就是单体，也是大多数系统最自然的起点。本文想说清楚：既然单体这么顺手，为什么很多团队最后还是把它拆开？拆开要付出什么代价？小团队到底该不该跟进？

一、为什么一开始要用单体

新产品最大的敌人不是性能不够，而是想法还没被验证。单体把功能放在一起，调用就是函数调用，不用考虑网络和接口版本，一个人改完就能端到端跑通。部署也简单：打包一份，起一个进程，出了问题整包回滚。团队小的时候，这种做法让需求从想法到上线最短。更重要的是，早期根本不知道哪些功能会长大、哪些会被砍掉，边界模糊反而是一种灵活：先跑起来，再谈优化。

二、单体长大后的痛点

麻烦是慢慢长出来的。代码多了，改一个小功能也要先读懂一大片不相关的代码，新人上手越来越慢。部署变重：只改一个小模块，也要把整个应用重新打包上线，出了问题很难只回滚一半。几个人同时改同一份代码，合并冲突越来越多，排队上线成了常态。扩展也不均匀：某个模块流量暴涨，整个应用都要跟着扩容。系统越大，发布的心里负担越重，团队开始“不敢动”，新需求越来越慢。

三、微服务拆分原则

拆分不是越碎越好。第一，按业务边界拆，而不是按技术层次拆：一个服务围绕一块完整的业务能力，比如用户、订单、结算，各自有自己的数据和职责，改动尽量只影响自己。第二，自治：每个服务能独立开发、测试、部署和扩展，发布节奏不用互相等待。第三，接口要稳：服务之间用明确的约定通信，内部实现可以变，对外承诺不能随便改。第四，适度：先拆最痛、最独立、变化最频繁的那一块，用真实的痛点驱动拆分，而不是为了拆而拆。

四、拆开之后的新问题

拆开不是免费的。先是调用变复杂：原来一次函数调用的事，现在要走网络请求，延迟、超时和失败都要处理，一次业务操作可能牵涉好几个服务，每个环节都要有兜底。其次是数据一致性：每个服务管自己的数据后，过去一个事务能解决的事，现在要分几步完成，中间状态需要专门设计，失败了要能补偿或重试。最后是排查变难：一个请求在多个服务之间跳转，日志分散在各处，没有统一的链路编号，出问题时要先花很长时间定位到底是哪个服务出了问题，监控和运维的工作量也随之增加。

五、小团队该不该上微服务

对小团队来说，答案大多是：先别急。如果只有几个人、产品还在找方向，单体的效率优势更大，强行拆分只会把一个人能完成的事，变成几个人协调接口、排查调用链。更合适的做法是先把单体写“干净”：模块之间边界清晰、依赖有方向，为将来拆分留好口子。等某个模块确实成了瓶颈——比如它经常独立扩容、经常单独发布、由固定的人维护——再把它单独拆出来，拆一个、稳一个。小团队上微服务，应该是被真实的痛点推出来的，而不是被概念推进去的。

结语

单体和微服务没有高下之分，只有合不合适。一个大系统之所以要被拆开，不是因为单体过时了，而是因为它长大了，单个整体已经装不下不同的变化节奏和扩展需求。理解拆分的收益和代价，按业务边界稳稳地拆，在合适的时机才拆，才是微服务真正的入门课。