Eureka详解
一、基础架构
1.Eureka服务治理基础架构的三个核心要素：
- 服务注册中心：Eureka提供的服务端，提供服务注册与服务发现的功能。
- 服务提供者：提供服务的应用，内嵌了Eureka客户端。
- 服务消费者：消费者从注册中心获取服务列表，从而消费者可以知道去何处调用所需要的服务。之前使用Ribbon来实现服务消费，一般常用Feign来实现服务消费。
二、服务治理机制
1.服务注册
服务提供者在启动时会将自己的信息通过发送REST请求的方式将自己注册到服务注册中心(Eureka Server)，服务注册中心将收到的各个服务的信息后存储起来，存储结构：Map<服务名，Map<实例名，实例信息>>。
2.服务同步
搭建服务注册中心双节点或者服务注册中心集群后，服务注册中心作为服务注册到了其他注册中心。当一个服务注册到一个注册中心时，该注册中心将会该请求转发给集群中相连的其他注册中心，从而实现注册中心之间的服务同步。这样，就能从所有的注册中心获取到该服务的信息了。
3.服务续约
一个服务注册到服务注册中心之后，这个服务会维护一个心跳持续告诉注册中心“我还在线”，防止注册中心将该服务的实例从服务清单中删除。
关于服务续约的两个参数：
eureka:
instance:
lease-renewal-interval-in-seconds: 30 # 服务续约心跳间隔，默认30s一次
lease-expiration-duration-in-seconds: 90 # 服务失效时间，默认90s
4.获取服务列表
当一个服务配置了eureka.client.fetch-registry=true参数后，启动时，他会发送一个REST请求给服务注册中心获取注册中心维护的服务清单。为了性能考虑，该清单默认会30s更新一次。
关于获取服务列表的参数：
eureka:
client:
fetch-registry: true # 向注册中心获取服务清单
registry-fetch-interval-seconds: 30 # 服务清单每30s刷新一次
5.服务调用
服务从注册中心获取服务清单之后，通过服务名就可以获取服务的所有实例的信息，客户端可以根据某些规则决定具体调用哪一个实例，在Ribbon中会默认采用轮询的方式进行调用，从而实现客户端的负载均衡。
6.服务下线
当一个服务的某个实例重启或关闭时，Eureka客户端会发送REST请求给注册中心，告诉注册中心该实例 “即将下线”。注册中心收到该请求后，刷新服务清单，并把该事件传播出去，避免其他服务继续调用该实例。
7.失效剔除
服务的实例注册到注册中心后，默认每30s进行一次服务续约，当该实例突然崩溃后，即无法继续进行服务续约。注册中心启动时会创建一个定时任务，每隔60s(默认)进行一次服务清单的清理，清理掉当前服务清单中超过90s(默认)没有续约的服务。
8.自我保护
在本地启动Eureka Server和邮件服务，一段时间后，注册中心的页面上就会出现以下警告。
这个警告实际上就是触发了Eureka Server的自我保护机制：邮件服务启动后每30s向注册中心进行一次服务续约，注册中心会统计15分钟之内的服务续约失败比例，这个比例低于85%，则认为该实例非常稳定安全，注册中心将该实例保护起来，让这些实例不会过期，尽可能的保护这些信息。
但是若是在这段保护期间内该实例出现问题，那么其他服务可能还能拿到这个实例，就会发生调用失败的情况，所以客户端必须要有容错机制，比如请求重试、断路器等。
在本地开发时，很容易就触发了自我保护机制，可以使用eureka.server.enable-self-preservation=false来关闭自我保护，已确保注册中心能够将不可用的实例及时剔除。
