1. The core elements of service governance
We know that Eureka service governance includes three core elements: service registry, service provider, and service consumer. The basic relationship between the three is: the service registry provides a service registration and service discovery platform, and the service provider registers the service to the service registry. Center, the service consumer obtains and calls the service instance list from the service registry. The following figure shows the relationship between the three:
2. Service provider
1. Service registration
When the service provider starts, it will register itself to the specified service registry by sending a REST request. The registration address is specified according to the configuration in the configuration file eureka.client.service-url.defaultZone. During the request process, some of its own metadata information is carried. These metadata information is stored in one after being received by Eureka Server ConcurrentHashMap. This Map is a two-layer structured Map. The key of the first layer is the service name, and the key of the second layer is the instance name. Of course, the premise of the entire registration is configured eureka.client.register-with-eureka=true(default value, true if not configured), if the configuration is false, no registration behavior will occur.
2. Service synchronization
As shown in the figure above, the two service providers are registered to different service registries, but the two service registries register with each other to form a cluster. When any one of the service registries receives the registration request from the service provider After that, the request will be forwarded to other service registries in the cluster. In this way, other service registries in the cluster also maintain a list of service instances of the service provider, thereby realizing service synchronization.
3. Service renewal
After the service provider registers itself to the service registration center, it is not done once and for all, but will periodically send information to the service registration center to tell the service registration center: "I am still alive". That is, the service provider will maintain a heartbeat and periodically interact with the service registry. The advantage of this is to prevent the service registry from removing the service provider as an unavailable service. This periodic heartbeat service is usually called Service renewal. Regarding the service renewal operation, there are two important configurations:
eureka.instance.lease-renewal-interval-in-seconds=30
eureka.instance.lease-expiration-duration-in-seconds=90
The first configuration leaseRenewalIntervalInSecondsindicates the frequency at which the service provider sends heartbeats to the service registry, which is 30秒sent once. If leaseExpirationDurationInSecondslater, the service registry does not receive the heartbeat of the service provider, it will remove the service (in the case of multiple instances, remove an instance), the default time is 30秒.
The second configuration leaseExpirationDurationInSecondsmeans the timeout period for the service registry to wait for the next heartbeat after receiving the heartbeat of the service provider last time. If the next heartbeat is not received within this time, the service will be removed (in the case of multiple instances) Exclude an instance under), the default time is 90秒.
Three, serve consumers
1. Get service
Assuming that the service registry has registered a service, and the service has three service instances, when we start the service consumer, the service consumer will send a REST request to the service registry to request a list of registered service instances. In order to ensure the availability of the service, the service registry and the service provider will ensure the availability of the service in the form of a heartbeat. There is also an agreement between the service registry and the service consumer, which is 30秒to update the list of service instances every time by default. Service consumers, as far as possible to ensure the availability of services. For obtaining the service instance list, the first eureka.client.fetch-registryvalue must be guaranteed to be true (default is true, no configuration is required), if it is false, the consumer will no longer obtain the service instance list from the service registry. Of course, the default 30 seconds to update the service instance list cache is also eureka.client.fetch-registry-interval-secondsconfigurable.
2. Service call
After the service consumer obtains the service instance list, he can obtain the specific instance information of the service through the name of the service provider, including the metadata of the specific instance (such as service name, instance name, instance IP, instance port, etc.). With this information, the person can call these examples to complete specific functions. The service call is generally done by Ribbon, which uses the default polling algorithm to achieve client load balancing.
3. Service offline
Under normal circumstances, service offline refers to the service stop providing services. There are generally two cases when the service stops providing services: The first is normal offline, and the service will send a RESTrequest to the service registry before it goes offline , telling the service registry. The service is about to be stopped. At this time, the service registry will mark the instance corresponding to the service as after receiving the request DOWN, and propagate the notification that the service is offline to consumers. The second case is abnormal offline. Generally, abnormal offline is caused by line interruption or power failure of the server where the service is located. At this time, the service registration center has not received the offline notification, so within the leaseExpirationDurationInSecondstime period, the In the case of a heartbeat, the corresponding instance of the service will also be marked as DOWN, but before the marking, the service consumer may continue to call the service, but the service is not available at this time, so it is necessary to implement fault tolerance protection on the client side to reduce this The irresistible factors lead to disasters caused by the failure of consumers to call.
Fourth, the service registry
1. Failure elimination
Invalidation elimination is a mechanism for the service registry to eliminate abnormally offline service instances. Service instances 默认是60秒that have timed out ( 默认是90秒) in the instance list are removed at regular intervals ( ) .
2. Self-protection
The service registry has a self-protection mechanism, that is, the service registry will count the heartbeat of the service. If within 15 minutes, whether the heartbeat rate of the service fails 低于85%, if it happens 低于85%, the service registry will register these service instances The information is protected so that the information of these service instances does not expire. These protected service instances may not be able to provide services again, so a fault-tolerant mechanism needs to be established on the client side, otherwise it is easy for service consumers to get that it does not exist or does not provide The service instance of the service. A series of red warning messages appear on the service registration center panel:
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.
Since the service registry has opened the self-protection mechanism by default, in order to ensure the availability of the service, the self-protection mechanism of the service registry can be turned off. It only needs to be configured in the configuration file of the service registry eureka.server.enable-self-preservation=false(the default value is true), so that the service is registered The center can promptly remove unavailable services in time.