Spring Cloud原理详解
之前一直在看《spring cloud微服务实战》，最近又看了架构笔记的《拜托！面试请不要再问我spring cloud底层原理》，对spring cloud的主要组件的原理有了更深的理解，特地做一下总结
一、spring cloud核心组件：eureka
(1)netflix eureka
1）、eureka服务端：也称服务注册中心，同其他服务注册中心一样，支持高可用配置。如果eureka以集群模式部署，当集群中有分片出现故障时，那么eureka就转入自我保护模式。它允许在分片故障期间继续提供服务的发现和注册，当故障分片恢复运行时，集群中其他分片会把它们的状态再次同步回来
2）、eureka客户端：主要处理服务的注册与发现。客户端服务通过注解和参数配置的方式，嵌入在客户端应用程序的代码中，在应用程序运行时，eureka客户端想注册中心注册自身提供的服务并周期性地发送心跳来更新它的服务租约。同时，它也能从服务端查询当前注册的服务信息并把它们缓存到本地并周期性地刷新服务状态
3）、eureka server的高可用实际上就是将自己作为服务向其他注册中心注册自己，这样就可以形成一组互相注册的服务注册中心，以实现服务清单的互相同步，达到高可用效果
(2)eureka详解
1）、服务提供者
a.服务注册
服务提供者在启动的时候会通过发送rest请求的方式将自己注册到eureka server上，同时带上了自己服务的一些元数据信息。eureka server接收到这个rest请求之后，将元数据信息存储在一个双层结构map中，其中第一层的key是服务名，第二层的key是具体服务的实例名
b.服务同步
两个服务提供者分别注册到了两个不同的服务注册中心上，也就是说，它们的信息分别被两个服务注册中心所维护。此时，由于服务注册中心之间因互相注册为服务，当服务提供者发送注册请求到一个服务注册中心时，它会将该请求转发给集群中相连的其他注册中心，从而实现注册中心之间的服务同步。通过服务同步，两个服务提供者的服务信息就可以通过这两台服务注册中心中的任意一台获取到
c.服务续约
在注册完服务之后，服务提供者会维护一个心跳用来持续告诉eureka server：“我还活着”，以防止eureka server的剔除任务将该服务实例从服务列表中排除出去，我们称该操作为服务续约
# 定义服务续约任务的调用间隔时间，默认30秒 eureka.instance.lease-renewal-interval-in-seconds=30 # 定义服务失效的时间，默认90秒 eureka.instance.lease-expiration-duration-in-seconds=90
2）、服务消费者
a.获取服务
当我们启动服务消费者的时候，它会发送一个rest请求给服务注册中心，来获取上面注册的服务清单。为了性能考虑，eureka server会维护一份只读的服务清单来返回给客户端，同时该缓存清单会每隔30秒更新一次
# 缓存清单的更新时间，默认30秒 eureka.client.registry-fetch-interval-seconds=30
b.服务调用
服务消费者在获取服务清单后，通过服务名可以获得具体提供服务的实例名和该实例的元数据信息。在ribbon中会默认采用轮询的方式进行调用，从而实现客户端的负载均衡
对于访问实例的选择，eureka中有region和zone的概念，一个region中可以包含多个zone，每个服务客户端需要被注册到一个zone中，所以每个客户端对应一个region和一个zone。在进行服务调用的时候，优先访问同处一个一个zone中的服务提供方，若访问不到，就访问其他的zone
c.服务下线
当服务实例进行正常的关闭操作时，它会触发一个服务下线的rest请求给eureka server，告诉服务注册中心：“我要下线了”。服务端在接收到请求之后，将该服务状态置为下线（down），并把该下线事件传播出去
3）、服务注册中心
a.失效剔除
eureka server在启动的时候会创建一个定时任务，默认每隔一段时间（默认为60秒）将当前清单中超时（默认为90秒）没有续约的服务剔除出去
b.自我保护
在服务注册中心的信息面板中出现红色警告信息：
该警告就是触发了eureka server的自我保护机制。eureka server在运行期间，会统计心跳失败的比例在15分钟之内是否低于85%，如果出现低于的情况，eureka server会将当前的实例注册信息保护起来，让这些实例不会过期，尽可能保护这些注册信息。但是，在这段保护期间内实例若出现问题，那么客户端很容易拿到实际已经不存在的服务实例，会出现调用失败的情况，所以客户端必须要有容错机制，比如可以使用请求重试、断路器等机制
# 关闭保护机制，以确保注册中心可以将不用的实例正确剔除（本地调试可以使用，线上不推荐） eureka.server.enable-self-preservation=false
二、spring cloud核心组件：ribbon
ribbon是一个基于http和tcp的客户端负载均衡器，它可以在通过客户端中配置的ribbonserverlist服务端列表去轮询访问以达到服务均衡的作用。当ribbon和eureka联合使用时，ribbon的服务实例清单ribbonserverlist会被discoveryenabledniwsserverlist重写，扩展成从eureka注册中心中获取服务端列表。同时它也会用niwsdiscoveryping来取代iping，它将职责委托给eureka来去定服务端是否已经启动
在客户端负载均衡中，所有客户端节点都维护着自己要访问的服务端清单，而这些服务端的清单来自于服务注册中心（比如eureka）。在客户端负载均衡中也需要心跳去维护服务端清单的健康性，只是这个步骤需要与服务注册中心配合完成
通过spring cloud ribbon的封装，我们在微服务架构中使用客户端负载均衡调用只需要如下两步：
- 服务提供者只需要启动多个服务实例并且注册到一个注册中心或是多个相关联的服务注册中心
- 服务消费者直接通过调用被@loadbalanced注解修饰过的resttemplate来实现面向服务的接口调用
三、spring cloud核心组件：fegin
fegin的关键机制是使用了动态代理
1）、首先，对某个接口定义了@feginclient注解，fegin就会针对这个接口创建一个动态代理
2）、接着调用接口的时候，本质就是调用fegin创建的动态代理
3）、fegin的动态代理会根据在接口上的@requestmapping等注解，来动态构造要请求的服务的地址
4）、针对这个地址，发起请求、解析响应
fegin是和ribbon以及eureka紧密协作的
1）、首先ribbon会从eureka client里获取到对应的服务注册表，也就知道了所有的服务都部署在了哪些机器上，在监听哪些端口
2）、然后ribbon就可以使用默认的round robin算法，从中选择一台机器
3）、fegin就会针对这台机器，构造并发起请求
四、spring cloud核心组件：hystrix
在微服务架构中，存在着那么多的服务单元，若一个单元出现故障，就很容易因依赖关系而引发故障的蔓延，最终导致整个系统的瘫痪，这样的架构相较传统架构更加不稳定。为了解决这样的问题，产生了断路器等一系列的服务保护机制
在分布式架构中，当某个服务单元发生故障之后，通过断路器的故障监控，向调用方返回一个错误响应，而不是长时间的等待。这样就不会使得线程因调用故障服务被长时间占用不释放，避免了故障在分布式系统中的蔓延
hystrix具备服务降级、服务熔断、线程和信号隔离、请求缓存、请求合并以及服务监控等强大功能
hystrix使用舱壁模式实现线程池的隔离，它会为每一个依赖服务创建一个独立的线程池，这样就算某个依赖服务出现延迟过高的情况，也只是对该依赖服务的调用产生影响，而不会拖慢其他的依赖服务
五、spring cloud核心组件：zuul
spring cloud zuul通过与spring cloud eureka进行整合，将自身注册为eureka服务治理下的应用，同时从eureka中获得了所有其他微服务的实例信息
对于路由规则的维护，zuul默认会将通过以服务名作为contextpath的方式来创建路由映射
zuul提供了一套过滤器机制，可以支持在api网关无附上进行统一调用来对微服务接口做前置过滤，已实现对微服务接口的拦截和校验
六、小结
- eureka：各个服务启动时，eureka client都会将服务注册到eureka server，并且eureka client还可以反过来从eureka server拉取注册表，从而知道其他服务在哪里
- ribbon：服务间发起请求的时候，基于ribbon做负载均衡，从一个服务的多台机器中选择一台
- feign：基于feign的动态代理机制，根据注解和选择的机器，拼接请求url地址，发起请求
- hystrix：发起请求是通过hystrix的线程池来走的，不同的服务走不同的线程池，实现了不同服务调用的隔离，避免了服务雪崩的问题
- zuul：如果前端、移动端要调用后端系统，统一从zuul网关进入，由zuul网关转发请求给对应的服务
总结
以上就是这篇文章的全部内容了，希望本文的内容对大家的学习或者工作具有一定的参考学习价值，谢谢大家对的支持。如果你想了解更多相关内容请查看下面相关链接