spring cloud eureka 的服务治理机制

一、基础架构

  构建Eureka服务治理有三个核心角色：服务注册中心、服务提供者和服务消费者。

• 服务注册中心（Eureka Server）：Eureka提供的服务端，提供服务注册和发现的功能；
• 服务提供者：提供服务的应用，遵循Eureka通信机制的应用。它将自己注册到Eureka Server中，以供其他应用发现；
• 服务消费者：消费者应用从服务注册中心获取服务列表，从而让消费者知道可以从哪个服务提供者调用其所需的服务；

很多时候，客户端既是服务提供者也是服务消费者

二、要素

        在高可用的集群中，都会创建两个或两个以上的服务注册中心，他们之间进行相互注册，使得各自所管理的服务列表在各个注册中心进行信息同步。

三. 服务治理机制

 3.1 服务提供者

   3.1.1 服务注册

服务提供者在启动的时候会发送REST请求的方式将自己注册到Eureka Server服务上，同时带上自身的一些元数据信息。Eureka Server 接受到REST请求之后，将元数据信息存储到一个双层Map中，其中第一层的key是服务名，第二层的key是具体的实例名，value值有挺多信息的，其中就有点击实例需要进行操作的url （value值不太清楚，个人猜测应该url链接），Eureka服务端的信息面板中一个服务有多个实例的情况，这些内容就是以双层Map形式存储的。

在服务注册时，需确认一下 eureka.client.register.with.eureka=true参数是否正确，该默认值为false，若设置为false 将不会启动注册操作。

   3.1.2 服务同步

两个服务提供者分别注册到两个不同的注册中心上，也就是说他们的信息分别被两个注册中心所维护，由于服务注册中心之间因相互注册为服务，所以当服务提供者发送一个请求到某个服务注册中心时，该服务注册中心也会将请求转发给集群中相连的其他注册中心，从而实现了注册中心的服务同步。通过服务同步，两个服务提供者的服务信息就可以通过这两台服务注册中心的任意一台获取。

   3.1.1 服务续约

在注册完服务之后，服务提供者会维护一个心跳用来持续告诉Eureka Server 我还活着，以防止Eureka Server 剔除任务 将该服务实例从服务列表中排除出去，我们称该操作为“服务续约”
服务续约有两个重要的属性：
eureka.instance.lease-renewal-interval-in-seconds=30
表示服务续约的调用间隔时间默认为30秒
eureka.instance.lease-expiration-duration-in-seconds=90
表示服务失效的时间为默认90秒

 3.2 服务消费者

   3.2.1 获取服务

当我们启动服务消费者的时候，它会发送一个REST请求到注册中心，来获取上面注册的服务清单，为了性能考虑，Eureka Server 会维护一份只读的服务清单返回给客户端，同时该缓存清单会每隔30秒更新一次
所以获取服务是服务消费者的基础，必须确保
eureka.client.fetch-register=true 默认为ture
若想修改获取服务清单的更新时间修改
eureka.client.register-fetch-interval-seconds=30 的参数进行修改，默认30秒

   3.2.2 服务调用

服务消费者获取服务清单后，通过服务名获取具体的实例名和该实例的元数据信息，因为有这些服务的信息，所以客户端可以根据自己的需求决定具体调用哪个实例，在ribbon中默认采用轮询的方式进行调用，从而实现客户端的负载均衡。
对于访问实例的选择 Eureka 中有Region和Zone的概念，一个Region中包含多个Zone，每个服务客户端会注册到一个Zone中，所以每个客户端对应一个Region和一个Zone，在服务调用时优先访问同一个Zone中的服务提供方，若访问不到就调用其他的Zone。

   3.2.3 服务下线

在服务运行过程中必然会面临关闭或重启某个实例的情况，在关闭时我们不希望客户端继续调用关闭的实例，所以当服务正常关闭时，会触发一个REST请求给Eureka Server 告诉服务注册中心 我要下线了 服务端接收到请求之后，将该服务状态设置为(DOWN)并把该下线事件传播出去。

 3.3 服务注册中心

   3.3.1 失效剔除

有时候，服务实例并不一定会正常下线，可能由于内存溢出，网络故障等原因导致服务不能正常工作，而服务注册中心并没有收到服务下线请求，为了从服务列表中清除那些不可用的服务实例，Eureka Server 在启动的时候会创建一个定时任务，默认每隔60秒将清单中超时90秒的没有续约的服务剔除出去。

   3.3.2 自我保护

当我们在本地调试基于Eureka的程序时，基本上都会遇到这样一个问题，在注册中心信息面板中出现红色的警告信息：

EMERGENCY! EUREKA MAY BE INCORRECTLY CLAIMING INSTANCES ARE UP WHEN THEY’RE NOT. RENEWALS ARE LESSER THAN THRESHOLD AND HENCE THE INSTANCES ARE NOT BEING EXPIRED JUST TO BE SAFE.

实际上就是触发了Eureka Server的自我保护机制，因为服务注册到Eureka Server之后会维护一个心跳连接，告诉Eureka Server我还活着，Eureka Server在运行期间会统计失败的比列在15分钟内低于85%的，如果出现低于的情况（在单机调试的时候跟容易满足，实际在生产环境上通常是由于网络不稳定导致），Eureka Server会将这些服务实例保护起来，让这些服务不过期，尽可能保护这些注册信息，但是在保护期间客户端很容易拿到实际已经不存在的服务实例，会出现失败的情况，所以客户端必须要有容错机制，比如使用请求重试，断路器等机制。
既然本地吊事容易触发注册中心自我保护机制 可以通过配置属性
eureka.server.enable-self-preservation=false 参数来关闭保护机制，以确保服务注册中心可以将不可用的服务实例正确剔除。

启动自我保护后此时会出现以下几种情况：
1、Eureka Server不再从注册列表中移除因为长时间没收到心跳而应该过期的服务。
2、Eureka Server仍然能够接受新服务的注册和查询请求，但是不会被同步到其它节点上，保证当前节点依然可用。
3、当网络稳定时，当前Eureka Server新的注册信息会被同步到其它节点中。
因此Eureka Server可以很好的应对因网络故障导致部分节点失联的情况，而不会像Zookeeper那样如果有一半不可用的情况会导致整个集群不可用而变成瘫痪。