Eureka详解

一、基础架构*

1、服务注册中心*

*提供服务注册 和发现服务功能

*高可用：
eureka server 即为服务注册中心，此服务可以为集群，（集群就是两个或以上），形成高可用的eureka注册中心。

服务同步：
多个 eureka server 之间相互注册，服务提供者不管在哪个节点服务注册，该节点服务会把信息同步给集群的每个服务，从而实现数据同步，为的就是客户端访问到服务的任意节点都会获取完整的服务列表。

eureka server 提供了失效自动剔除和自我保护功能：
失效剔除：
有些时候，我们的服务提供方并不一定会正常下线，可能因为内存溢出、网络故障等原因导致服务无法正常工作。Eureka Server需要将这样的服务剔
除出服务列表。因此它会开启一个定时任务，每隔60秒对所有失效的服务（超过90秒未响应）进行剔除。
可以通过eureka.server.eviction-interval-timer-in-ms参数对其进行修改，单位是毫秒，生成环境不要修改。这个会对我们开发带来极大的不变，你对服务重启，隔了60秒Eureka才反应过来。开发阶段可以适当调整，比如10S

eureka:
server:
enable-self-preservation: false # 关闭自我保护模式（缺省为打开）
eviction-interval-timer-in-ms: 1000 # 扫描失效服务的间隔时间（缺省为60*1000ms）没1000毫秒扫描一次如果有down机的服务会进行剔除

自我保护：
当一个服务未按时进行心跳续约时，Eureka会统计最近15分钟心跳失败的服务实例的比例是否超过了85%。在生
产环境下，因为网络延迟等原因，心跳失败实例的比例很有可能超标，但是此时就把服务剔除列表并不妥当，因为服务可能没有宕机。Eureka就会把
当前实例的注册信息保护起来，不予剔除。生产环境下这很有效，保证了大多数服务依然可用。

*2、服务提供者

服务提供者 需要在Eureka server 注册服务 并完成续约的工作

服务注册：
服务提供者在启动时，会检测配置属性中的：eureka.client.register-with-erueka=true参数是否正确，这个参数默认就是true，确实这个参数为true时会向eureka server 发起rest请求并携带自己的原数据信息，eureka server会吧这些信息保存到一个双层 map 结构中 第一层map的key 就是服务名称，第二层map的key就是服务实例的id。

服务续约：
在注册服务完成以后，服务提供者会维持一个心跳（定时向EurekaServer发起Rest请求），告诉EurekaServer：“我还活着”。这个我们称为服务的续
约（renew）；

有两个重要参数可以修改服务续约的行为： #注意：和eureka server 失效剔除 配合使用
eureka:
instance:
lease-expiration-duration-in-seconds: 90 #服务失效时间，默认值90秒
lease-renewal-interval-in-seconds: 30 #服务续约(renew)的间隔，默认为30秒

通俗的说就是服务提供者会每隔30秒会向eureka server 发送一次心跳，证明还活着，如果超过90秒没有发送 eureka server 会认为该服务宕机 会从服务列表剔除，这两个值生产环境不用修改，默认即可。

3、消费者

获取服务列表：
当服务消费者启动是，会检测* eureka.client.fetch-registry=true* 参数的值，如果为true，则会从Eureka Server服务的列表只读备份，然后缓存在本地。并且每隔30秒会重新获取并更新数据。我们可以通过下面的参数来修改：
eureka:
client:
registry-fetch-interval-seconds: 5

生产环境不用修改。

负载均衡Robbin

我们在测试时启动了一个user-service，然后通过DiscoveryClient来获取服务实例信息，然后获取ip和端口来访问
然而在实际开发中为了提高效率，我们往往会开启很多 user-service 集群 那到底去访问哪个

一般这种情况下我们就需要编写负载均衡算法，在多个实例列表中进行选择。
不过Eureka中已经帮我们集成了负载均衡组件：Ribbon，简单修改代码即可使用。
什么是Ribbon：

Ribbon 是 Netflix 发布的负载均衡器，它有助于控制 HTTP 和TCP 客户端的行为。为ribbon 配置服务体服务提供者地址列表后，ribbon 就可基于某种负载均衡算法，自动地帮助服务消费者去请求。ribbon默认为我们提供了很多负载均衡的算法，如轮询、随机等。当然，我们也可为 ribbon 实现自定义的负载均衡的算法。

4、重试机制

Eureka的服务治理强调了CAP原则中的AP，即可用性和可靠性。它与Zookeeper这一类强调CP（一致性，可靠性）的服务治理框架最大的区别在于：
Eureka为了实现更高的服务可用性，牺牲了一定的一致性，极端情况下它宁愿接收故障实例也不愿丢掉健康实例，正如我们上面所说的自我保护机
制。
但是，此时如果我们调用了这些不正常的服务，调用就会失败，从而导致其它服务不能正常工作！这显然不是我们愿意看到的。

因此Spring Cloud 整合了Spring Retry 来增强RestTemplate的重试能力，当一次服务调用失败后，不会立即抛出一次，而是再次重试另一个服务
只需要简单配置即可实现Ribbon的重试

spring:
cloud:
loadbalancer:
retry:
enabled: true # 开启Spring Cloud的重试功能
user-service:
ribbon:
ConnectTimeout: 250 # Ribbon的连接超时时间
ReadTimeout: 1000 # Ribbon的数据读取超时时间
OkToRetryOnAllOperations: true # 是否对所有操作都进行重试
MaxAutoRetriesNextServer: 1 # 切换实例的重试次数
MaxAutoRetries: 1 # 对当前实例的重试次数

根据如上配置，当访问到某个服务超时后，它会再次尝试访问下一个服务实例，如果不行就再换一个实例，如果不行，则返回失败。切换次数取决
于MaxAutoRetriesNextServer参数的值