服务提供者在启动时，会检测配置属性中的：eureka.client.register-with-erueka-true参数是否正确，事实上默认就是true。如果值确实为true，则会想eurekaServer发起一个Rest请求，并携带自己的元数据信息，eureka server会把这些信息保存到一个双层Map结构中。

第一层Map的key就是服务id，一般是配置中的spring.application.name属性

底层Map的key是服务的实例id.一般host+serviceId+port，例如：locahost：user-service：8081

值则是服务的实例对象，也就是说一个服务，可以同时启动多个不同实例，形成集群。

服务续约

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

续约时间

每隔30秒续约一次（可设置）

微服务项目之乐优--3.eureka集群搭建及eureka客户端详述及负载均衡Ribbon的使用和底层源码分析

服务时效时间

每个30秒发一次心跳，但是如果90秒还没有发，说明该服务挂了（可设置）

微服务项目之乐优--3.eureka集群搭建及eureka客户端详述及负载均衡Ribbon的使用和底层源码分析

失效剔除时间

在失效之后，并不是马上执行剔除操作，需要等待30秒时间（可设置）

微服务项目之乐优--3.eureka集群搭建及eureka客户端详述及负载均衡Ribbon的使用和底层源码分析

自我保护

我们关停一个服务，就会在eureka面板看到一条警告：

微服务项目之乐优--3.eureka集群搭建及eureka客户端详述及负载均衡Ribbon的使用和底层源码分析

这是触发了eureka的自我保护机制。当服务未按时进行心跳续约时，eureka会统计服务实例最近15分钟心跳续约的比例是否低于了85%。在生产环境下，因为网络延迟等原因，心跳失败实例的比例很有可能超标，但是此时就把服务剔除列表并不妥当，因为服务可能没有宕机。eureka在这段时间内不会剔除任何服务实例，直到网络恢复正常。生产环境下这很有效，保证了大多数服务依然可用，不过也有可能获取到失败的服务实例，因此服务调用者必须做好服务的失败容错。

我们也可以通过以下配置来关闭自我保护

微服务项目之乐优--3.eureka集群搭建及eureka客户端详述及负载均衡Ribbon的使用和底层源码分析

负载均衡问题

在之前取出ip地址其实没有实现负载均衡

微服务项目之乐优--3.eureka集群搭建及eureka客户端详述及负载均衡Ribbon的使用和底层源码分析

四、负载均衡Ribbon

在刚才的案例中，我们启动了一个user-service，然后通过discoveryClient来获取服务实例信息，然后获取ip和端口来访问。

但是实际环境中，我们往往会开启很多个user-service的集群，此时我们获取的服务列表中就会有很多个，到底该访问哪一个呢？

一般情况下我们需要编写负载均衡算法，在多个实例列表中进行选择。

不过eureka中已经帮我们集成了负载均衡组件：ribbon，简单修改即可使用。

什么是ribbon：

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