什么是Eureka？
Eureka就好比滴滴出行，负责管理，记录服务提供者的信息。
服务调用者不需要自己寻找服务，而是把自己的需求告诉Eureka，然后Eureka会把符合你需求的服务告诉你。
同时，服务提供方和Eureka之间会通过“心跳”机制进行监控，当某个服务提供方出现问题时，Eureka会自动把它从服务列表中剔除。
这就实现了服务的自动注册、发现、状态监控。
Eureka的基础架构
Eureka架构中的三个核心角色：
服务注册中心：
Eureka的服务端应用，提供服务注册和发现功能。
服务提供者：
提供服务的应该用，可以是SpringBoot应用，也可以是其他任意技术实现，只要对外提供的是Rest风格服务即可。
服务消费者：
消费应用从注册中心获取服务列表，从而得知每个服务方的信息，知道去哪里调用服务方。
高可用的Eureka Server
EurekaServer即服务的注册中心。EurekaServer可以是一个集群，形成高度可用的Eureka中心。
多个EurekaServer之间会互相注册服务，当服务提供者注册到EurekaServer集群中的某个节点时，该节点会把服务的信息同步给集群中的每个节点，从而实现数据同步。
因此，无论客户端访问到EurekaServer集群中的任何一个节点，都可以获取到完整的服务列表信息。
所谓的高可用注册中心，其实就是把EurekaServer自己也作为一个服务进行注册，这样多个EurekaServer之间就能互相发现对方，从而形成集群。
服务提供者
服务提供者要向EurekaServer注册服务，并完成服务续约等工作。
服务提供者在启动时，会检测属性中的：eureka.client.register-with-eureka=true 参数是否正确，事实上默认的就是true。
如果值为true，则会向EurekaServer发起一个Rest请求，并携带自己的元数据信息，EurekaServer会把这些信息保存到一个双层Map结构中。
第一层Map的Key是服务的id，一般是配置中的：spring.application.name 属性。
第二层Map的Key是服务的实例id，一般 host + serviceld + port 例如：localhost:service-provider:8081
值是服务的实例对象，也就是说一个服务，可以同时启动多个不同的实例，形成集群。
在注册服务完成后，服务提供者会维持一个心跳（定时向EurekaServer发送一个Rest请求），告诉EurekaServer这个服务还存在，这个行为就被称为服务的续约（renew）。
有两个重要参数可以修改服务续约的行为:
eureka: instance: lease-expiration-duration-in-seconds: 90 # 服务失效的间隔，默认为30秒 lease-renewal-interval-in-seconds: 30 # 服务续约的时间，默认为90秒
也就是说，默认情况下每隔30秒，服务会向注册中心发送一次Rest请求，证明自己还活着。
如果超过90秒没有发送，EurekaServer就会认为该服务宕机，会从服务列表中移除。
这两个值在生产环境不要修改，默认即可。
在开发环境中，这个值就太长了，经常我们关掉一个服务，Eureka依然认为服务还存活着，所以可以适当的调小。
服务消费者
当服务消费者启动时，会检测 eureka.client.fetch-registry=true 参数的值，如果为true，则会拉取EurekaServer服务的列表只读备份，然后缓存在本地。
并且，每隔三十秒会重新获取并更新数据，可以通过下面的参数进行修改。
eureka:
client:
registry-fetch-interval-seconds: 5
生产环境中，不需要修改这个值。
在开发环境中，为了快速得到服务的状态，可以将其设置的小一点。
失效剔除
当服务进行正常关闭操作时，它会出发一个服务下线的Rest请求给EurekaServer，告诉服务注册中心：“我要下线了”。
服务中心接收到请求后，将服务设置为下线状态。
有些时候，服务提供方并不会正常下线，可能会因为内存溢出、网络故障等原因导致服务无法正常干工作。
EurekaServer需要将这样的服务踢出服务列表。
因此，EurekaServer会开启一个定时服务，每隔60秒对所有失效的服务进行剔除。
可以通过 eureka.server.eviction-interval-timer-in-ms 参数进行修改，单位是毫秒。
生产环境不要修改。
但是这个速度会对开发带来极大的不便，服务重启后，60秒Eureka才反应过来，所以在开发阶段可以适当的调整。
自我保护
当关停一个服务时，会在Eureka面板看到一条警告。
这就是触发了Eureka的自我保护机制，当一个服务未按时进行心跳续约时，Eureka会统计最近15分钟心跳失败的服务实例的比例是否超过了百分之八十五。
在生产环境下，因为网络延迟等原因，心跳失败实例的比例很可能超标，但是此时就把服务剔除是不妥当的。
因为服务可能没有宕机，所以Eureka会把当前实例的注册信息保护起来，不予剔除。
生产环境下很有效，保证了大多数服务依然可用，但是在开发中会带来一定的麻烦。
因此开发阶段会关闭自我保护模式。
eureka: server: enable-self-preservation: false # 关闭自我保护模式（缺省为打开） eviction-interval-timer-in-ms: 1000 # 扫描失效服务的间隔时间（缺省为60*1000ms）