​

This is the third article in the Spring Cloud column, and knowing the first two articles will help you understand the rest:

  1. Spring Cloud first article | Spring Cloud preface introduces an overview and its commonly used components

  2. The second Spring Cloud | use and understand Eureka registry

​

Overview of Eureka Registry high availability cluster

In micro service architecture of the distributed system, we should fully consider various micro service component of high usability problems, can not have a single point of failure, because the registry had itself is also a service, if it is only one node, then it is likely to malfunction, so we will not be able to register with the query service, so we need a high available service registration Central, which needs to be addressed through a registry cluster. The Eureka service registry itself is also a service, which can be seen as a provider or a consumer. We have configured Eureka.client.register-with-eureka= False allows registries not to register themselves, but we can register ourselves with other registries.

Eureka Server high availability is actually to himself as A service to other service registry, this will form A group to register each service registry, and implementation services listing of synchronization, each other on the registry is A registered service, synchronization can be copied to the registry B, so from any device on the registry can query to the registered Service, so as to achieve high availability.

​

2. Eureka Registry ha cluster construction

Eureka Registry A high availability cluster is where registries register with each other

1. We copy the application of Eureka server (Spring Cloud-Eureka-server). Yml is application-Eureka8701.yml. Application – Eureka 8702. Yml, we let Eureka 8701 and 8702 register with each other.

Modify application-eureka8701.yml:

spring:
  application:
    name: springcloud-eureka-server
server:
  port: 8701
Set hostname for the service center and specify IP address
eureka:
  instance:
    hostname: eureka8701
  client:
    register-with-eureka: true
    fetch-registry: trueService - url: defaultZone: http://eureka8702:8702/eureka modify application - eureka8701. Yml corresponding configuration spring as follows: application: name: springcloud-eureka-server server: port: 8702Set hostname for the service center and specify IP address
eureka:
  instance:
    hostname: eureka8702
  client:
    register-with-eureka: true
    fetch-registry: true
    service-url:
      defaultZone: http://eureka8701:8701/eurekaCopy the code

2, copy SpringcloudEurekaServerApplication start class named SpringcloudEureka8701ServerApplication, SpringcloudEureka8702ServerApplication, mouse on to start the class right choice as shown in figure

​

But in starting the class SpringcloudEureka8701ServerApplication add – Dspring. Profiles. The active = eureka8701

​

The same is true for the 8702 startup class operation, which is omitted here.

3. In order to ensure that Eureka8701 and Eureka8702 can be correctly accessed from each other and synchronize data, if they cannot be accessed from each other, the data in Eureka service cannot be synchronized and shared. We need to add two lines of configuration to the hosts file in the C:\Windows\System32\drivers\etc directory as follows:

127.0.0.1 eureka8701

127.0.0.1 eureka8702

4, launched two SpringcloudEureka8701ServerApplication SpringcloudEureka8702ServerApplication service we can see the successful registration.

​

The same is true for Eureka8702, where the Eureka service cluster is set up

Three, Eureka details

1. Service consumer model

1-1. Obtain services

When a consumer starts using a service alias, a REST request is sent to the service registry to get the corresponding service information, which is then cached to the local JVM client and updated from the server every 30 seconds.

The eureka.client. registrie-fetch -interval-seconds=30 parameter is available. The default value is 30 and the unit is second.

1-2. Services are offline

It is inevitable that an instance of a service will be shut down or restarted while the system is running, and it is not expected that the client will continue to call the closed instance during a service shutdown. So in the client application, when a service instance normally shuts down, it triggers a REST request to the Eureka Server for the service to go offline, telling the service center, “I’m going offline.” Upon receiving the request, the server sets the service state to DOWN and propagates the offline event.

2. Service registration mode

2-1. Elimination of failure

In some cases, our service instance does not necessarily go offline. The service may not work properly due to memory overflow or network failure, and the service registry does not receive a request for “service offline”. To remove these instances from the service table that cannot provide services, Eureka Server Eureka.server.eviction -interval-timer-in-ms=6000L will be designed to time out the current list (eureka.instance.lease-exp by default, 90 seconds) every time when a timed task is created at startup Iration -duration-in-seconds= 90) Services that are not renewed are kicked out

2-2 Eureka Service Registry self-protection mechanism

When we debug eureka-based applications locally, we almost always have a problem with the following red warning message in the information panel of the service main center. During development tests, we need to restart the microservice instance frequently. However, we rarely restart Eureka Server together (because the Eureka registry is not modified during development), and this protection mechanism is triggered when the number of heartbeats received in a minute decreases significantly. You can see Renews threshold and Renews(last min) on eureka management interface. When the latter (the number of heartbeats received in the last minute) is less than the former (heartbeat threshold), the protection mechanism will be triggered and a red warning will appear:

​

In fact, this warning triggers the Eureka Server’s self-protection mechanism. After registering with the Eureka Server, the service maintains a heartbeat connection to tell the Eureka Server that it is still alive. During the operation of Eureka Server, it will count whether the rate of client node heartbeat failure is lower than 85% within 15 minutes. If the rate is lower than 85%, the self-protection mechanism will be triggered, which can be easily met during stand-alone debugging. In actual production environment, it is usually caused by network instability. The Eureka Server protects the current instance registration information so that it does not expire and protects the registration information as much as possible. However, during this period of protection, if there is a problem with the instance, the client can easily get the actual service instance that is no longer in use, and there will be call failure. Therefore, the client must have a fault tolerance mechanism, such as please use retry, circuit breaker and other mechanisms.

In the absence of Eureka self-protection, if the Eureka Server does not receive a heartbeat from a microservice instance within a certain period of time, The Eureka Server will cancel the instance, but when the network partition failure occurs, the microservice and Eureka Server will not be able to communicate with each other normally. The above behavior may become very dangerous, because the microservice itself is normal, it should not cancel the microservice at this time, if there is no self-protection mechanism, The Eureka Server will unregister the service.

Eureka solves this problem by “self-protecting” the Microservice node when the Eureka Server node loses too many clients in a short period of time (possibly due to a network partition failure). Once in self-protected mode, Eureka Server protects the information in the service registry without deleting the data in the service registry (that is, without logging out any microservices). When the network is recovered, the Eureka Server automatically exits the self-protection mode. So, self protection mode is a kind of abnormal response network security protection measures, its architecture philosophy is better while retaining all micro service (of health service and unhealthy micro service will retain), also don’t blindly the cancellation of any of the health service use self protection mode, can let the Eureka cluster is more robust and stable, of course, also can use the configuration items: Eureka.server. enable-self-preservation=fase disables self-preservation mode.

But had Server self-protection pattern will also bring us some trouble, if a service provider within the protection period just logged off with regard to the service consumers at this time will get an invalid service instance, will call fails at this time, for this problem need to service the consumer has some fault tolerance mechanism, such as retry, circuit breakers, etc.

Eureka’s self-protection mode makes sense. When it is activated, it does not remove services from the register that have expired due to a long time without a heartbeat. Instead, it waits for repairs until the heartbeat returns to normal and then automatically exits self-protection mode. This mode is designed to avoid service unavailability due to network partition failure.

For example, there is A call relationship between two microservice client instances A and B. A is the consumer and B is the provider, but due to network failure,B fails to send heartbeat renewal to Eureka in time Eureka cannot simply remove B from the registry, because if B is removed,A cannot obtain B’s registered service from Eureka server, but B’s service is available at this time. So Eureka’s self-preservation mode is best left on.

2-3. The configuration related to disabling self-protection is as follows

  • Server Configuration

eureka:
  server:
    enable-self-preservation: false
    #eureka Server clean up invalid node interval, default 60000 ms, i.e. 60 seconds
    eviction-interval-timer-in-ms: 60000 # millisecondsCopy the code

  • Client Configuration

# Heartbeat detection detection and renewal time. Set the value to a smaller value during the test to ensure that the registry can kick out the service in time after the service is closed
eureka:
  instance:
    Send a heartbeat to the server every 1s to prove that you are still alive.
    lease-renewal-interval-in-seconds: 1
    # tell the server that if I don't send you a heartbeat within 2 seconds, I'm dead and please kick me out
    lease-expiration-duration-in-seconds: 2Copy the code

  • Disable the self-protection mode. The following information is displayed on the Eureka server:

​

Case source address: gitee.com/coding-farm…

​

​