3. 跨板块业务依赖关系梳理

跨板块联动失效之所以难以排查，根本原因往往不在某个板块内部，而在于板块之间的依赖关系没有被显式梳理出来。一个订单履约异常，可能既不是订单板块的代码问题，也不是库存板块的接口问题，而是两者之间那条"下单后异步扣减库存"的数据依赖在高峰期出现了延迟堆积。因此，风险识别的第一步不是找故障，而是把依赖关系画清楚。

本节以一个典型的电商平台为例：平台包含交易板块（下单、支付）、库存板块（可售库存、锁定库存）、履约板块（拣货、发货）、结算板块（对账、分账）四个业务板块。我们围绕"用户下单到订单发货"这一真实链路，分别梳理服务依赖、数据依赖与组织协作依赖三类关系，并从中识别关键依赖节点。

一、三类依赖的区分与梳理方法

服务依赖指一个板块的运行时行为需要同步或异步调用另一个板块的服务接口才能完成。梳理时关注调用方向、调用方式（同步 RPC / 异步消息）、超时与重试策略。例如交易板块创建订单时同步调用库存板块的"锁定库存"接口，锁定成功才允许支付；支付成功后通过消息队列通知履约板块生成发货单。这类依赖决定了故障的传播路径——同步调用会把下游的延迟直接传导为上游的失败。

数据依赖指板块之间通过共享数据或数据同步形成的事实约束。它比服务依赖更隐蔽，因为即使接口全部正常，数据不一致仍会导致业务错误。典型例子是：库存板块的可售库存由交易板块的订单状态驱动扣减，而结算板块的对账数据又依赖履约板块的发货回传。数据依赖要梳理清楚三件事：谁是数据的产生方（源）、谁是消费方、同步是实时还是批量、延迟容忍度是多少。

组织协作依赖指跨板块问题处理时涉及的人员与职责关系。例如库存异常需要交易与库存两个团队共同定位，发货延迟的对客解释需要履约与客服协同。组织依赖不体现在系统调用图上，却直接决定故障发生时的响应速度，是联动失效复盘中最容易被忽略的一环。

二、依赖图谱与关键节点识别

将上述三类依赖叠加到同一张图上，就得到板块间依赖图谱。下图以四个板块为主体，用不同线型区分服务调用、数据流向与协作关系，并标出识别出的关键依赖节点。

图中三个红色节点即为关键依赖节点，它们的共同特征是：位于多个板块的交汇处、被至少两条链路共同依赖、且一旦失效会同时影响上下游。具体来看：

• 节点①：库存锁定接口。它是交易与库存之间唯一的同步强依赖，超时设定为 800ms。一旦库存板块响应变慢，交易侧下单成功率会直接下降，且重试可能造成重复锁定。识别依据是"同步调用 + 无降级方案 + 高并发入口"。
• 节点②：支付成功消息。它是交易到履约的异步枢纽，消息丢失或重复消费会导致"已付款不发货"或"重复发货"。识别依据是"异步链路 + 消息可靠性依赖 + 业务不可逆"。
• 节点③：发货回传数据。它同时被结算对账和客服查询消费，回传延迟会造成对账差异和客诉。识别依据是"一对多数据消费 + 批量时效约束"。

三、把图谱落到可执行的依赖清单

图谱画完后，必须沉淀为可维护的依赖清单，否则一次梳理只能解决一次问题。清单至少应包含依赖名称、上游板块、下游板块、依赖类型、调用方式、时效要求、失效影响与责任人。以下为示例片段（参数为教学假设值）：

维护清单时有两条实用原则。其一，每条依赖必须有唯一责任人，跨板块问题最怕"都相关、都不管"；其二，时效要求要写成可观测的数值，如"≤800ms""≤5s 投递"，这样才能在监控中设置告警阈值，把依赖风险从"知道有"变成"能发现"。

需要强调的是，依赖图谱不是一次性文档。板块拆分、接口改造、消息中间件升级都会改变依赖结构，关键节点也可能转移。建议在每次跨板块故障复盘后回看图谱，确认是否有新的关键节点出现、原有节点的时效要求是否仍然成立，让依赖梳理真正成为风险识别的持续输入。