微服务之间出现 A -> B -> C -> A 的循环依赖（Circular Dependency），通常是架构设计不合理或领域边界划分不清的信号。这是一种架构“坏味道”（Anti-pattern）。 如果不及时治理，会导致以下严重后果： 1. 无限递归/死循环：如果缺乏终止条件，请求会在网络中无限传递，耗尽资源。 2. 分布式死锁：如果调用是同步阻塞的，容易造成线程池耗尽，导致系统雪崩。 3. 部署耦合：A 启动依赖 B，B 依赖 C，C 又依赖 A，导致无法独立部署或重启。 以下是治理循环依赖的几种常见方案，按推荐程度从高到低排列： --- 1. 架构分层与下沉（最推荐：重构） 循环依赖通常意味着 A 和 C 之间存在“共同依赖”的逻辑，或者 C 承担了本该属于底层服务的职责。 方案 A：公共服务下沉（Extraction） 做法：将 A 和 C 中相互依赖的业务逻辑或数据，剥离出来形成一个新的基础服务 D。 结果：A -> B -> C，同时 A -> D，C -> D。 优点：彻底打破环状结构，符合分层架构原则（上层调用下层，下层不反调上层）。 方案 B：服务合并（Me...
播面