Eureka角色功能介绍

1.服务提供者：
服务注册：
服务提供者在启动的时候，会通过rest请求将自己注册到Eureka server上，同时带上了自身服务的一些元数据信息。Eureka收到这个请求之后，会将元数据（参见文末注解）存储到一个双层的map中。第一层map的key为服务名，第二层的key为具体服务的实例名。
服务同步：
当一个服务注册到一个服务注册中心上时，由于注册中心之间也互相注册为服务，因此注册中心会将该请求转发给集群中相关联的其他注册中心。从而实现服务注册的同步。
服务续约：
在注册完服务之后，服务提供者会维护一个心跳来持续告诉Eureka server该服务依然处于可用状态，从而避免Eureka server将该服务从注册中心剔除
关于服务续约有两个重要属性：
eureka.instance.lease-renewal-interval-in-seconds=30
eureka.instance.lease-expiration-duration-in-seconds=90
前者用户服务续约的调用间隔时间，默认为30s。也就是说每隔30秒服务提供者会发送一个心跳包给Eureka server。
后者是用于定义服务失效的事件，默认为90s。也就是说若90s未收到心跳包则认为该服务不可用，将从注册中心剔除。

2.服务消费者：
获取服务：
当我们启动服务消费者实例的时候，消费者会发送一个rest请求到注册中心，来获取上面的可用服务列表。Eureka server 会维护一份只读的服务列表清单给客户端，并且该清单每隔30s更新一次。此参数可以通过 eureka.client.registry-fetch-interval-seconds=**来更改。
服务调用：
服务消费者在获取服务清单后，可以根据服务名称，获取具体提供服务的实例名称和元数据信息。客户端可以自主选择使用哪一个服务实例来提供服务，Ribbon中默认采用轮询的方式进行调用以实现负载均衡。
对于选择实例，Eureka 中有region 和 zone的概念。一个region可以包含多个zone。每个客户端均需要注册到zone，因此每个客户端对应一个region和一个zone，在进行服务调用的时候，默认会优先选择同一个zone的服务提供方，若未能获取到服务则会调用其他zone的服务。
服务下线：
当服务实例正常的关闭时，会触发一个服务下线的rest请求给Eureka server。服务端在接收到请求之后，将该服务的状态置为down下线，并把该下线事件传播给其他服务端和客户端。

3.服务注册中心：
失效剔除：
有的服务并不一定能正常退出或者关闭，有可能有因为网络、内存、性能或者其他乱七八糟的幺蛾子（相信做开发的同学都有类似惨痛的经历）而导致服务不能正常提供服务，此时服务注册中心并不能接收到一个请求下线的rest请求。为了保持维护的服务都处于可用状态，eureka server会有一个定时任务， 默认每隔60s触发一次将服务清单中没有续约（还记得吗？默认90s）的服务剔除掉
自我保护：
之前介绍过，服务提供者会维护一个心跳连接，在Eureka server运行过程中，会统计心跳失败的比例，若在15min内超过85% ，则会触发eureka server的保护机制，将当前的实力注册信息保护起来，让这些实例不会过期。但是此期间若服务实例本身出现了问题，那么很可能出现客户端拿到的服务实例已经不可用，会出现调用服务失败的情况，因此，客户端要有自己的容错机制，比如请求重试、断路器等方案。
ps：据说本地调试很容易触发自我保护机制，为了确保所有的服务实例都处于可用状态，建议本地调试的时候把参数eureka.server.enable-self-preservation=false来关闭注册中心的自我保护机制。

此处对元数据做一些注解：元数据是Eureka客户端在向服注册中心发送注册请求时，用来描述自身服务信息的对象，其中包含了一些标准化的元数据比如：服务名称、实例名称、实例IP、实例提供服务的端口等用于服务治理的重要信息，以及一些用户负载均衡策略或者是其他特殊用途的一些数据。这些元数据是可以通过配置文件来配置的。