系统间通信这个系列写到第三篇我打算换个节奏。前两篇把协议选型、同步与异步模型、超时重试的基本边界都聊了一遍不少读者后台留言说理论都能看懂可真到了线上出问题还是不知道往哪儿查。这是我做架构这些年最深的一个体会——通信架构的设计图永远干净生产环境永远复杂。所以第三篇我不打算再铺新概念专门记录那些设计图里不会出现的问题同步调用的参数坑、队列积压事故、最终一致性落地的真实取舍以及链路追踪在排障里的实际价值。适合正在做微服务拆分、或者在多个系统之间折腾通信方式的团队尤其适合那些刚从单体切到分布式、被线上故障折磨过一两轮的开发者。1. 同步调用的三组参数配置不好迟早翻车1.1 连接超时和读取超时必须分开配置很多团队把超时当成一个“随便给的值”全局统一设个 3000ms 完事。这几年看下来这几乎是最容易埋雷的写法。连接超时connectTimeout和读取超时readTimeout应对的是两个完全不同的等待场景前者是 TCP 握手、连接建立花的时间后者是请求已经发出去、等待服务端响应数据的时间。把两者拧成一个值后果就是要么连接阶段给的时间太多某个下游网络不通时所有线程在 connect 上排队要么读取阶段给的时间太少明明正常业务就要跑两秒你只给一秒一上线就超时。我经手过一个典型事故。某个核心服务给下游接口配置了 3 秒总超时平时没有异常。后来下游数据库发生抖动一条 SQL 从 50ms 涨到了 2.8 秒。这个值没有超过总超时请求本身不算超时但因为同类请求都开始卡在 2 秒以上这个服务自身的 Tomcat 线程池活跃线程数快速被打满最终把自己拖垮了。问题不在于下游而在于你给了下游“多余的等待时间”并且没有任何降级手段。同步调用最怕的不是个别接口慢而是慢请求把连接池和线程池占住拖垮整个进程。正确的思路是把等待拆成三层。连接建立阶段给 500ms 到 1s这个阶段本来就是毫秒级完成不需要宽限第一个字节等待 TTFB 给 1s 到 2s用来容忍服务端处理前的基础耗时整个读取阶段给一个宽松但不放纵的兜底值比如 3s 到 5s。不同下游接口的耗时特征不一样至少要把“连接”和“读取”拆开别用一个总超时包打天下。连接型超时宁可短一点快速失败让熔断器尽早介入读取型超时按接口 p99 的 3 到 5 倍去设留出合理余量。1.2 重试会放大故障别在核心链路上轻易开启如果说超时是防守那重试就是进攻。可进攻一旦用错了地方反而会放大故障。我在不少项目里看到同一个错误RPC 框架自动带重试配置默认重试 2 次下游一抖动所有调用方几乎在同一时间发起重复请求流量直接变成原来的三倍把本就不稳定的下游彻底压垮。这个放大效应不是理论推演是我亲历的。某一轮内部系统全链路压测时我们同时依赖了三个下游服务其中一个服务发布变更后响应从 50ms 涨到 5s。调用方配置了重试 2 次单服务 QPS 800瞬间对下游产生了接近 2400 的请求压力。下游本来就慢再被重试流量灌进来最终彻底雪崩。更要命的是重试不止消耗下游资源还消耗调用方自己的线程池——所有重试请求都在同步等待线程活跃数持续上涨年轻代 GC 越来越频繁连健康检查都过不去了。经验总结下来就几句话写操作的重试要格外小心除非接口已经实现了幂等否则重试可能造成重复下单、重复扣款读操作虽然相对安全但必须考虑这个接口在下游故障时是不是真的值得再打一次。如果一定要重试必须配合指数退避加抖动避免所有客户端在同一时间扎堆重试同时把重试次数压到 1 次以内。最核心的一条重试必须和熔断器联动。没有熔断保护的重试故障期间就是灾难放大器。1.3 熔断器与超时重试的协同设计熔断器的目标是下游已经快要不行了你还继续把流量打给它。三个状态——关闭、打开、半开——逻辑本身不复杂难在参数配合。我常用的策略是10 秒滑动窗口内失败率达到 50% 就熔断 30 秒半开状态只放 10% 的试探流量试探成功才逐渐恢复。这三个参数必须和超时、重试放在一起看因为它们是一个整体。超时决定一次请求最多等多久重试决定一次请求最多发起几次熔断决定下游故障时调用方愿不愿意快速失败。举个反面例子。假设超时设 5s失败率阈值 50%窗口 10s那么窗口内只要失败 5 个请求就会熔断。但这 5 个请求每个都已经等了 5s如果重试 2 次可能总共等了 15s 才返回失败。对用户来说这个系统的体验就是卡了十几秒然后报错。所以好的配合是超时收短到 2~3s重试只对幂等读操作开一次熔断的失败率阈值按接口重要程度单独配置。核心链路宁可快速失败让上层降级也不能硬扛到线程池耗尽。同步调用最怕的不是返回错误而是用超长等待把整条链路活活拖死。2. 一次队列积压事故重新定义了消费端设计的底线2.1 事故背景一条订单消息引发的连锁反应聊完同步说异步。消息队列积压这件事做系统间通信的团队基本都遇到过但大多数人是问题出现之后才去看监控。我印象最深的一次是某次大促前的全链路压测。订单系统把结构化的 JSON 消息推给下游三个消费者库存、物流、积分。消息峰值 QPS 在 1500 左右按照设计容量是绰绰有余的。但压测进行到一半积分服务数据库连接池满了消费能力从每秒 1500 掉到每秒 300队列积压从几千条滚到几百万条Broker 磁盘告警消费组 Lag 图上拉出一条长长的斜坡。当时团队的第一反应是加机器。消费者从 3 台扩到 15 台结果发现消费速度并没有线性增长。这是一个非常关键的信号瓶颈不在消费者实例数量而在消费者内部的某个环节。很多人遇到积压就只会扩容但扩容解决不了单点瓶颈只会把问题从“队列堵”变成“连接池更堵”。2.2 排查过程从堆积量反推消费瓶颈排查积压问题我习惯按三步走先看消费组 Lag 是不是真的在涨再看消费 TPS 和消费 RT最后看消费者的 JVM 和下游依赖。光看积压量只能说明堵了搞不清是生产太快、消费太慢还是消费者在空转。公式很简单积压量 生产速率 - 消费速率。如果生产速率没有异常变化那核心矛盾就锁定在消费侧。那一轮压测里我们把消费者扩到 15 台之后TPS 始终在 700 上下浮动。这说明单机消费能力被某个东西卡住了。接着看 GC 日志老年代回收频率高得吓人堆内存只有 2G消息体里嵌了完整带上游业务明细的 JSON每次反序列化都要产生大量中间对象。再看数据库连接池只有 15 个连接消费线程却开了 16 个。16 个线程抢 15 个连接必然有线程在等连接释放消费速度不可能上去。最终的调整方案很朴素。消息体瘦身把内嵌的大 JSON 换成业务 ID消费者需要时再按需查询消费线程从 16 降到 8改成批量拉取一次拉 100 条数据库连接池从 15 提到 30。三个改动加起来消费 TPS 从 700 涨到 24008 个小时把几百万积压清完了。整个过程最值得记录的不是某个高明技巧而是验证顺序先确认实例数不是瓶颈再看 JVM再看下游连接池一步步逼近真相。2.3 消费端设计的三条加固原则那次事故之后我把消费端设计原则写进了团队规范一共三条。第一条消费线程数必须小于下游连接池可用连接数。消费线程再多如果每个线程都在等数据库连接TPS 反而会因为线程切换而下降。反过来也一样如果消费者 CPU 不高、TPS 也上不去优先检查它依赖的连接池和外部 IO而不是先加机器。连接池耗尽最典型的特征是线程等待时间变长但 CPU 和内存都很健康。第二条Lag 和积压时间是最高优先级的监控指标。积压量必须按分钟级采集并且按消费组拆开看。只有看到每个消费组各自的积压速度才能在多下游场景里快速定位是哪条链路出了问题。只监控 Broker 总积压量的团队遇到问题只能瞎猜因为总积压量会把不同消费组的问题混在一起。第三条死信队列要提前设计。消费者反复处理失败的消息如果没有独立的死信队列重试会把日志刷爆还可能阻塞正常消息。我们的做法是重试超过 3 次就直接落库保留原始 payload 和异常堆栈后续人工修复或写脚本回放。死信表字段要包含消息 ID、业务 ID、类型、失败原因、重试次数、入表时间再加一个唯一索引防止重复入库。不要等到积压事故发生了再补那就晚了。3. 最终一致性落地本地消息表与事务消息选哪个都不轻松3.1 本地消息表简单可靠但有明显的双写隐患系统间通信最典型的业务场景就是“本地业务操作 通知下游”。下单后给积分服务发消息、支付成功后通知物流服务都属于这一类。你当然可以直接调用 MQ 发布消息但 MQ 发送失败时本地事务已经提交了下游永远感知不到这次变更数据就出现了不一致。于是本地消息表方案出现了在同一个本地事务里写业务数据和一个消息记录消息状态先设为待发送事务提交后再由后台任务扫描发送成功后再更新状态。这个方案看起来朴素实际确实能跑很多老项目用得非常稳定。但它有个硬约束业务表和消息表必须在同一个数据库里否则本地事务就不成立。一旦业务分库分表或者消息需要跨越多个数据源这套方案就失效了。而且它带来的双写成本很直接每一条业务消息都要多写一张表、多一次事务数据库压力会增加不少。我的建议是老项目如果已经跑了一年半载别轻易动它新项目如果存在跨库或分片需求就别再往这个方向绕。3.2 事务消息半消息与回查机制的取舍事务消息是很多人眼里比本地消息表更高级的方案RocketMQ 的事务消息最有代表性。它的核心机制是半消息加回查。生产者先把消息发给 MQ但这时消息对消费者不可见生产者继续执行本地事务。本地事务提交后调用 MQ 的 commit消息才真正被投递。如果生产者在执行本地事务的途中进程挂了MQ 会主动回查本地事务结果再决定 commit 还是 rollback。这套机制解决了本地消息表跨库能力受限的问题但实际落地坑也不少。最典型的是本地事务执行时间不能太长。RocketMQ 的事务超时默认是 60 秒如果本地事务里做了重量级数据库操作或者外部 RPC超过默认时限后 MQ 发起回查本地事务还没结束回查拿不到明确结果消息就会一直悬在中间状态。另一个坑是实现回查方法时要足够轻不要为了查事务状态再去跑一遍完整业务逻辑最好直接读一张状态表。我自己踩过的一个坑是事务消息的端到端延迟可能比想象中高特别是在回查频繁、消息转账中间态比例较大的场景。如果你是那种要求业务提交后几百毫秒内必须消费完毕的场景事务消息不一定比本地消息表更合适。可以把两种方案的对比放进一张表里方便踩坑前先判断维度本地消息表事务消息实现成本低业务库加后台任务中需要事务回调和回查方法跨数据库能力不支持业务和消息必须同库支持依赖 MQ 和回调接口可观测性状态表直观可查可改半消息对消费者不可见排查靠日志运维复杂度需要定时任务和清理策略依赖 MQ 的回查能力和监控适用场景单库内的轻量服务跨库、多系统边界复杂的场景3.3 幂等设计才是最终一致性的大前提不管选本地消息表还是事务消息MQ 的投递语义天生是“至少一次”几乎不可能做到“恰好一次”。消费端收到重复消息是常态不是异常。所以最终一致性的真正核心不在发送端而在消费端的幂等设计。幂等做不好消息发得再准也会在消费端出乱子。幂等设计最常见的三种思路。第一种是数据库唯一键。在业务表上建立和业务 ID 对应的唯一索引重复消息插入时报冲突被忽略适合业务操作本身就是插入的场景。第二种是消费记录表。消费前先把 messageId 和业务 ID 写入记录表用唯一键兜底重复消息被 insert ignore 挡掉。第三种是 Redis 的 SETNX短时间窗口内用一个固定的业务键做消费标记适合对响应速度要求高、业务状态变化频繁的场景。生产环境我见过最稳的组合是“Redis 前置检查加数据库唯一索引兜底”两边互补性能和安全都能顾到。消费幂等表大概是这样的可以参考CREATE TABLE t_message_consume_log ( id BIGINT PRIMARY KEY AUTO_INCREMENT, message_id VARCHAR(64) NOT NULL, biz_id VARCHAR(64) NOT NULL, consume_time DATETIME NOT NULL, UNIQUE KEY uk_biz_id (biz_id) ) COMMENT 消息消费幂等记录表;三点必须注意。幂等键不能只用 messageId同一个业务操作可能被多个消息触发要结合业务 ID 组合使用幂等约束必须落数据库唯一索引Redis 过期之后可能失效消费逻辑里的幂等检查不能放在事务外面否则并发场景下重复请求会漏过拦截。最终一致性的前提不是消息发送多可靠而是同一个消息哪怕消费两次业务状态也只有一个结果。4. 链路追踪不是可选项它是定位通信问题的第一抓手4.1 TraceId的生成与透传代码里只需要做三件事系统间通信的排障最头疼的问题永远是请求到底经过了哪些服务哪个环节慢哪个节点拒绝了请求哪条消息丢了没有链路追踪你只能逐台机器翻日志靠时间戳猜调用关系。有了 TraceId你至少能把一次请求经过的系统串起来。实现链路追踪不一定要一下子就上完整的可观测性平台先做好三件事就够了。第一在系统入口生成 TraceId。不管是 HTTP 网关还是消息队列消费者只要请求进入系统就生成一个全局唯一 ID。第二把 TraceId 放进日志上下文。Java 项目就是 MDC其他语言就是各自的线程上下文让每一行日志自动携带 TraceId。第三在系统间通信时透传。发 HTTP 放在 header发 gRPC 放进 metadata发 MQ 放进消息属性。结果最容易被疏忽的是第三步。链路只要有一跳没传整条链路就断在那一环后面所有日志都对不上。异步线程池是 TraceId 最容易断的地方。线程池里的线程拿不到主线程的 MDC不做包装的话TraceId 一进异步就丢了。标准解法是给线程池的 Runnable 做一层装饰提交时把当前线程的 MDC 快照抓一份执行时再塞回去public class MdcRunnable implements Runnable { private final Runnable task; private final MapString, String context; public MdcRunnable(Runnable task) { this.task task; this.context MDC.getCopyOfContextMap(); } Override public void run() { MDC.setContextMap(context); try { task.run(); } finally { MDC.clear(); } } }消息队列的消费端同样要注意消费开始时要从消息头里取出上游透传的 TraceId 塞进当前线程而不是自己重新生成一个。只有全链路透传同一个 ID日志才能串成一条线。这一条做对了排障效率至少翻一倍。4.2 从指标反推通信瓶颈的三条经验有了 TraceId 和基础监控指标排障会快很多。三条经验分享给大家。第一条看耗时构成。如果你发现服务自身 CPU 消耗很低但整体 RT 很高八成是下游调用占了主要时间。这时候顺着调用链看下游每一个节点的耗时通常会有某个下游接口的 p99 很高。再往下挖一层很可能某个依赖查了慢 SQL或者调了外部 API 被限流。不要急着优化自己服务的代码先把耗时分布看清楚。第二条区分平均延迟和尾部延迟。平均 200ms 但 p99 飙到 2 秒典型特征是大多数请求很快少数请求特别慢。尾部延迟的来源往往是线程池排队请求量升高时少量请求滞留在队列里等线程表现出来是 p99 偏高但平均值不太明显。这时要看线程池活跃数、队列长度和下游慢调用而不是服务整体负载。只看平均值会掩盖问题必须把分位数的监控建起来。第三条连接池活跃数逼近上限是重要预警信号。很多系统卡顿不是 CPU 不够而是连接池耗尽。连接池默认值往往是拍脑袋定的流量一涨就拦在池子外面排队。当你看到某个服务的线程等待时间变长、数据库连接活跃数持续接近 max 时优先看下游有没有慢 SQL 拖住了连接释放再考虑扩容连接池。盲加连接池配置不是办法慢查询才是病根。4.3 一个值得提前投入的日志规范最后聊一个大家不太当回事、但实际价值极高的事情日志规范。系统间通信排障最怕的不是没有日志而是每个系统的日志格式五花八门。TraceId 字段叫 trackingId另一个系统叫 requestId时间戳时区对不上聚合的时候根本匹配不了。即使链路追踪通了也会卡在字段对不上这一步还得对着不同格式的日志做正则匹配。我们的做法是把全链路日志格式统一成一个 JSON schema时间戳、服务名、实例 IP、TraceId、SpanId、业务 ID、方法名、耗时、状态码。每个系统预留相同字段名跨系统只透传公共字段。这个投入看起来不起眼但通信类故障一旦出现你能在几分钟内用一个 TraceId 把相关日志全部拉出来而不是花几十分钟对着时间猜调用顺序。强烈建议每个做系统间通信架构的团队先把这件事咬牙做完再考虑更花哨的方案。5. 消息队列不是银弹这三类场景我会拒绝异步化5.1 强实时性要求高的交互链路写到这里必须给异步化泼点冷水。前面讲了事务消息、最终一致性和消费端设计但并不是所有场景都适合换到消息队列。最典型的就是强实时性要求高的交互链路。用户在前端点了按钮、扫了脸、确认了支付系统需要在几百毫秒内把结果告诉用户这种场景不能用异步。比如登录风控、支付结果确认、实名认证校验每一步的结果都直接影响用户能不能进行下一个操作。异步化之后你无法确定下游什么时候消费完用户端只能转圈等待体验直接崩掉。有人会想用“异步加前端轮询”来缓解但在强交互场景下轮询本身也是一套复杂度还要保证查询结果的时效和一致性。如果你发现业务逻辑必须在有限时间内拿到下游明确结果老老实实用同步 RPC。异步削峰最合适的场景是那些不需要立刻得到结果的后台任务比如报表生成、数据核对、消息推送。异步化解决的是宽限时间内的吞吐和削峰问题而不是解决“用户就要结果”的实时问题。5.2 事务边界需要跨系统强一致时消息队列的最终一致性本质上允许某一个时间段内系统之间状态不一致。但对于账务类、结算类、对账类的强一致场景这个窗口期极难接受。你给用户扣了款但下一跳流程还没有抓到支付结果用户余额出现了短暂的不一致客服那边可能瞬间收到好几单投诉。本地消息表和事务消息能保证消息不丢但并不能保证业务操作之间的强一致和顺序性也无法替代分布式事务与对账补偿机制。这种场景下需要在“强一致等待”和“最终一致补偿”之间做权衡。如果两个系统之间的状态偏差可以接受在一个秒级窗口内最终收敛可以考虑最终一致如果要求一个动作必须在前一个动作成功后才能执行且任何时刻都不能出现中间状态那 MQ 就不是合适的方案。判断标准不是“哪个架构先进”而是业务对时间一致性的容忍度。先画出业务顺序图凡是状态流转不能被中断的链路都不要轻易异步化。5.3 消息顺序性要求极高的业务还有一种场景就是消息顺序性要求极高的业务。交易流水、订单状态机、库存预占释放这些流程如果消息乱序业务状态直接错乱。让 MQ 保证全局顺序的代价非常大通常要落到单分区而单分区意味着消费并发度被限制到了一你又回到了吞吐瓶颈。实际可行的方案是局部有序把需要有序的同一维度消息比如同一个订单 ID 的所有消息通过固定的分区键路由到同一个分区。这样不同订单分散到不同分区并行处理单个订单内部仍然是顺序消费。如果你发现自己为了顺序性把整个队列收敛到单分区那就需要重新审视这条链路是不是真的适合用 MQ。很多时候单机同步处理加本地状态流转比强行上消息队列简单得多。做架构的人要沉得住气不是所有流量都必须削峰也不是所有链路都必须异步化。选通信方式之前先想清楚业务能不能接受短暂的不一致这就是我一路踩坑之后最想强调的一句话。