拆解拆分逻辑：重新理解微服务架构设计

很多团队做转型，上来第一句就是“我们要上微服务”。然后就开始拆。拆完半年，哭的心思都有。原本改一行代码就能发版，现在改一个需求要动三个服务，协调四个团队，发版要等排期。出了问题，查日志要跳五个系统，定位问题花一天。

拆错了比不拆更要命

错误的拆分带来的沟通成本和运行复杂度，会远超拆分带来的收益。 很多人默认，拆就是对的，拆得越细越好。去年跟一个南京做生鲜电商的技术负责人聊天，他说他们团队八个人，硬是把业务拆成了十二个服务。就为了“符合行业共识”。结果每次大促，服务之间调用超时，报各种错，运维天天熬夜，开发天天改BUG，原本半年就能做完的需求，拖了快一年。 说白了，就是为了拆而拆，忘了拆分到底为了解决什么问题。拆分的初衷，从来不是为了符合什么架构范式，而是为了解决 大规模团队协作下的开发效率问题，是为了把不同变更频率的模块隔离开，避免牵一发动全身。 如果你团队只有五六个人，所有代码所有人都能hold住，为什么要拆？本来改完就能发版，硬生生拆出一堆依赖，给自己加工作量。 微服务错误拆分后服务调用链路混乱图 见过最离谱的拆分，是把一个用户信息表，拆成了三个服务，基本信息一个，标签一个，等级一个。每次查询用户信息，要调三次接口，拼完返回。就因为看到说单一职责，就得拆成这样？单一职责不是这么用的。 单一职责是说一个模块只做一件相关的事，不是说每个字段都要单独拆出去。

业务边界才是拆分的标尺

拆分找不到边界，拆了也是白拆。很多人拆分按技术层拆，所有DAO拆一个服务，所有接口拆一个服务，所有缓存拆一个服务，这完全搞反了方向。 拆分要沿着业务边界拆，不是沿着技术层次拆。 举个例子，电商业务里，商品搜索是一个相对独立的业务域，订单履约是另一个，营销优惠又是一个。这些业务本身变更频率不同，负责的团队也不同，沿着这个边界拆，每个团队独立开发独立部署，不会互相干扰，这才对。 当然，边界也不是固定死的。得看你的业务阶段和团队规模。如果你就是一个小团队做垂直电商，所有业务就这几个人管，完全可以把商品和库存放在同一个上下文里，没必要硬分开。硬分开反而每次改库存逻辑，还要跨服务协调，得不偿失。 领域驱动微服务上下文边界划分示意图 很多人会提，康威定律说设计要符合组织架构，这句话的核心是什么？其实就是说，你的拆分边界，必须和团队的沟通边界对齐。如果两个拆分出来的服务，是同一个团队在维护，那还不如合并成一个，减少不必要的调用开销。如果两个服务本来就是两个独立团队负责，哪怕业务关联度高一点，该拆还是得拆，不然两个团队改同一个代码库，天天解决合并冲突，效率更低。 这里有个容易踩的坑，就是为了复用，把所有通用逻辑拆出来做成公共基础服务。复用本身没错，但过度复用会导致所有服务都依赖这个基础服务，基础服务一变，全链路都要跟着回归测试，反而变成了单点瓶颈。 说实话，适度的冗余，比过度复用好。允许业务服务里有少量重复代码，也比把所有逻辑都抽到公共服务里，让所有人都等你改好强。

被忽略的运行期复杂度

被忽略的运行期复杂度 设计的时候，大部分人都只盯着开发阶段的效率，很少有人提前考虑运行起来之后的问题。微服务本质上是分布式系统，分布式系统该有的问题，一个都跑不了。 网络延迟、调用超时、数据不一致、服务雪崩……这些问题，你拆完服务才想到要解决，就晚了。 就说数据一致性，很多人设计的时候，默认拆完服务用个消息队列做最终一致性就完事了。但你有没有想过，你的业务场景能不能接受不一致？比如做支付，扣了用户的钱，结果订单没生成，这个不一致能接受吗？当然不能。所以对于这种强一致要求的场景，最好的设计就是不要把这两个操作分到两个不同的服务里。放在同一个服务同一个数据库事务里，解决起来简单得多，也可靠得多。 不要为了拆分而强行拆分，牺牲一致性换所谓的架构优美，本质就是舍本逐末。 还有容错，很多团队拆分完服务，没做熔断降级，结果一个小众服务挂了，全链路都卡住，整个系统都崩了。这种事我见过不下十次。明明只是一个活动推荐服务出问题，结果用户连首页都打不开，损失多大。 所以设计的时候，就要想清楚，每个服务的容错边界是什么，依赖出问题了怎么降级，核心链路不能断，非核心可以直接降级返回默认值。这些都要在设计阶段就考虑进去，不是拆完再补。 不过话说回来，现在行业里很多声音反思拆分，其实也不是完全否定拆分的价值，而是对过去多年过度拆分的纠偏。没有哪一种架构是万能的，适合你的业务阶段、团队规模的，才是对的。 你要做大规模业务，上百人大团队协作，拆分当然能解决你的协作瓶颈。你就三五个人做创业项目，验证商业模式，单体足够用，先跑起来再说，别扯什么架构先进性，能快速落地拿到结果比什么都重要。