SPRINGCLOUD五大组件及相关注解整理

一、服务注册&发现——Netflix Eureka

a.微服务调用过程

1.注册中心：提供微服务的注册与发现。
说到分布式系统这里不得不提一下“CAP原则“：CAP原则又称CAP定理，指的是在一个分布式系统中，一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance）。CAP 原则指的是，这三个要素最多只能同时实现两点，不可能三者兼顾。而这个“P”是分布式系统中必备的，eureka的原则是“AP”，它保证了服务的最终一致性！
2.微服务的调用过程：

1）服务注册：服务A启动时向注册中心eureka注册自己相关的服务信息（应用名、ip端口等相关信息）；

2）服务续约：Eureka客户端会每隔30秒发送一次心跳来进行服务续约。通过续约来告知Eureka服务器该客户端仍然存在，希望服务器不要剔除自己。告诉服务器自己还活着；

3）服务下线：Eureka客户端在程序关闭时想Eureka服务器发送取消请求。发送请求后，该客户端实例信息将从服务器的实例注册列表中删除。注意：这里所提到的服务下线是指客户端通过程序所实现的主动下线，而非异常情况下的服务不可用，异常情况将在后续做出相关说明；

4）“服务器1”在完成相关注册请求后会将自己服务中的注册信息同步到“服务器2”中，最终保持所有服务器中注册信息一致，当注册服务为集群模式时，需要将服务之间彼此注册、服务拉取等属性打开，完成彼此之间的服务注册、拉取、心跳监控：

register-with-eureka: true #向注册中心注册自己
fetch-registry: true #拉取注册服务信息

；

5）拉取服务信息：服务B启动时，会向eureka注册中心拉取所有注册服务信息，并将信息缓存到本地内存中；

6）远程服务的调用：当服务B调用服务A时，可以通过本地缓存的服务信息最终完成对A服务的远程调用；

补充说明：

“失效删除”：在默认的情况下，当Eureka客户端连续90秒没有像Eureka服务器发送服务续约的心跳（Heartbeat），Eureka服务器就会将该服务实例从服务注册列表中删除，即剔除该服务。
问题：
当有些服务C因为地区的网络的不稳定的原因，而不能与注册服务器之间完成“服务续约”最终导致90秒后，服务C被eureka从注册中心剔除！90s后该地区网络又恢复正常了，而此时服务已被剔除！（最终只能重启服务C重新完成注册！）

针对以上情况，我们的Eureka为我们提供了一种新的机制“自我保护机制”，它的作用能使Eureka集群更加的健壮、稳定的运行。

“自我保护机制”：自我保护机制的工作机制是如果在15分钟内超过85%的客户端节点都没有正常的心跳，那么Eureka就认为客户端与注册中心出现了网络故障，Eureka Server自动进入自我保护机制。
1）自我保护机制被激活的条件
Renews (last min) < Renews threshold
两个参数：
Renews threshold ：Eureka Server 期望每分钟收到客户端实例续约的总数

Renews (last min) ：Eureka Server 最后 1 分钟收到客户端实例续约的总数。

具体位置如下图所示：

公式计算方法如下：
Renews threshold = 注册服务实例数量 * 每分钟心跳次数 * 阈值
注册实例数：我们具体的服务注册数量；
每分钟心跳次数：默认每30s一次心跳，一分钟就是60/30 = 2 次；
阈值：85%即，0.85；

Renews (last min) 服务器统计，可以在eureka页面查看；

针对微服务调用流程图计算举例：

Renews threshold = 4(服务A、注册服务1、注册服务2、服务B) * 2 * 0.85 = 6.8

即如果最后 1 分钟收到客户端实例续约的总数 < 6.8 ,最终eureka就会进行自我保护机制；自我保护机制发生后eureka将进行如下操作：
1）Eureka Server不再从注册列表中移除因为长时间没收到心跳而应该过期的服务。
2）Eureka Server仍然能够接受新服务的注册和查询请求，但是不会被同步到其它节点上，保证当前节点依然可用。
3）当网络稳定时，当前Eureka Server新的注册信息会被同步到其它节点中。

思考：
在自我保护模式下，因为Eureka Server不再从注册列表中移除长时间没收到心跳而应该过期的服务，这样就会导致访问这些服务，会出现大量的服务错误信息（有可能会因为大量的请求超时而拖垮正常的服务），此时我们因该怎么办呢？

我们可以通过Netflix Hystrix 来实现服务的熔断降级（此处不做讨论）！～后面会总结Hystrix相关知识！

b.eureka的工作原理

1.eureka工作原理流程图如下：

步骤：
1）服务A向eureka服务器发起注册；

2）eureka服务器将注册信息写入一级缓存registry中；

3）定时任务默认为每60s将registry中的注册服务信息同步到二级缓存readWriteCacheMap中；

4）定时任务默认为每30s将readWriteCacheMap中的注册服务信息同步到三级缓存readOnlyCacheMap中；

5）服务B通过定时任务每30s向三级缓存readOnlyCacheMap中拉取注册信息至eurekaClient客户端；

6）eurekaClient客户端通过定时任务每30s将信息同步给本地负载均衡器Ribbon，最终由Ribbon完成远程服务调用；

若服务B无法直接从三级缓存中获取到信息，则会向上至二级缓存中获取，若还获取不到，则直接向一级缓存中获取；

问题：若服务直接下线，客户端最长感知时间为多少？

步骤：
0s时服务未通知Eureka Client直接下线；
29s时第一次过期检查evict未超过90s；
89s时第二次过期检查evict未超过90s；
149s时第三次过期检查evict未续约时间超过了90s，故将该服务实例从registry和readWriteCacheMap中删除；
179s时定时任务从readWriteCacheMap更新至readOnlyCacheMap;
209s时Eureka Client从Eureka Server的readOnlyCacheMap更新；
239s时Ribbon从Eureka Client更新。
因此，极限情况下服务消费者最长感知时间将无限趋近240s。

面对如此长的时间，我们如何去解决？
。。。。。。。。。。。