保密原因，这里不透露系统名称
背景
存在A和B两个系统，A系统的核心实体entityA与B系统的核心实体entityB是 1 对多的关系，即：entityA : entityB ~ 1 : N
问题出现
- 服务A和B的请求数持续保持异常的高位
- 这两个服务的流量高于常规情况，且当时没有特殊业务活动会明显提升UV
- 数据库压力持续上升，并最终保持连接数和活跃连接数达到 100%
问题检查&解决
- 对于与数据库保持异常高连接数的微服务，执行熔断，暂时缓解数据库压力，稳定其他微服务正常运行
- 根据异常的微服务反查逻辑，发现循环依赖问题
- 随机提取了一个前述存在循环依赖问题的接口的日志跟踪id(trace id)，发现该trace id下同时记录了对两个接口的多个不同时间点(毫秒差距）的请求日志，说明该请求确实在这两个接口间循环依赖
- 发布更新
- 恢复被熔断的服务
为什么直到数据库压力被打满才出现接口超时告警？
如果有循环依赖，应该测试阶段就已经发现接口请求失败？
这里原因有二
- web端接口超时配置是5min，rpc接口超时配置是1s
- a系统和b系统针对对应依赖接口的出错都有容错机制，会自动返回其他正常加载的信息
长期解决方案
- 在业务逻辑层面，就尽量避免两个系统互相依赖，这里需要结合业务逻辑来具体分析、具体解决
- 如果两个微服务互相依赖，要考虑这两个微服务合并是否更合理
- 如果无法合并（例如两个系统确实不属于一个领域边界；不属于一个团队管理），则将逆流的逻辑（不符合主数据流的逻辑）作为异步逻辑，与核心代码保持松耦合。这里结合业务逻辑具体分析、具体解决
- 需要持续 review 微服务架构，及时发现循环依赖并视具体情况而处理
- 基于框架已有的流量染色能力，在框架层面增加路由计数逻辑，当计数超过一定阈值时发起告警（具体阈值视情况而定
- 这里参考路由器回环检测
- 对于存在外部服务依赖的接口，上线前做好充分压测，以检查高压环境会产生哪些连锁反应？降级熔断是否能生效？
- 面向其他微服务的与面向web端的rpc接口应该分开定义，面向其他微服务的接口，底层应该尽量不再依赖其他微服务，否则出现链路大于等于3的循环依赖(a依赖b，b依赖c，c又依赖a）很难被发现
思考
在微服务架构中，由于不同微服务由不同的开发人员，甚至由不同团队负责。对于产品同学而言，他们几乎不会关注循环依赖会引发什么问题，对他们而言，正确的思维方式是从用户角度出发，如何能方便用户获取信息、操作流程。因此，需要研发同学在开发过程中及时察觉其中可能出现风险并规避。
例如上述方案5作为原则，那么即使不刻意审查技术方案，也能避免大部分的循环依赖情况
补充说明
其实，这次问题还同时带出了慢查询问题，导致从库压力保持100%。我们在发现循环依赖问题前就发现了这个问题并解决，及时降低了数据库压力。考虑到这个问题比较容易发现（数据库慢查询监控），且为了便于与循环依赖问题分开讨论，没有在上面描述。