The infrastructure of Spring Cloud Eureka

Infrastructure architecture

• Service registry: Eureka provides the service side, provides the service to register in the discovery function, namely in the previous section we implemented the Eureka-server

• Service provider: An application that provides services, which can be springboot applications, or other technology platforms, and that follow Eureka communication mechanisms. It will
  

The services you provide are registered with Eureka for other applications to discover, which is the Hello-service application we implemented in the previous section.

• Service consumers: Consumer apps get a list of services from the service registry, so consumers can know where to call the services they need, in the previous section

The use of the Ribbon to achieve service consumption, in addition to the follow-up also need to introduce is oh that feign consumption.

Many times the client is both a service provider and a service consumer.

Service governance mechanism

Based on the structure above, let's take a look at the beginning of service registration to service invocation, and some important communication behaviors involved in each element.

Service Provider

　　 1. Service Registration

The service provider registers itself on the Eurekaserver at startup by sending a rest request, with some of its own services

Data information. After the Eureka server receives this rest request, the element information is stored in a double-layered map, where the first-level key is the service name,

The second-level key is the instance name of the specific service. When a service has multiple instances, the content is stored in such a double-layer map.

When registering the service, you need to confirm that the next eureka.client.register-with-eureka=true parameter is correct and that the value defaults to true. If set to false, the registration operation will not start.

　　2. Service synchronization.

　　　　Two service providers are registered to two different service registries, which means that their information is maintained by two service registries respectively.

At this point, as service registries are registered with each other as services, when a service provider sends a registration request to a service registry, it forwards the request to the cluster

Other registries to enable synchronization of services between registry centers. With service synchronization, the service information of two service providers can be obtained through any of the two service registries.

　3. Renewal of Service

　　　　　　After the service is registered, the service provider maintains a heartbeat that continues to tell Eurekaserver: "I'm alive," to prevent Eureka Server from removing the service instance from the list of services.

We call this operation a renewal of the service. (Renew)

　　

Service consumers

1. Access to services

　　　　　　Here, a service has been registered in the service registry, and there are two instances of the service. When we start the service consumer, it sends a REST request to the service registry to get

The above list of services, for performance reasons, Eureka server maintains a read-only list of services to return to the client, and the cache manifest is updated every 30s.

　　　　　　

2. Service invocation

　　　　　　after the service consumer obtains the service list, the service name can obtain the instance name of the service and the metadata information of the instance. . Because there are instances of these services

Details, so the client can decide which instance to invoke according to its own needs, and it will be invoked by default in the Ribbon, thus allowing the client to load balance.

For the selection of access instances, there is the concept of region and zone in Eureka, where a region can contain multiple zones, and each service client needs to be registered to a

Zone, so each client corresponds to a region and a zone. When making service calls, give priority access to the service provider in the same zone.

3. Service Downline

When the system is running, it will inevitably face the situation of shutting down or restarting an instance of the service, and during the service shutdown, we naturally do not want the client to continue to invoke the closed instance. So on the client

program, when the service instance does a normal shutdown operation, it will start a service offline rest request to Eurekaserver, tell the service registry: "I want to go offline." After the server receives the request, the

The service status is reset to down. And spread out the downline events.

Service Registration Center

　1. Failure Culling

　　　　In some cases, our service instances are not necessarily offline, may be due to memory overflow, network failure and other reasons to make the service does not work properly, and the service registry is not

Receive a "Service offline" request. In order to exclude these instances from the service list that are not available for service. Eureka server will create a timed task when it is started, by default every time

(default 60s) excludes services that have not been renewed in the current manifest (default is 90s).

　　2. Self-protection

　　　　　　When we debug the Eureka-based program locally, we will basically encounter one such problem, under the Information Panel of the service registration Zongxin appears under Class

The warning message:

In fact, the warning starts with the Eureka Server's self-protection mechanism. After the service is registered with Eureka Server, a heartbeat connection is maintained, telling Eureka that the server is alive.

Eureka server runs, it counts whether the rate of heartbeat failure is less than 80% in 15 minutes, and if it does, Eureka server will protect the current instance registration information.

Keep these instances out of date and protect these registration information as much as possible. However, this period of protection during the instance of the problem, then the client is very easy to get the actual service instances that do not exist, there will be a failure to call the situation,

Therefore, the client must have a fault-tolerant mechanism, such as can use the request retry, circuit breaker mechanism.

　　

The infrastructure of Spring Cloud Eureka