✅什么是微服务的循环依赖？
典型回答
微服务之间的循环依赖是指在微服务架构中，两个或多个服务相互依赖对方的情况。这里的依赖其实就是互相调用。两个微服务互相调用，A调用B，B又反向调用A，或者A调用B，B调用C，C调用A，这都是循环依赖。
举个例子，假设我们有两个微服务：订单服务（Order Service）和库存服务（Inventory Service）。
- 订单服务（Order Service）：
- 当用户下单时，订单服务需要调用库存服务来检查所需商品的库存。
- 如果库存充足，订单服务会继续处理订单。
- 库存服务（Inventory Service）：
- 当库存服务更新库存时，它需要通知订单服务更新订单状态。
- 为此，库存服务会调用订单服务的一个接口。
这里的循环依赖出现在：
- 订单服务依赖库存服务来验证库存。
- 库存服务依赖订单服务来更新订单状态。
我们在做设计的时候应该尽量的避免循环依赖，因为循环依赖会导致以下这些问题：
1、流量放大：因为系统之间存在循环依赖，那么就会导致本来下单系统可能只有100 QPS，但是因为存在循环依赖，就会导致这个QPS被放大，因为100个请求调用到订单服务，订单服务就有100个请求调到库存服务，而库存服务又有100个请求再调到订单服务。就导致订单服务有200的QPS了。无形中被放大了流量。
2、性能问题：因为存在循环依赖，那么服务之间需要等待彼此的响应，就会无形中拖长请求的RT，让接口性能变的更慢。
3、互相影响：如果一个服务出现问题，这个问题可能会通过循环依赖影响到另一个服务。而一个服务中的错误可能通过依赖链传播到其他服务，增加了系统出现级联故障的风险。
4、发布困难：每当一个服务需要更新时，我们需要同时考虑他依赖了谁以及谁依赖了他。一般是被依赖的应用先发布。但是因为系统间存在循环依赖，那么在上一个新的功能的时候需要发布时，就会带来很大的问题，那就是谁先发的问题，而谁先发都会有问题。
主要就是以上这几个问题，所以我们平时需要尽量的避免循环依赖。
扩展知识
如何解决？
首先，遇到循环依赖的问题，第一件事就是考虑设计的不合理性，一般来说系统会有自己的明确的职责，并且一张架构图中，一个系统一定是有属于他自己的位置的，一个系统又在上游，又在下游，那一定是设计的不合理，所以需要考虑做重新设计。
其次，像前面我们提到的例子，库存需要通知订单更新状态，这个过程我们可以把服务调用改成消息通信，通过异步消息来解耦调两个系统之间的相互依赖。这样就可以避免互相影响。
另外，比较常用的一种方式，那就是引入一个共享库，当出现循环依赖时候，可以考虑将共享部分抽取出来作为一个共享库，然后由各个相关服务共同引用这个库。通过在循环依赖的两个微服务中引用共享库，而不是直接调用对方的接口来操作数据。
上面的共享库，也可以做成一个共享服务（或者叫中介服务），你俩不是互相依赖么，那么干脆我单独搞一个服务出来，你们都直接依赖他而不是做互相依赖。比如我们实际业务中就有一个台账系统，我们会把各个业务流水都写到台账中，所以当我们上游系统之间需要查询数据的时候，就可以直接去台账查，而不需要依赖其他的系统。而台账作为最下游系统，他也不会调用任何其他服务，他最多会提供消息给别的系统。
扩展知识
如何识别循环依赖
要解决循环依赖，首先需要识别出来。那么具体如何识别呢？
首先，一个一劳永逸的方式，就是有一个明确地架构图，架构图中明确的标注出来各个系统处于什么位置，上游系统都有谁，下游系统都有谁，依赖只能是从上到下的，而不能是从下到上的。有了这样一张图，大家就都知道，我自己的系统处于什么位置，我可以依赖谁，谁可以依赖我了。
如我在网上找的下面这张图，基本上就是一个很明确的从上到下的调用关系。
其实就是可以通过链路追踪来看是否存在循环依赖，当一个调用的trace中，一个应用被调用多次，那么可能就会存在循环依赖的问题。
还有就是通过各种评审来发现了，比如我们前面提到的，循环依赖会导致发布过程存在谁先发的问题，这个问题在发布评审时是一定可以暴露出来的。
所以，在设计评审，发布评审，TC评审，以及代码评审的时候，需要关注一下是否存在着循环依赖的问题。