SpringCloud Eureka服务治理机制

1、基础架构

        构建Eureka服务治理有三个核心角色：服务注册中心、服务提供者和服务消费者。上图就是这三个角色之间的通讯工做架构图。

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

2、各核心要素

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

服务注册中心

一、失效剔除

        有时候服务实例异常（内存溢出、网络故障等）下线， 此时服务注册中心并无收到“服务下线”的请求，为了从列表中将这些没法提供服务的实例剔除，Eureka Server在启动时会建立一个定时任务，默认每隔一段时间（默认为60秒），将当前清单中超时（默认90秒）没有续约的服务剔除出去。

二、自我保护

        Eureka Server在 运行期间，会统计心跳失败的比例在15分钟以内是否低于85%，若是是，Eureka Server就会将当前实例注册信息保护起来，让这些实例不会过时。在单机的状况之下容易触发自我保护机制。当触发自我保护机制时，Spring Eureka面板页面出现下面状况：

默认状况下，是会开启自我保护机制，能够经过设置参数关闭，但通常状况都是要开启的。

服务提供者

一、服务注册

        “服务提供者”在启动时，会经过发送REST请求的方式将本身注册到Eureka Server上，同时带上自身服务的一些元数据信息。Eureka Server接收到REST请求后，将元数据信息存储到一个双层结构Map中，第一层的key是服务名，第二层key是具体的服务实例名，以下：

        架构图中，有两个服务提供者实例，分别注册到两个不一样的服务注册中心，即它们的信息分别被两个不一样的服务注册中心所维护，由于服务注册中心之间实现了同步（即当一个服务提供者发送注册请求到一个服务注册中心时，它就会将请求转发到集群中的与之相连的服务注册中心），因此经过这两台服务注册中心的任意一台均可以获取该服务提供者的信息（服务列表）。

二、服务续约

        注册完成以后，服务提供者还会维护一个心跳，告诉Eureka Server：“我还活着”，以防止被Eureka Server剔除。默认状况下，续约任务间隔为30秒，服务失效的时间为90秒，能够经过配置文件设置时间。

服务消费者

一、获取服务列表

        若是如今有两个服务注册中心，并且有两个服务提供者实例（如架构图），当启动一个服务消费者的时候，首先，它会发送REST请求，获取由服务注册中心返回的服务列表信息，为了性能考虑，Eureka Server会维护一份只读服务清单返回给客户端，同时每30秒更新一次清单列表。

二、服务调用

        服务消费者获取到服务清单后，经过服务名能够获取提供服务的实例名和该实例的元数据信息。由于有这些服务实例的详细信息，因此客户端能够根据本身的须要决定具体调用哪一个实例，在Ribbon中，会默认采用轮询的方式进行调用，从而实现客户端的负载均衡。

        Eureka中有Region和Zone两个概念，一个Region中能够包括多个Zone，每一个服务客户端须要被注册到一个Zone中，因此客户端对应一个Region和一个Zone。在进行服务调用的时候，优先访问同处一个Zone中的服务提供方，若访问不到，则访问其余Zone。