spring-cloud原理讲解

Eureka

首先，让我们深入了解服务注册中心 Eureka，它在Spring Cloud技术栈中扮演着至关重要的角色。

服务注册与发现是 Eureka 中的核心功能。举例来说，假设我们有一个服务消费者服务A，以及两个服务提供者服务B的节点。在启动时，服务A和服务B都会向注册中心注册自己的服务。

服务A会定期从注册中心拉取服务注册表信息到本地，这个过程被称为服务发现，默认情况下是每30秒执行一次。当然，你也可以根据需要进行配置，以优化这个过程

看下图

实际上，在服务拉取服务注册表时，客户端并不直接从Eureka的服务注册表中获取数据。

Eureka采用了二级缓存机制，第一级是ReadOnly缓存，第二级是ReadWrite缓存。

客户端会直接从ReadOnly缓存中读取注册表信息。

当服务进行注册时，首先会将注册信息写入服务注册表。一旦服务注册表更新，就会立即将数据同步到ReadWrite缓存中。

但是，什么时候会将ReadWrite缓存中的数据同步到ReadOnly缓存呢？

这里有一个定时任务，会定期检查ReadWrite缓存是否与ReadOnly缓存不一致，如果不一致，就会将数据同步到ReadOnly缓存中。

默认情况下，这个定时任务的执行间隔是30秒，当然你也可以根据需要进行配置

这种做法的好处在于优化了并发读写的冲突。当服务注册时，同时有服务进行注册表信息的读取时，会存在频繁的读写加锁操作。这样的情况下，写操作会阻塞读操作，导致性能下降。因此，我们需要避免大量读写操作同时访问同一张表。

通过采用二级缓存的机制，大部分读操作都可以直接访问ReadOnly缓存，从而避免了频繁的读写加锁操作。而定时将ReadWrite缓存中的数据同步到ReadOnly缓存，确保了数据的及时更新

心跳与故障检测

服务注册中心的另一个重要功能是心跳与故障检查，其目的是确定已注册的服务是否仍然处于活动状态。

Eureka会启动一个定时任务，周期性地检查服务的心跳状态，默认间隔也是30秒，当然你也可以自行设置。

如果一台机器在约定的时间间隔内未上报自身的状态，Eureka就会将该机器从注册表中剔除，并将此更新同步到ReadWrite缓存中

Hystrix

在微服务架构中，服务调用频繁，一个服务的故障可能引发整个调用链的故障，导致服务雪崩。

Hystrix应运而生，旨在解决这一问题。它提供了服务降级、服务熔断、线程和信号隔离、请求缓存、请求合并以及服务监控等功能。

Hystrix采用了舱壁模式实现线程池的隔离，为每个依赖服务创建独立的线程池。这意味着即使某个依赖服务出现高延迟，也只会影响到该依赖服务的调用，而不会拖慢其他依赖服务

Zuul

当请求到达Zuul网关时，它会根据配置的请求路径与服务的对应关系直接将请求转发给匹配的服务。然后，Zuul会使用Ribbon从本地Eureka缓存列表中获取一台服务的机器，并通过负载均衡算法选择其中一台。最终，Zuul会将请求直接发送到选定的机器上，使用HTTP通信框架进行通信