多微服务合并为一个服务：判断信号、实施路径与防退化

架构评审会上吵得最凶的一次，议题就是"多微服务合并为一个服务"。一边说拆得太碎已经快维护不动了，另一边说合回去就是开历史倒车。这种争论在做过几年服务化改造的团队里几乎都会出现，而且往往没有标准答案。我前后参与过三次规模不等的服务收敛，其中一次把十几个服务合成一个部署单元，另外两次只做了局部合并。踩过的坑足够写一本小册子，所以这篇不讲概念，只讲我在真实项目里怎么判断该不该合、怎么合、合完之后怎么防止它退化成一坨谁都不敢动的代码。

先把结论摆在前面：多微服务合并为一个服务，本质上是把分布式系统的复杂度换回单体内部的模块化复杂度。它不是技术退步，也不是万能解药，而是一次复杂度搬家。搬得好，运维成本、链路延迟、故障排查难度同时下降；搬得不好，你会得到一个"分布式单体"——既没有微服务的独立性，也没有单体的简单性，两边的好处都占不到。下面这些内容适合正在被服务数量困扰、或者准备做服务收敛的团队参考，也适合刚接手一堆历史服务、想知道能不能动手合并的同学。

1. 别急着动手：判断"该合并"的六个真实信号

1.1 拆分过度之后的样子，比想象中更容易识别

服务拆得对不对，跟服务数量没有直接关系。一个二十人的团队维护三十个服务，和两百人维护三十个服务，是完全两种体验。我见过最典型的一种情况是：一个业务域被切成了六个服务，结果每次改动一个业务规则，要同时发六个版本，联调两天，上线一晚上，出问题还得挨个查日志对时间戳。这时候拆分带来的不是解耦，是纯粹的成本放大。

判断服务是否拆过头，我一般看三个最直接的指标。第一个是变更连带率：一次业务需求平均要改几个服务的代码。如果这个数字常年大于三，说明边界切错了。第二个是跨服务调用占比：统计一下接口调用总量里，跨进程调用占多少。如果大部分接口只是为了给兄弟服务提供数据，那这些调用本来就是进程内方法调用。第三个是单服务有效代码量：如果一个服务刨掉脚手架、配置、启动类之后核心逻辑只剩几百行，那它更像一个模块而不是一个服务。

这三个指标不需要多精确的工具，从代码仓库的提交记录、网关的调用日志、构建产物的体积里就能粗估出来。我通常花半天时间就能出一份初步判断，比开三次架构评审会有效得多。

1.2 六个信号的具体判别标准

下面这张表是我自己在用的判别清单，左边是信号，右边是我会去看的具体证据。只要命中三个以上，我就会认真考虑合并方案。

需要说明的是"团队边界消失"这一条。微服务最核心的价值之一是组织解耦——不同团队可以互不阻塞地发布。一旦某个业务域的开发和运维已经收归同一个小组，独立部署带来的协作收益就基本归零了，剩下的只有成本。这是我判断合并时权重最高的一条，甚至高于技术层面的耦合程度。

1.3 什么情况下坚决不能合

反过来的清单同样重要。有三种情况我从来不考虑合并。第一种是合规与审计隔离要求：某些模块必须独立部署、独立审计，这是硬约束，跟技术优劣无关。第二种是性能画像差异极大：一个模块是 CPU 密集型，另一个是长连接 IO 密集型，合并之后资源争抢会非常严重，GC 停顿会互相影响。第三种是故障隔离是业务刚需：核心交易链路和边缘业务绝不能放在同一个进程里，因为合并意味着雪崩半径扩大。

还有一种常被忽略的情况：如果团队连最基本的模块化纪律都守不住——比如随便跨模块直接访问对方的内部类、共享数据库表随便写——那合并之后必然得到一个巨型意大利面。这种情况下，先修纪律再谈合并，顺序不能反。

2. 合并前的依赖地形测绘：把调用关系画成可执行清单

2.1 调用关系不要看文档，要看真实流量

架构文档里的依赖图，跟生产环境真实的调用关系，差距往往大得离谱。我做过一次比对，文档上写着 A 服务依赖 B 和 C，实际流量里 A 还偷偷调了 D 的一个内部接口，而这个接口是当年为了排查问题临时加的，走后门用了两年没人清理。如果不把这种"暗线"找出来，合并上线当天必炸。

我的做法是直接拉网关和 RPC 框架的访问日志，按调用方和被调方聚合，跑出最近七天的真实调用矩阵。同时并行做一次静态扫描，把代码里所有远程调用的客户端声明提取出来，跟日志结果求差集。差集里的条目就是需要人工确认的部分，通常两种可能：要么是没人用的死代码，要么是没登记的隐藏依赖。这两种处理方式完全不同，必须逐个确认。

顺带一提，这个方法还有个副产品：你大概率能发现一批可以顺手删掉的僵尸接口。我在最近一次合并里清理了三十多个调用量为零的接口，合并前的工作量直接少了一截。

2.2 数据边界的三种耦合形态，决定了合并难度

服务之间的耦合，看接口调用只是表面，真正决定工作量的是数据。我把数据耦合分成三种形态，难度依次递增。

第一种是只读共享：A 服务通过接口从 B 拉数据，自己不留存。这种最容易合，改成本地方法调用即可。第二种是各自持有副本：两个服务各自存了一份数据，靠消息同步。合并时要决定以谁为准，通常选数据更全的那一方，另一方改成本地查询后把同步逻辑删掉。第三种是交叉写入：两个服务都会写同一批表，靠事务或补偿保证一致性。这种最麻烦，合并时必须重新梳理写路径，把原来靠分布式事务兜住的场景改成本地事务，而本地事务的边界又常常跟原来的补偿边界对不上。

提示：第三类数据耦合是合并项目里最容易低估工作量的部分。我的一般估算方式是，接口改造的工作量占三成，数据层改造占七成，其中交叉写入占这七成里的一半以上。

2.3 输出一张能直接派活的合并清单

测绘完成后，我会产出一张清单，格式大概是这样的：模块名、对外入口（HTTP 路径或 RPC 方法）、内部依赖、数据归属、风险等级、负责人。这张表看起来朴素，但它是后续所有工作的基础，也是跟其他团队对齐预期的最有效工具。

风险等级的判定我用了三条简单规则：涉及交叉写入的标红，涉及外部系统回调的标黄，只有纯查询的标绿。实践下来标红的模块数量通常占总量的两到三成，而它们会占据整个项目一半以上的工期。这个比例提前讲清楚，能省掉很多后期的进度扯皮。

清单里还有一列容易被省略但很有用：保留还是废弃。合并是个天然的清理窗口，那些常年没人调用的接口、废弃的定时任务、过期的兼容分支，趁着这次改造一起删掉，比事后单独治理容易得多。

3. 进程内调用替换远程调用：接口收敛的具体做法

3.1 先换传输层，再换调用方式，不要一步到位

改造顺序上我吃过一次亏。当时图快，直接把远程调用客户端删掉，改成本地接口注入，一次性提交。结果本地跑得好好的，上线之后发现某个调用点原来依赖远程调用的超时机制做保护，改成本地调用后变成一个死循环，直接把线程池打满了。

后来我改成两步走。第一步只换传输层：远程调用客户端继续保留，但把实现替换成一个本地实现类，方法签名和返回结构完全不变。这一步的目标是让所有调用点在无感知的情况下把请求留在进程内。第二步才是把客户端接口替换成普通的模块服务接口，同时调整异常语义和超时保护。分两步走的好处是每一步都能单独灰度、单独回滚，出问题的时候能快速定位是哪一层改坏的。

第一步的代码大致是这样的，原来的远程调用客户端接口保持不变：

// 原远程调用客户端（保留，但实现替换为本地） public interface OrderQueryClient { OrderDetail queryById(Long orderId); } // 合并后的本地实现，内部直接调用订单模块的服务 @Component public class LocalOrderQueryClient implements OrderQueryClient { private final OrderDomainService orderDomainService; public LocalOrderQueryClient(OrderDomainService orderDomainService) { this.orderDomainService = orderDomainService; } @Override public OrderDetail queryById(Long orderId) { // 注意：这里不再有网络异常、超时、序列化，但需要手工补上参数校验 if (orderId == null || orderId <= 0) { throw new IllegalArgumentException("orderId invalid"); } return orderDomainService.loadDetail(orderId); } }

第二步再把这个客户端接口整体替换掉，让业务代码直接依赖OrderDomainService。这个替换过程可以用 IDE 的全局重构完成，但异常语义需要人工逐处确认。

3.2 包结构按业务能力划，不按技术分层划

合并之后最容易犯的错误是按 controller / service / dao 分层建包。看起来整齐，实际上模块边界完全消失了，任何人可以从任何 controller 调到任何 dao，三个月之后就没人说得清哪些代码属于哪个业务。

我采用的划法是顶层按业务能力分模块，每个模块内部再分层：

com.example.app ├── order // 订单模块 │ ├── api // 对外暴露的接口与DTO │ ├── domain // 领域逻辑，不依赖其他模块的domain │ └── infra // 仓储实现、外部适配 ├── inventory // 库存模块 │ ├── api │ ├── domain │ └── infra └── shared // 只放真正无业务语义的通用件 ├── util └── error

关键纪律有两条：模块之间只能通过api包互相访问，domain和infra包对其他模块不可见；shared包不允许出现任何业务概念，只能是日期工具、字符串处理这类纯技术工具。这两条如果靠自觉是守不住的，必须用工具强制，第六章会展开讲。

3.3 异常语义的重构，是最容易被漏掉的隐形工作

远程调用和本地调用在异常语义上完全不同，这是合并改造中最细碎也最容易出事的部分。远程调用天然存在一种失败：请求已经发出去了，但对端有没有执行成功你不知道。所以原来的代码里到处是"调用失败要不要重试""超时了怎么补偿"这类逻辑。改成本地调用后，这类失败不存在了，那些重试和补偿代码就变成了有害的。

举个具体例子：原来调用库存扣减接口，超时会重试两次。合并后本地调用不会再超时，但代码里的重试逻辑还在，如果碰上一次业务异常被包装成了可重试异常，就会重复扣减。这类问题排查起来极其痛苦，因为现象是"偶发多扣"，日志里看不出任何异常。

我的处理方式是给每个改造成本地的调用点加一条强制检查项：确认原来的重试条件、超时阈值、熔断规则三样东西的处置方式。要么删除，要么改成对本地业务异常的精确判断。这一步没有捷径，只能靠清单逐项过，我在一次合并里过了两百多个调用点，花了整整四天，但上线后一次这类问题都没出。

4. 数据层合并才是真正的深水区

4.1 三种数据形态对应三套完全不同的策略

接口层改造再复杂，本质上还是代码重写。数据层改造不一样，它涉及存量数据的迁移和一致性保证，一旦出问题就是数据损坏，恢复成本极高。我把遇到过的场景整理成下面这张表：

最后一行是我认为最危险的情况。两个服务写同一张表，一开始可能只是各自更新不同字段，但跑了两年之后，各自对这张表的字段含义理解可能已经不一样了。我在一次合并里发现，A 服务写入的状态值 3 表示"已取消"，B 服务以为是"已退款"，因为两边的枚举定义在各自仓库里独立演化，早就分叉了。这种问题只能靠人工比对枚举和状态机，没有工具能自动发现。

4.2 主键策略冲突和索引重建

合并数据时，自增主键是最常见的冲突源。多个库各自自增，合并后主键必然重复。如果这些表之间还有关联关系，主键重映射就是一场灾难。

我采用的方案是尽量不改存量主键，而是给合并后的表加一个全局唯一业务编号，对外交互统一用业务编号，内部关联仍用原主键加来源标识。这个方案的好处是存量数据完全不动，风险最低；代价是表上多一个字段，查询时要带上来源条件。对于新产生的数据，直接改用统一的号段发号器，慢慢把存量数据自然淘汰掉。

索引重建这件事经常被低估。原来两个服务各自针对自己的查询习惯建了索引，合并后查询模式变了，原来的索引可能变成负担。我在一次合并后遇到过写入性能下降四成的情况，排查半天发现是合并后某个高频更新表上多了三个联合索引，都是原服务各自为战留下的。所以合并完成后一定要做一轮索引审查，把没人用的索引删掉，这个过程大概能回收百分之十到二十的写入性能。

4.3 分布式事务消失之后，补偿逻辑要重写而不是删掉

很多人以为合并之后事务变简单了，把原来的补偿逻辑一删了事。这个想法很危险。原来跨服务调用，每一步失败都能明确知道失败在哪、要不要补偿；现在全在一个本地事务里，事务边界扩大了，锁持有时间变长，反而可能引入新的并发问题。

我的做法是把原来的补偿边界映射成新的事务边界。原来可能是"扣库存 + 建订单 + 发消息"三步，每步都有补偿。合并后前两步可以放进一个本地事务，但发消息这一步必须挪到事务提交之后，否则消息可能先于数据可见，消费方读不到。

@Transactional(rollbackFor = Exception.class) public void createOrder(CreateOrderCmd cmd) { // 事务内：只做数据库操作，保持事务尽可能短 inventoryService.deduct(cmd.getSkuId(), cmd.getQty()); Order order = orderRepository.save(buildOrder(cmd)); // 消息投递挪到事务外，用事务同步器保证提交后才发 TransactionSynchronizationManager.registerSynchronization( new TransactionSynchronization() { @Override public void afterCommit() { eventPublisher.publish(new OrderCreatedEvent(order.getId())); } } ); }

注意：合并之后事务变长是个普遍现象，因为原来分散在多个服务的事务操作现在挤到了一个事务里。我的一般原则是单个事务内的数据库操作不超过五次，超过就要考虑拆分并配合状态机推进。

5. 灰度切换与流量验证：怎么做到合并期间不停机

5.1 双跑对比：不要相信"逻辑等价"这四个字

任何声称"合并后逻辑完全等价"的说法，我都不信。两个服务独立演化那么久，边界条件上的差异一定存在。所以我的做法是双跑对比，新旧两条链路同时处理同一批请求，比对结果。

对比的实现不复杂：在网关层做分流，把请求同时打给旧服务和合并后的新服务，新服务的返回不对外输出，只做落库比对。比对字段要挑有业务语义的，比如订单金额、状态、优惠明细，而不是整个响应做字符串比对，否则时间戳、序列号这类无关字段会淹没真正的差异。

比对差异要有明确的判定规则。我一般分三档：结果完全一致、仅无关字段不同、业务字段不同。第三档必须逐条人工看，通常能在灰度期间挖出十几处边界差异，这些差异如果直接全量切过去，就是线上的几十个投诉工单。

5.2 切流顺序：从只读接口到写接口，从低峰到高峰

切流顺序我踩过坑。有一次先切了写接口，因为觉得写接口逻辑更简单，结果出问题之后产生了脏数据，清理花了两天。后来固定成这个顺序：只读查询接口、无副作用的计算接口、低频写接口、高频写接口、定时任务。

每一步的观察期不少于一个完整业务周期。什么叫完整业务周期？就是这批接口的所有使用场景至少被覆盖一次。比如涉及日终结算的接口，观察期就必须跨过一个结算时点，否则等于没验证。

流量比例上，我用的是 1% → 5% → 20% → 50% → 100% 的阶梯，每档之间的间隔根据接口 QPS 决定，QPS 低的接口需要更长的观察时间才能积累到有统计意义的样本量。同时要保证灰度流量能覆盖到不同的客户端、不同的地区、不同的时段，不能只抓到一类请求。

5.3 回滚方案要写进发布脚本，不能只写在文档里

回滚这件事，写在文档里等于没有。我的要求是回滚开关必须是配置中心里的一个开关，改完立即生效，不需要发版。同时这个开关要覆盖三个层面：流量切回旧服务、数据写入双写、消息消费暂停。

数据写入这一层最容易被忽略。合并后新服务可能已经写了新表，回滚时这部分数据不能直接丢，需要有双写或者反向同步来兜。我在一次项目里就是因为没做双写，回滚后新服务产生的订单在旧服务里查不到，客服那边直接炸锅。

6. 合并后的模块化纪律：防止服务退化成一坨泥

6.1 用构建工具把边界焊死，别指望代码评审

模块化边界靠自觉是守不住的，尤其是项目紧张的时候，一个"就这一次"的跨模块直连会变成惯例。我的做法是在构建层面做限制，让违规代码根本编译不过。

如果用的是多模块构建，每个业务模块独立成一个子模块，其他模块只能依赖它的 api 子模块，这样 domain 和 infra 在编译期就是不可见的。这个方案成本很低，效果极好，几乎零维护。

<!-- 模块依赖声明示意：外部只能看到 api 子模块 --> <dependency> <groupId>com.example.app</groupId> <artifactId>order-api</artifactId> <version>1.0.0</version> </dependency>

如果不是多模块结构，退一步可以用依赖检查工具，在构建流水线里跑一次包依赖分析，发现违规引用直接失败。这个检查跑一次大概几秒钟，成本可以忽略，但能挡住绝大多数越界。

6.2 补上架构测试，把规则变成可执行的断言

编译期限制能挡住包级别的越界，但挡不住逻辑上的耦合，比如订单模块直接查了库存模块的表。这类问题需要架构测试来兜。

我的做法是写一组断言：模块 A 的代码里不允许出现模块 B 的仓储类名、不允许出现模块 B 的表名常量、不允许出现模块 B 的领域对象。这些断言可以用简单的源码扫描实现，跑在单元测试阶段。

@Test public void orderModuleShouldNotTouchInventoryTables() { List<String> violations = SourceScanner.scan("com/example/app/order") .filter(line -> line.contains("t_inventory") || line.contains("InventoryRepository")) .collect(Collectors.toList()); assertTrue("订单模块禁止直接访问库存表: " + violations, violations.isEmpty()); }

这类断言一开始会误报，需要调几轮，但稳定之后就是一道很可靠的护栏。我维护的那套断言跑了两年多，抓到的违规加起来有几十次，基本都是新人在不知情的情况下越界。

6.3 发布粒度变粗之后，排队问题要提前想好

合并最直接的副作用是发布粒度变粗。原来一个服务可以随时发，现在十个模块绑在一起，任何一个小改动都要走完整回归。这个问题在合并初期特别明显，我在一次项目里就遇到过发布窗口排不上队、两个团队为了谁先发争了两天的情况。

缓解手段有三个。一是把不常变动的模块和常变动的模块分开发布通道，虽然在一个部署单元里，但可以通过配置灰度实现部分模块行为的快速切换。二是建立发布列车机制，固定每周几个发布窗口，提前收集变更，避免随时插队。三是把配置变更和代码变更彻底分开，能用配置解决的绝不发版。第三条最有效，我们后来把大量业务规则做成了配置驱动，发布频率直接降了一半。

7. 那些合并之后才暴露的问题

7.1 资源池共享带来的污染，比预想的更严重

原来每个服务一个进程，线程池、连接池、堆内存都是独立的。合并之后全部共享，一个模块的问题会直接影响其他模块。我在合并上线第一周就遇到过一次：某个报表查询模块的慢 SQL 把连接池占满，导致订单查询全部超时。这在合并前是不可能发生的，因为两个服务各有各的连接池。

解决办法是给关键模块分配独立的连接池和线程池，用命名区分，并且加上隔离上限。代价是总资源占用变高，但这是必要开销。

# 按模块拆分连接池，避免互相拖累 datasource: order: maximum-pool-size: 30 connection-timeout: 1000 report: maximum-pool-size: 10 connection-timeout: 3000

线程池同理，尤其是异步任务和定时任务，必须跟在线请求的线程池分开，否则一批定时任务跑起来就能把在线请求全部堵死。

7.2 链路追踪需要重建，traceId 不会自己传下去

这是个特别隐蔽的坑。原来跨服务调用时，traceId 通过请求头传递，中间件自动处理，谁都不用管。合并之后所有调用都在同一个进程里，不再有请求头，traceId 就断了。现象是日志里只有半截链路，排查问题时想看一次完整请求经过了哪些模块，根本拼不起来。

解决思路是在进程内用上下文透传。同步调用可以用线程本地变量，但异步和线程池场景下会丢失，必须在任务提交时做上下文拷贝。这块的实现要覆盖所有异步入口，包括线程池、消息消费、定时任务，漏一个就会出现断链。

// 异步任务提交时必须显式传递上下文 public <T> CompletableFuture<T> submitWithContext(Supplier<T> task) { TraceContext ctx = TraceContext.current(); return CompletableFuture.supplyAsync(() -> { TraceContext.restore(ctx); try { return task.get(); } finally { TraceContext.clear(); } }, bizExecutor); }

我建议合并前就把这个封装做好，作为基础设施的一部分，不要等出了问题再补。

7.3 雪崩半径扩大，需要补上原来不需要的隔离

合并前，服务之间天然隔离，一个服务挂了不影响另一个。合并后，一个未捕获的异常、一次内存泄漏、一个死循环，都会拖垮整个部署单元。这不是理论风险，我在合并后的第三个月就遇到过一次内存泄漏，泄漏点在一个很小的边缘模块里，结果整个应用频繁 Full GC，核心业务跟着抖动。

补隔离的手段有几种。最直接的是给边缘模块加上熔断和限流，虽然是本地调用，但照样可以用信号量做并发控制。其次是给每个模块设定内存使用上限的监控告警，早发现早处理。最后是在关键路径上加超时保护，本地调用虽然没有网络超时，但可以用带超时的异步执行包装，防止某个慢方法无限期挂住线程。

7.4 一次完整的排查链路复盘

说个具体的例子。合并上线两周后，有用户反馈"下单偶尔很慢"。这在合并前不会出现，因为订单服务和库存服务是分开的，慢的话能直接定位到是哪个服务。现在日志混在一起，只能靠 traceId 串。

我的排查过程是这样的：先从慢请求的 traceId 拉出完整链路，发现耗时集中在一个本地方法上；再看这个方法内部的日志，发现它在等一个数据库连接；然后查连接池监控，发现高峰时段连接池使用率长期在百分之九十五以上；最后定位到是报表模块新增的一个批量查询，占用了大量连接。

整条链路走下来花了大概两个小时，其中前一个小时都在确认 traceId 能不能串起来。这个案例让我意识到，合并之后可观测性的建设必须先于合并完成，否则每次排查都要多花一倍时间。后来我们把指标监控细化到了模块级别，包括每个模块的调用耗时分布、连接池占用、线程池队列长度，排查效率才回到合并前的水平。

回到最开始那个争论。多微服务合并为一个服务这件事，从来不是"拆好还是合好"的二选一，而是看当前的复杂度主要花在哪里。如果大部分精力消耗在跨服务协调、联调、发布排队上，合并就是划算的；如果复杂度主要来自单个模块内部的业务逻辑，那合并帮不上什么忙，甚至会让问题更难隔离。

我个人在实际操作中的体会是，判断标准可以简化成一句话：看团队每天的时间花在协调上还是花在实现上。前者占比高，就该合；后者占比高，说明边界本身没问题，别折腾。另外还有一个实操建议，无论合并规模多大，先把可观测性和模块化检查这两块基础设施做起来再动手，这两样东西在合并过程中是安全带，合并完成后是护栏，缺了任何一样，这事都别急着上。