分布式是把一个集中式系统拆分成多个系统，每一个系统单独对外提供部分功能，整个分布式系统整体对外提供一整套服务。对于访问分布式系统的用户来说，感知上就像访问一台计算机一样.
而分布式架构的具体实现有很多种，这其中包括了C/S架构、P2P架构、SOA架构、微服务架构.Serverless架构等
所以，微服务架构是分布式架构的一种
它将一个大型的应用程序拆分成一组小型、独立的服务单元，每个服务单元都可以独立部署、运行和扩展。每个微服务都专注于执行一个特定的业务功能，并通过轻量级的通信机制(如HTTP、RPC、MQ等)来相互调用。
微服务的目的是有效的拆分应用，实现敏捷开发和部署
比如把一个原来中心化的商城服务，拆分成产品服务、订单服务及用户服务，每一个服务把功能内聚，系统间通过远程调用解耦。实现高内聚低耦合
并且每一个服务都可以独立的提供子服务。并且他们有自己的应用、自己的存储，是独立的，互不影响的。
订单服务下单需要调用库存服务校验库存，库存扣减成功后需要调用订单服务接口进行通知，这就是循环依赖
危害：
1、流量放大: 因为系统之间存在循环依赖，那么就会导致本来下单系统可能只有100 QPS，但是因为存在循环依赖，就会导致这个QPS被放大，因为100个请求调用到订单服务，订单服务就有100个请求调到库存服务，而库存服务又有100个请求再调到订单服务。就导致订单服务有200的QPS了。无形中被放大了流量。
2、性能问题: 因为存在循环依赖，那么服务之间需要等待彼此的响应，就会无形中拖长请求的RT让接口性能变的更慢。
3、互相影响: 如果一个服务出现问题，这个问题可能会通过循环依赖影响到另一个服务。而一个服务中的错误可能通过依赖链传播到其他服务，增加了系统出现级联故障的风险。
4、发布困难: 每当一个服务需要更新时，我们需要同时考虑他依赖了谁以及谁依赖了他。一般是被依赖的应用先发布。但是因为系统间存在循环依赖，那么在上一个新的功能的时候需要发布时，就会带来很大的问题，那就是谁先发的问题，而谁先发都会有问题。
?如何解决呢
重新设计：一个系统又在上游，又在下游，那定是设计的不合理，所以需要考虑做重新设计
消息通信：把直接接口调用改为消息通信，实现解耦
引入共享服务：当出现循环依赖时候，可以考虑将共享部分抽取出来作为一个共享库，然后由各个相关服务共同引用这个库
限流：限流的目的是控制流量的并发量，常见的限流算法：漏桶算法、令牌桶算法、计算器算法、滑动时间窗口算法
熔断：熔断是为了防止系统因某个服务的故障而整体崩溃，类似于电路的熔断器。在检测到下游服务异常时，自动停止向该服务发送请求，并在一定时间后尝试恢复，举个例子，当电商平台上用户支付时，收银台发现某个支付渠道，如微信支付失败率突增，超时严重，那么就可以临时把这个支付方式熔断掉。
降级：是当系统负载过高时，主动关闭一些非核心功能，以确保核心功能的正常运行。一般用于在系统资源有限或响应时间过长时，通过降低服务质量保障核心服务