Github：https://github.com/yihonglei/thinking-in-springcloud
一 Eureka基础架构Eureka服务治理基础架构包括三个核心要素。
1、服务注册中心
Eureka分为客户端和服务端，Eureka服务端提供服务注册与发现的功能。
2、服务提供者
提供服务的应用，Spring Boot应用或者遵循Eureka通信机制的应用。
将应用自己注册到Eureka注册中心，以供其它应用的发现。
3、服务消费者
消费者从服务注册中心获取服务列表，通过客户端负载均衡某种算法轮询服务列表，
然后调用其所需要的服务，也即调用对应的服务提供者。
注意，在某些情况下，服务既是提供者也是消费者，
比如服务A调用B，B调用C，这个时候B既是提供者，也是消费者。
二 服务治理机制Eureka各个元素间的运作原理如下图：
这里假设启动了两个服务提供者，两个集群Eureka Server，两个服务消费者。
1、服务提供者
--服务注册（register）
从图中可以看到，服务提供者在启动的时候通过发送REST请求，将自己注册到Eureka Server注册中心，
注册信息包含一些元数据信息。Eureka Server接收到请求后，将元数据存储在一个双层结构Map中，
第一层的key是服务名，第二层的key是具体服务的实例名。
--服务同步（replicate）
图中提供了两个服务提供者，分别向两个注册中心注册，因为服务注册中心为集群部署，注册中心互相注册，
当服务提供者发送请求到一个注册中心时，注册中心会将注册的信息转发给其它集群相连的注册中心，
完成注册中心之间的服务同步。通过注册中心之间的服务同步，集群注册中心服务信息保持一致，
这样就可以通过任意一台注册中心获取服务列表。
--服务续约（renew）
服务提供者注册完成后，会维护一个心跳，用来持续的告诉注册中心，我还活着，避免Eureka Server 将服务提供者
从注册中心剔除，这种操作行为我们称为服务续约。
2、服务消费者
--获取服务（get registry）
服务消费者在启动的时候，向注册中心发送REST请求给服务注册中心，从服务注册中心获取服务列表清单。
Eureka Server维护一份只读的服务清单返回给客户端，同时该缓存清单默认每隔30秒更新一次。
--服务调用（invoke server）
服务消费者在获取服务清单后，通过服务名可以获得提供服务的实例名和该实例的元数据信息。
如果使用Ribbon客户端负载均衡，可以采用某种算法轮询进行调用。
--服务下线（cancel）
系统运行过程中总会有面临关闭或重启服务某个实例的情况，在服务关闭期间，我们不希望客户端会
继续调用关闭的服务实例。当服务实例进行正常关闭操作时，它会触发一个服务下线的REST请求Eureka Server，
注册中心收到请求时，服务端将该服务状态置为下线(DOWN)，同时把该下线事件传播下去。
3、服务注册中心
--失效剔除（evict）
服务有时候并不一定会正常下线，可能由于异常故障使服务运行不正常，但是，服务注册中心并未收到"服务下线"请求。
注册中心为了将这些无法提供服务的实例剔除，Eureka Server在启动的时候会创建一个定时任务，
默认每隔一段时间(默认为60秒)将当前清单中超时(默认为90秒)没有续约的服务从注册中心剔除。
--自我保护
默认情况下，如果Eureka Server在一定时间内（默认90秒）没有接收到某个微服务实例的心跳，
Eureka Server将会移除该实例。但是当网络分区故障发生时，微服务与Eureka Server之间无法正常通信，
而微服务本身是正常运行的，此时不应该移除这个微服务，所以引入了自我保护机制。
自我保护机制的工作机制是如果在15分钟内超过85%的客户端节点都没有正常的心跳，
那么Eureka就认为客户端与注册中心出现了网络故障，Eureka Server自动进入自我保护机制，
此时会出现以下几种情况：
1）Eureka Server不再从注册列表中移除因为长时间没收到心跳而应该过期的服务。
2）Eureka Server仍然能够接受新服务的注册和查询请求，但是不会被同步到其它节点上，
保证当前节点依然可用。
3）当网络稳定时，当前Eureka Server新的注册信息会被同步到其它节点中。
因此Eureka Server可以很好的应对因网络故障导致部分节点失联的情况，
而不会像ZK(zookeeper)那样如果有一半不可用的情况会导致整个集群不可用而变成瘫痪。