改个字段要动四个服务:分布式单体避坑复盘

那是我们把一个老单体"成功"拆成微服务之后的第三个月,我才后知后觉地意识到:我们没造出微服务,我们造出了一个更难伺候的怪物。那天产品提了个不大的需求——给订单加一个"备注"字段,用户下单时能填,后台能看。放在以前的单体里,这是半天的活:改个表、加个字段、前后端各动几行。可这次,我开了个会才把要改的服务列清楚:订单服务要加字段、用户服务要透传、通知服务要展示、还有个聚合查询的 BFF 服务要跟着改。四个服务,四个代码仓库,四个团队,而且因为它们之间是链式依赖,上线还得讲顺序——谁先谁后错了就报错。一个半天的需求,硬是排期排了一周半,联调联了两天,上线那晚四个服务的人全在线上盯着,生怕哪个服务发早了或发晚了把链路搞断。

那一刻我盯着满屏的发布群消息,心里只有一个念头:这不对劲。微服务不是说好了"各自独立开发、独立部署、独立扩展"吗?怎么我们改个备注字段,搞得比单体还累、还慌、还慢?后来我才知道,这个我们亲手造出来的东西有个专门的名字——分布式单体(Distributed Monolith):它把单体拆成了好多个进程、好多个服务、好多次网络调用,承担了微服务架构所有的分布式复杂度(网络延迟、序列化、部分失败、最终一致性、十几套运维),却一个微服务真正的好处(独立开发、独立部署、独立扩展、故障隔离)都没拿到。这是微服务化最常见、也最坑的一种失败姿势:你以为你升级了,其实你只是把一个紧耦合的系统,从"进程内紧耦合"变成了"跨网络紧耦合",反而更糟了。

故障现场:一个"备注字段"暴露的真相

先说清楚背景。我们这套系统支撑一个中等规模的电商后台,日订单量几十万。一年前还是个 Java 单体,几十万行代码,所有人都在一个工程里提交,部署是一个 war 包整体上线。随着团队扩到三十多人,单体的痛点很明显:一个人改错一行,整个系统编译不过;发布一次要全员等;谁也不敢动核心代码怕牵一发动全身。于是我们做了当时看来无比正确的决定:拆微服务。

半年时间,我们把单体拆成了十几个服务:订单服务、用户服务、商品服务、库存服务、通知服务、支付服务、还有几个聚合查询的 BFF。拆完上线那天还挺有成就感的。可成就感没维持多久,各种别扭就接踵而至。"备注字段"事件只是压垮我耐心的最后一根稻草——在那之前,类似的别扭已经发生过很多次:做个"订单状态变更同时发短信"的需求要改三个服务;查个"用户的订单列表带商品图"的接口要串联四个服务的调用;每次稍微像样点的需求,几乎没有一个能在单个服务里闭环完成的。

我把过去两个月的需求翻出来统计了一下,数字很扎心:

结论刺眼:我们拆微服务的初衷是"提速"——让小团队能独立快速迭代;可结果是全面"减速",几乎每个需求都要跨服务协作、排期、联调、按序上线,比单体时代慢了好几倍。这就是分布式单体最典型的症状:本应解耦的服务,实际上耦合得密不透风,只不过耦合的形式从"函数调用"变成了"网络调用",而后者比前者难管理一百倍。

第一件事:认清"分布式单体"长什么样

要解决问题,先得能识别它。分布式单体不是某一行代码写错了,而是一整套架构上的"症候群"。我对照着自己的系统,总结出几个最典型的特征,你可以拿去给自己的系统做个体检:

# 分布式单体的典型症候(中几条就要警惕了)
1. 改一个功能, 总要同时改动好几个服务         → 服务没按业务边界拆
2. 服务必须按特定顺序部署, 否则就报错          → 服务间强耦合、强依赖
3. 多个服务直接连同一个数据库 / 同一张表        → 数据层没拆, 耦合最深
4. 一个请求要同步串联调用 5+ 个服务才有结果      → 调用链过长, 雪崩风险
5. 服务之间共享一个公共 model / DTO 的 jar 包    → 代码层硬耦合, 牵一发动全身
6. 任何一个服务挂了, 整条链路都不可用           → 没有故障隔离

我那套系统,六条中了五条。其中最致命、也最隐蔽的是第 3 条——共享数据库。我们拆服务的时候,图省事,代码是拆开了部署成了不同进程,但底下还是连的同一个 MySQL、读写着同一批表。订单服务和用户服务都在直接读写 user 表和 order 表。这意味着什么?意味着这两个服务在数据层面根本没分开:用户服务想改个 user 表的字段,得通知订单服务一起改;订单服务的一个慢查询,能把整个库的连接占满,拖垮用户服务。共享数据库,是分布式单体里耦合最深、也最难拆的一道枷锁——它让"独立部署"从根上就不可能,因为数据是绑死的。

第二件事:根因是"拆分边界"划错了

认清症状之后,我开始追根:为什么我们拆出来的服务会这么黏?复盘下来,病根只有一句话——拆分的边界划错了。我们当初拆服务,凭的是一种朴素的、却完全错误的直觉:按"技术"或"数据表"来拆。哪些代码操作 order 表,就划成订单服务;哪些操作 user 表,就划成用户服务。听起来很整齐,对吧?可这恰恰是分布式单体的万恶之源。

因为真实的业务需求,几乎从不会乖乖地只落在一张表、一个技术模块里。"用户下单"这个动作,天然就要同时碰订单、用户、库存、通知——你按表拆,就等于把一个完整的业务动作,人为地切成了好几刀,分散到好几个服务里。于是每来一个业务需求,都得把这几刀重新缝合起来——这就是为什么我改个备注要动四个服务。按技术分层或数据表拆服务,会让"业务的内聚"和"服务的边界"互相垂直、彼此撕裂,结果就是每个业务需求都横跨多个服务。

正确的拆法,是按业务能力(Business Capability)或者说领域的限界上下文(Bounded Context)来拆。核心标准是内聚:那些"总是一起变化、服务于同一个业务目标"的东西,应该待在同一个服务里。我把两种拆法的差别画成了图:

看出区别了吗?错误拆法里,一个需求像探照灯一样扫过好几个服务;正确拆法里,一个业务需求理想情况下应该落在一个服务内部就能闭环。判断一个服务边界划得好不好,有个特别朴素的检验标准:看常见的业务需求,是不是大多能在单个服务内部独立完成,而不需要拉着一堆别的服务一起改。如果你发现需求总是横跨服务,那不是需求的错,是你的服务边界划错了。

第三件事:拆数据库,斩断最深的耦合

边界想清楚了,落地第一刀,必须砍向那个最深的耦合——共享数据库。原则很硬核:每个服务独享自己的数据库(或至少独享自己的表),别的服务绝不允许直接访问,只能通过这个服务暴露的接口来拿数据。这是微服务的一条铁律,也是"独立部署"的前提:数据私有了,你才能自由地改自己的表结构而不影响别人。

# 拆数据库前(分布式单体): 大家共用一个库, 谁都能伸手
[订单服务] ---\
[用户服务] ----+--> [同一个 MySQL: order表/user表/stock表...]
[库存服务] ---/        ↑ 谁都能读写谁的表, 耦合死

# 拆数据库后(真微服务): 数据私有, 只能走接口
[订单服务] --> [订单库 order_db]   想要用户数据? 调用户服务的接口
[用户服务] --> [用户库 user_db]
[库存服务] --> [库存库 stock_db]

拆库的过程是痛苦的,尤其是历史数据和那些跨表的 JOIN 查询。我们的做法是分步走、不求一步到位:第一步,先在代码层面约束——禁止任何服务直接访问不属于自己的表,需要别人的数据一律改成调接口,哪怕底层还连着同一个库;第二步,把表按服务归属拆到不同的 schema 或不同的库实例;第三步,处理那些原本靠数据库 JOIN 完成的跨服务查询,改成应用层组装。

// 反面: 订单服务直接 JOIN 用户表拿用户名 (耦合了 user 表)
// SELECT o.*, u.name FROM `order` o JOIN `user` u ON o.user_id = u.id

// 正面: 订单服务只查自己的库, 用户信息调用户服务的接口
public List<OrderVO> listOrders(Long uid) {
    List<Order> orders = orderRepo.findByUserId(uid);   // 只查订单库
    // 需要的用户信息, 批量调用户服务接口 (而非 JOIN 它的表)
    Map<Long, UserDTO> users = userClient.batchGet(
        orders.stream().map(Order::getUserId).distinct().toList());
    return assemble(orders, users);   // 应用层组装
}

很多人一听"把 JOIN 改成接口调用"就皱眉:这不是凭空多了网络开销、还可能 N+1 调用吗?是的,这正是微服务要付出的代价。但关键在于批量化——像上面那样把"一个个查"变成"一批一起查"(batchGet),就能把 N 次调用压成 1 次。用一点点查询性能和一些应用层组装代码,换来数据层的彻底解耦、换来每个服务能独立演进自己的数据模型——这笔交易,在中大型系统里几乎总是划算的。

第四件事:把"同步强依赖"改成"异步事件"

拆完数据库,还剩一道耦合:服务之间那条长长的同步调用链。"下单后发短信"为什么要改订单和通知两个服务、还得保证调用顺序?因为我们写的是订单服务下完单同步去调通知服务发短信。这条同步链有两个大问题:一是耦合——订单服务得知道通知服务的存在、地址、接口;二是脆弱——通知服务挂了或者慢了,会直接拖累甚至拖垮下单这个核心流程。

解法是事件驱动:订单服务下完单,只管往消息队列里发一个"订单已创建"的事件,然后就返回了,它压根不需要知道谁会关心这个事件;通知服务自己去订阅这个事件,收到了就发短信。这样一来,订单服务和通知服务之间就彻底解耦了——订单服务不认识通知服务,通知服务挂了也丝毫不影响下单。

// 反面: 订单服务同步调通知服务 (强耦合 + 脆弱, 通知挂了下单也挂)
orderRepo.save(order);
notifyClient.sendSms(order.getUserId(), "下单成功");  // 同步等它, 它慢你也慢

// 正面: 订单服务只发事件, 不关心谁消费 (解耦 + 健壮)
orderRepo.save(order);
eventBus.publish(new OrderCreatedEvent(order.getId(), order.getUserId()));
// 下单流程到此结束, 立刻返回

// 通知服务: 自己订阅, 跟下单流程完全异步、隔离
@EventListener("OrderCreatedEvent")
public void onOrderCreated(OrderCreatedEvent e) {
    smsService.send(e.getUserId(), "下单成功");   // 它挂了也不影响下单
}

事件驱动是斩断微服务间同步耦合的利器。它把"我命令你做某事"(强耦合的同步调用)变成了"我宣布发生了某事,有兴趣的自己来处理"(松耦合的异步事件)。判断哪些调用该改成事件:凡是"主流程完成后触发的、不需要立即拿到结果的副作用"(发通知、记日志、更新统计、触发下游流程),都应该用事件异步化,而不是塞进主流程同步调用。当然,异步也带来了最终一致性、消息可靠投递等新课题,但这些是良性的、有成熟方案的复杂度,远好过同步链那种脆弱的强耦合。

第五件事:别共享代码,共享会变成耦合

还有一个特别隐蔽、却几乎人人都踩的坑:服务间共享一个公共的 model/DTO 的 jar 包(或者公共库)。这事看起来太合理了——订单服务和用户服务都要用 UserDTO,那提取一个 common 包大家都依赖,不是天经地义、还消除了重复吗?可正是这个"消除重复"的好意,又把刚拆开的服务在代码层面重新焊死了。

// 反面: 一个 common 包定义 UserDTO, 所有服务都依赖它
// common-1.0.jar  ← 订单服务、用户服务、通知服务全都 import 它
// 后果: 用户服务想给 UserDTO 加个字段, 一改 common,
//       所有依赖它的服务都得重新编译、一起升级、一起发布 → 又锁死了

// 正面: 每个服务定义自己需要的 DTO, 哪怕看起来"重复"
// 订单服务里: class UserBrief { Long id; String name; }  // 它只关心这俩
// 用户服务里: class UserDetail { ...十几个字段... }       // 完整定义
// 两者独立演进, 谁也不卡谁

这违反了很多人奉为圭臬的 DRY(不要重复)原则,但在微服务的语境下,有一句话值得刻在心里:在服务边界上,一点点可控的重复,远好过一份共享带来的强耦合。共享代码 = 共享变更的命运:你动它,所有依赖者都得跟着动。微服务追求的是"独立演进",而共享代码恰恰扼杀了独立性。所以,跨服务之间,宁可让每个服务定义自己那份"刚好够用"的 DTO,也别图省事抽一个大家共用的公共包。共享一些纯工具类(比如日期格式化)无妨,但承载业务语义的 model/DTO,绝不要跨服务共享。

一张"该不该拆、怎么拆"的决策图

讲完了五件事,我把"怎么避免造出分布式单体"的思考路径,收成一张决策图。下次你要拆服务、或者怀疑自己已经掉进坑里时,可以照着走一遍:

这张图最想传达的,其实是最上面那个分叉:第一问永远是"该不该拆",而不是"怎么拆"。微服务不是越多越好,服务的数量本身没有任何价值,甚至是负债(每个服务都有运维、监控、部署成本)。只有当一块功能"确实需要独立演进、独立扩展"时,拆它才有意义。为拆而拆,把本该内聚在一起的东西硬切开,正是分布式单体的起点。

真微服务 vs 分布式单体:一张对照表

最后,把"真微服务"和"分布式单体"在几个关键维度上的差别列出来,你可以拿它给自己的系统打个分——中间那列越多,你就越接近一个货真价实的分布式单体。

我们后来花了大半年,对照着这张表一项项地改:重划了边界,把十几个碎服务合并重组成五六个内聚的业务服务;拆了数据库;把能异步的调用都改成了事件;干掉了公共 model 包。改完之后,那个曾经要改四个服务的"备注字段"类需求,现在大多能在一个服务里搞定;发布也不再需要全员盯着排顺序。系统这才慢慢长出了微服务本该有的样子。

写在最后:微服务是"结果",不是"目标"

这场从"分布式单体"里挣扎出来的经历,给我最大的认知转变,是我终于想明白了一件以前完全搞反了的事:微服务,应该是系统演进到某个阶段的"结果",而不是一开始就奔着去的"目标"。我们当初的错误,从念头上就埋下了——我们是"想做微服务",于是去找一个单体来拆,把"拆成很多个服务"本身当成了成功的标志,服务拆得越多越觉得自己架构先进。可这是本末倒置。真正该问的从来不是"我怎么把它拆成微服务",而是"我的系统现在到底遇到了什么具体的痛点,微服务这套手段能不能、值不值得用来解决它"。

当你带着"解决具体问题"的心态去拆,你会非常克制:这块功能确实需要独立扩展(比如它流量特别大),好,把它拆出去;这块功能确实需要独立的技术栈或独立的发布节奏,好,拆。每一刀都拆得有理有据。而当你带着"我要做微服务"的心态去拆,你会拆得停不下来,把一个个本该内聚的业务硬生生切碎,最后收获一地的碎片和一个分布式单体。架构的成熟,恰恰体现在"克制"——不是看你能把系统拆得多碎、用了多少时髦的分布式技术,而是看你能不能在每个决策点上,清醒地分辨"什么该拆、什么坚决不拆"。

更进一步,我也彻底放下了对"单体"的偏见。单体不是落后的代名词,微服务也不是先进的勋章。它们只是两种各有适用场景的架构选择:单体的复杂度在"代码内部",微服务的复杂度在"服务之间"——而后者(网络、分布式事务、运维、可观测性)往往比前者更难驾驭。一个组织如果还没有足够的工程能力去驾驭分布式的复杂度,贸然拆微服务,只会用一种自己更搞不定的复杂度,去替换一种自己本来还能应付的复杂度,结果就是我经历的那种"比单体还累"。对很多团队来说,一个组织良好、模块清晰的"模块化单体",反而是更务实、更高效的选择;等业务和团队真的长到单体扛不住了,再有的放矢地把最需要独立的那部分拆出去,水到渠成。

所以,如果你也正打算拆微服务、或者隐隐觉得自己手里的"微服务"怎么用着比单体还别扭,我想把这次踩坑最想说的话送给你:别为了微服务而微服务。先想清楚你要解决的真问题,再判断拆分是不是对的手段,然后用业务边界(而非技术分层)去划线、让数据私有、让调用解耦、容忍一点重复。做到这些,你拆出来的才是能独立呼吸的微服务;做不到,你拆出来的,大概率只是一个穿着微服务外衣、却比单体更难伺候的分布式单体。愿你少走我走过的这段弯路,把每一刀,都拆在真正该拆的地方。

—— 别看了 · 2026