spring cloud 记录

服务注册中心：

失效提除：

有些时候，服务不一定会正常下线，内存溢出、网络故障等原因使得服务不能正常工作，注册中心也没有收到下线的请求，为了把这些不能正常

提供服务的实例提除，Eureka Server 在启动时候会创建一个定时任务，默认每隔（60秒）一个时间将当前清单中超时（90秒）没有续约的服务

提除出去。

自我保护机制

默认情况下，如果EurekaServer超过90秒没有接收到某个服务实例的心跳，将会注销该实例。但是，会存在由于网路波动而导致微服务实例和

EurekaServer无法正常通信，实际上这个实例是正常运行的，不应该去注销这个实例。针对这种情况Eureka提供了自我保护机制的方案。当

EurekaServer节点在短时间内丢失过多客户端时（15分钟内超过85%的节点都没有正常的心跳），那么EurekaServer就会认为客户端和注册中

心出现了网络问题，这个EurekaServer节点就会进入自我保护模式。一旦进入自我保护模式，EurekaServer就会保护服务注册表中的信息，

不再删除注册表中的信息。

自我保护模式中：

EurekaServer服务依旧提供注册功能，但是不再注销任何服务实例。当它收到心跳数重新恢复到阈值以上时，该EurekaServer服务就会退出自

我保护模式。宁可保留错误的服务信息，也不会盲目注销任何可能健康的服务。

# 关闭自我保护模式，生产环境建议开启

enable-self-preservation: false

每个客户端节点启动后会主动向EurekaServce注册自己，并维持一个心跳链接。当需要和其他服务通信时，会向EurekaServce询问目标服务的地

址进行访问。

 

Eureka对比Zookeeper

CAP原则

Consistency： 一致性；

Availability： 可用性；

Partition tolerance： 分区容错性；

CAP 原则指的是，在一个人分布式系统中这三个要素最多只能同时实现两点，不可能三者兼顾，其中P分区容错性是必须要满足的。

Zookeeper

Zookeeper满足CP。在Zookeeper中master因网络故障和其他节点失联的时候，剩余节点会重新选举leader，耗时较长。选举期间整个zk集群

不可用，导致注册中心瘫痪 。

 

Eureka

Eureka满足AP。Eureka各个节点都是平等的，只要有一个节点正常运行就可以提供注册和查询服务(保证可用性A)，只不过查到的信息可能不是最

新的(不保证强一致性C)。eureka会首先保证可用性，在一定程度内再去进行一致性的同步。

 

=================================================================

 

服务提供者：

注册：

服务提供者，在启动时候发送REST请求的方式将自己注册的eureka Server上，同时带上了自身服务的一些元数据信息，Eureka Server 接收到这个

REST请求之后，将元数据的信息存储在一个双层结构map中， 其中第一层的的key是服务名，第二层的key是具体的服务的实例名。

 

同步：

多个注册中心情况下，服务提供者分别注册到注册中心上，由于服务注册中心之间因为相互注册为服务，当服务提供者发送注册请求到一个服务注册中心

时，它会将该请求转发给集群中相连的其他注册中心，从而实现注册中心之间的服务同步。通过服务同步，俩个服务提供者的服务信息就可以通过这俩台

服务注册中心中的任意一台获取到。

 

续约（Renew）：

在注册服务之后，服务提供者会维护一个心跳用来持续告诉Eureka Server ，{服务存在}，以防止Eureka Server 将该服务实例从服务列表中排除出去

eureka.instance.lease-renewal-interval-in-seconds=30 : 参数用于定义服务续约任务的调用时间默认30秒

eureka.instance.lease-expiration-duration-in-seconds=90: 参数用于定义服务失效的时间，默认90秒。

 

========================================================================

 

服务消费者：

获取服务：

消费者启动，会发送REST请求去注册中心，来获取上面注册的服务清单，为了性能，eureka Servier 会维护一份制度的服务清单返回给客户端，

同时该缓存清单30秒更新一次。

调用：

获取清单后，通过服务名可以获得具体提供服务的实例名和该实例的元数据信息。客户端根据自己的需要决定具体调用哪个实例。

对于实例选择Eureka 有region（地理上的分区。亚洲、华北地区）、zone（具体机房： region 为北京，有俩个机房： zone1；zone2）的概念

，一个region包含多个zone，每个服务客户端被注册到zone中，所以每一个客户端对应一个Region和一个zone，在服务调用时候，优先访问同处

一个zone中的提供方，若访问不到，就访问其它zone。

下线：

当服务进行正常关闭操作时候，它会触发一个服务下线的REST请求给eureka Server，告诉服务注册中心，中心收到请求后将该服务的状态置为

下线（down），并且把下线时间传播出去。