一、基础架构
构建Eureka服务治理有三个核心角色：服务注册中心、服务提供者和服务消费者。上图就是这三个角色之间的通信工作架构图。
- 服务注册中心（Eureka Server）：Eureka提供的服务端，提供服务注册和发现的功能；
- 服务提供者：提供服务的应用，遵循Eureka通信机制的应用。它将自己注册到Eureka Server中，以供其他应用发现；
- 服务消费者：消费者应用从服务注册中心获取服务列表，从而让消费者知道可以从哪个服务提供者调用其所需的服务；
二、各核心要素
在高可用的集群中，都会创建两个或两个以上的服务注册中心，他们之间进行相互注册，使得各自所管理的服务列表在各个注册中心进行信息同步。
服务注册中心
1、失效剔除
有时候服务实例异常（内存溢出、网络故障等）下线， 此时服务注册中心并没有收到“服务下线”的请求，为了从列表中将这些无法提供服务的实例剔除，Eureka Server在启动时会创建一个定时任务，默认每隔一段时间（默认为60秒），将当前清单中超时（默认90秒）没有续约的服务剔除出去。
2、自我保护
Eureka Server在 运行期间，会统计心跳失败的比例在15分钟之内是否低于85%，如果是，Eureka Server就会将当前实例注册信息保护起来，让这些实例不会过期。在单机的情况之下容易触发自我保护机制。当触发自我保护机制时，Spring Eureka面板页面出现下面情况：
默认情况下，是会开启自我保护机制，可以通过设置参数关闭，但一般情况都是要开启的。
服务提供者
1、服务注册
“服务提供者”在启动时，会通过发送REST请求的方式将自己注册到Eureka Server上，同时带上自身服务的一些元数据信息。Eureka Server接收到REST请求后，将元数据信息存储到一个双层结构Map中，第一层的key是服务名，第二层key是具体的服务实例名，如下：
架构图中，有两个服务提供者实例，分别注册到两个不同的服务注册中心，即它们的信息分别被两个不同的服务注册中心所维护，因为服务注册中心之间实现了同步（即当一个服务提供者发送注册请求到一个服务注册中心时，它就会将请求转发到集群中的与之相连的服务注册中心），所以通过这两台服务注册中心的任意一台都可以获取该服务提供者的信息（服务列表）。
2、服务续约
注册完成之后，服务提供者还会维护一个心跳，告诉Eureka Server：“我还活着”，以防止被Eureka Server剔除。默认情况下，续约任务间隔为30秒，服务失效的时间为90秒，可以通过配置文件设置时间。
服务消费者
1、获取服务列表
如果现在有两个服务注册中心，而且有两个服务提供者实例（如架构图），当启动一个服务消费者的时候，首先，它会发送REST请求，获取由服务注册中心返回的服务列表信息，为了性能考虑，Eureka Server会维护一份只读服务清单返回给客户端，同时每30秒更新一次清单列表。
2、服务调用
服务消费者获取到服务清单后，通过服务名可以获取提供服务的实例名和该实例的元数据信息。因为有这些服务实例的详细信息，所以客户端可以根据自己的需要决定具体调用哪个实例，在Ribbon中，会默认采用轮询的方式进行调用，从而实现客户端的负载均衡。
Eureka中有Region和Zone两个概念，一个Region中可以包括多个Zone，每个服务客户端需要被注册到一个Zone中，所以客户端对应一个Region和一个Zone。在进行服务调用的时候，优先访问同处一个Zone中的服务提供方，若访问不到，则访问其他Zone。
