Spring Cloud micro-services technology stack (three): service governance Spring Cloud Eureka core element analysis

An article on " the Spring Micro Cloud services technology stack (B): to build highly available Eureka Server, service registration and discovery ," mainly from the use of introduced Spring Cloud Eureka, including Eurekabuilding service registration center, multi-service registry instance, and services discovery and consumption. This article will continue in-depth understanding of Spring Cloud Eurekathe core elements of governance serve a brief analysis to help us more flexibility to use Spring Cloud Eureka.

The core elements of governance services

By understanding the previous article, we know Eurekaservice management includes service registry, service providers and service consumers three core elements, the basic relationship between the three is: to provide service registry service registration and service discovery platform, service providers the service registered with the service registry, service consumers to obtain service instances from the list and call the service registry. The following figure shows the relationship between the three:

Now highlight the communication relationship between the three core elements based on the map:

service providers

• Service Registration

Service provider startup, by sending RESTa request mode registers itself to a designated service registry, registered address is the profile configuration according eureka.client.service-url.defaultZoneto specified in the request process, carry some of their own some of the metadata information, the metadata information is Eureka Serverreceived is stored in a later ConcurrentHashMap, this Mapis a two-layer structure Map, the first layer keyis the service name, the second layer keyis the instance name. Of course, the premise of the entire registration is configured eureka.client.register-with-eureka=true(default configuration was not true), if configured false, the registration behavior does not occur.

• Synchronization Service

如上图所示，两个服务提供者分别注册到了不同的服务注册中心，但是两个服务注册中心做了互相注册，形成了集群，当其中的任何一个服务注册中心接收到了服务提供者的注册请求后，就会将请求转发到集群中其他的服务注册中心，这样，集群中其他服务注册中心也维护了服务提供者的服务实例清单，从而实现了服务的同步。

• 服务续约

服务提供者将自己注册到服务注册中心之后并不是一劳永逸，而是还会周期性地向服务注册中心发送信息，告诉服务注册中心：“我还活着”。也就是服务提供者会维护一个心跳，周期性地和服务注册中心交互，这样做的好处是防止服务注册中心将服务提供者作为一个不可用服务剔除出去，这个周期性地心跳服务通常称之为服务续约。关于服务续约操作，还有两个重要配置：

eureka.instance.lease-renewal-interval-in-seconds=30
eureka.instance.lease-expiration-duration-in-seconds=90

第一个配置leaseRenewalIntervalInSeconds，表示服务提供者发送心跳给服务注册中心的频率，既30秒发送一次。如果在leaseExpirationDurationInSeconds后，服务注册中心没有收到服务提供者的心跳，则将剔除该服务（多个实例的情况下剔除某个实例），默认时间是30秒。
第二个配置leaseExpirationDurationInSeconds，表示服务注册中心至上一次收到服务提供者的心跳之后，等待下一次心跳的超时时间，在这个时间内若没收到下一次心跳，则将剔除该服务（多个实例的情况下剔除某个实例），默认时间是90秒。

服务消费者

• 获取服务

假设服务注册中心已经注册了一个服务，且该服务有三个服务实例，当我们启动服务消费者的时候，服务消费者端会发送REST请求到服务注册中心，请求获取已经注册的服务实例清单。为了保证服务的可用性，服务注册中心会和服务提供者以心跳的形式来保证服务的可用性，而服务注册中心和服务消费者之间同样有一份协议，那就是默认每30秒来更新一次服务实例清单给服务消费者，尽可能确保服务的可用性。对于服务实例清单的获取，首先得保证eureka.client.fetch-registry的值为true（默认为true，可以不用配置），如果为false，该消费者将不再从服务注册中心获取服务实例列表。当然，默认的30秒更新服务实例清单缓存也是可以配置的，eureka.client.fetch-registry-interval-seconds的值来配置。

• 服务调用

服务消费者获取到服务实例清单以后，就可以通过服务提供者的名称来获取服务的具体的实例信息，包括具体实例的元数据（如服务名称、实例名称、实例IP、实例端口等），消费者有了这些信息，就可以调用这些实例来完成具体功能。服务的调用一般由Ribbon来完成，它采用默认的轮询算法，实现客户端负载均衡。

• 服务下线

一般情况下服务下线值得是服务停止提供服务，服务停止提供服务一般有两种情况：第一种是正常下线，服务在下线之前会发送一个REST请求给服务注册中心，告诉服务注册中心，即将停止服务，这时候服务注册中心接收到请求之后会将服务对应的实例标记为DOWN，并将服务下线的通知传播给消费者。第二种情况是非正常下线，一般非正常下线是由于线路中断或者服务所在服务器的断电造成的，这时候服务注册中心并没有收到下线通知，所以在leaseExpirationDurationInSeconds时间段内，在没有收到心跳的情况下，也会将服务对应的实例标记为DOWN，但是在标记之前，服务消费者可能会继续调用服务，但是此时服务并不可用，所以需要在客户端实现容错保护，降低这种不可抗拒因素导致消费者调用失败而带来的灾难。

服务注册中心

• 失效剔除

失效剔除是服务注册中心对非正常下线的服务实例进行剔除的一种机制，在每隔一段时间（默认是60秒）将实例清单中的超时（默认是90秒）的服务实例清除出去。

• 自我保护

服务注册中心有一个自我保护的机制，那就是服务注册中心会统计服务的心跳，如果在15分钟内，服务的心跳失败比例是否低于85%，如果出现低于85%的现象，那么服务注册中心会将这些服务实例的注册信息保护起来，让这些服务实例信息不过期，这些被保护起来的服务实例不一定能再次提供服务，所以在客户端需要建立容错机制，否则服务消费者很容易拿到实际已经不存在或者不提供服务的服务实例。表现在服务注册中心面板上都是一串红色的警告信息：

EMERGENCY! EUREKA MAY BE INCORRECTLY CLAIMING INSTANCES ARE UP WHEN THEY'RE NOT. 
RENEWALS ARE LESSER THAN THRESHOLD AND HENCE THE INSTANCES ARE NOT BEING EXPIRED JUST TO BE SAFE.

由于服务注册中心默认开启了自我保护机制，为了保证服务的可用性，可以关闭服务注册中心的自我保护机制，只需要在服务注册中心的配置文件中配置eureka.server.enable-self-preservation=false（默认值为true）即可，这样服务注册中心就可以及时将不可用的服务及时剔除。

总结

Service registry, service providers and service consumers as the Eurekathree core elements of service management, it is essential to clarify the relationship between the three. Here, has completed basic analysis, articles will continue to analyze Spring Cloud Eurekapart of the source code, so stay tuned.