preface
Popular microservice architectures are changing the way we build applications, moving from single monolithic services to smaller and smaller deployable services (called microservices) that together make up our applications. When conducting A service, there will inevitably be calls between multiple services. If A service A wants to access service B deployed on another server, the premise is that service A needs to know the IP address of service B’s machine and the port corresponding to the service. The simplest approach would be for service A to maintain A copy of service B’s configuration (including IP addresses and ports, etc.), but this approach has several obvious drawbacks: how the configuration file is maintained as the number of services we call increases; Inflexibility. If service B changes the IP address or port, service A also changes the corresponding file configuration. Another is the inconvenient dynamic expansion or reduction of services. A better solution is Service Discovery. It abstracts out a registry. When a new service comes online, it will register its IP and port to the registry. It will periodically check the heartbeat of the registered service and remove it from the registry when the service status is abnormal. Service A only needs to obtain the information of service B from the registry. Even if the IP address or port of service B changes, service A does not need to change, which decouples services to some extent. Service discovery There are many open source implementations in the industry, such as Apache’s ZooKeeper, Netflix’s Eureka, Hashicorp’s Consul, and CoreOS’s ETCD.
What had been
Eureka on GitHub defines it as
Eureka is a REST (Representational State Transfer) based service that is primarily used in the AWS cloud for locating services for the purpose of load balancing and failover of middle-tier servers.
At Netflix, Eureka is used for the following purposes apart from playing a critical part in mid-tier load balancing.
Eureka, which is open source by Netflix, is designed in Client/Server mode. It is a service registration and discovery component developed based on HTTP protocol and Restful Api, providing complete service registration and discovery. Seamless integration with Spring Cloud. The Server plays the role of service registry, mainly providing service registration and discovery functions for the Client, maintaining the service registration information of the Client, and periodically detecting the registered service and removing the service offline when it is unavailable. The Client can obtain the registration information of its dependent services from the Server to complete the invocation between services. Unfortunately, version 2.0 is no longer open source, as you can see from the official Github Wiki. After all, service registration and service discovery are relatively basic and generic, and the ideas of other open source implementation frameworks are also well understood.
Service Registry (Eureka Server)
We introduced EurekaServer dependencies in the project, and then annotated the startup class @enableEurekaserver to use it as a registry. After starting the service, the page is as follows:
We continue to add the two modules service-provider and service-consumer, then add the @enableEurekaclient annotation to the startup class and specify the registry address as the Eureka Server we just started. A second visit shows that both services are registered.
Demo storage address: github.com/mghio/depth…
As you can see, Eureka is very simple to use, with only a few annotations and configurations to implement service registration and service discovery. Let’s look at how it implements these functions.
Service Register
The registry provides a service registration interface for invoking new services after they are started or changing the status of the corresponding service when the heartbeat detects that the service status is abnormal. Service registration sends a POST request with the current instance information to the addInstance method of the class ApplicationResource to register the service.
Can see the method to call the class PeerAwareInstanceRegistryImpl register method, the method is mainly divided into two steps:
- Call the parent class
AbstractInstanceRegistry的registerMethod to register the current service to the registry - call
replicateToPeersMethods are used asynchronously to other methodsEureka ServerThe node synchronizes service registration information
Service registration information is stored in a nested map, which is structured as follows:
The key of the layer 1 map is the application name (corresponding to service-provider in Demo), and the key of the layer 2 map is the application instance name (corresponding to mghio-mBP :service-provider:9999 in Demo). An application can have multiple instances. The main call flow is as follows:
Renew service
Service renewal is periodically invoked by service providers (such as service-provider in Demo), similar to heartbeat, to inform the registry of the Eureka Server of its status and avoid being taken offline by the Eureka Server as the service is aging. Renewals are renewals that send a PUT request to the renewLease method of class InstanceResource with the current instance information.
Into PeerAwareInstanceRegistryImpl renew method as you can see, the service contract steps in general and service registration, to update the current state of Eureka Server nodes, After the service is renewed successfully, the state is asynchronously synchronized to other Eureka Server sections. The main call process is as follows:
Service offline (Cancel)
When a service provider (such as the service-provider in Demo) stops a service, it sends a request to the registry to tell the Eureka Server to take the service offline, preventing the service consumer from invoking a non-existent service from the registry. A service offline sends a DELETE request with the current instance information to the cancelLease method of class InstanceResource to remove the service offline.
Into PeerAwareInstanceRegistryImpl cancel method as you can see, the service contract steps in general and service registration is consistent, in the current Eureka Server nodes eliminate offline before the service, After the service is offline successfully, the status is asynchronously synchronized to other Eureka Server sections. The main call process is as follows:
Eviction of service
Service deletion is when the registry Eureka Server starts a daemon thread evictionTimer at startup to perform the detection service periodically (default: 60 seconds). The judgment criterion is that the service has not been renewed for a certain period of time. The default expiration time is 90 seconds. That is, if a registered service does not Renew its service to the registry Eureka Server within 90 seconds, it will be removed from the registry. Expiry time can be configured eureka. Instance. LeaseExpirationDurationInSeconds modifications, Regularly perform testing services can be configured eureka. Server evictionIntervalTimerInMs modify main call process as shown in the figure below:
Service Provider
For the service provider (such as the service-provider service in Demo), there are three major operations: Register, Renew, and Cancel. Next, see how these three operations are implemented.
Service Register
Register.register-with-eureka =true (the default value is true) The registry does not need to register itself with the registry, set this configuration to false, this call is relatively simple, the main call flow is as follows:
Renew service
Service renewal is a heartbeat initiated by the service provider periodically (default is 30 seconds) to inform the registry that the Eureka Server is alive and healthy. You can configure eureka.instance.lease-renewal-interval-in-seconds to renew the service if eureka.client.register-with-eureka=true. To register the service in the registry, the main call process is as follows:
Service offline (Cancel)
When the service provider service is stopped, a DELETE request is sent to inform the registry that Eureka Server is offline so that the registry can take it offline and prevent service consumers from obtaining unavailable services from the registry. This process is relatively simple to implement. Add annotation @predestroy to shutdown method of DiscoveryClient. When the service stops, it will automatically trigger service removal and execute service removal logic.
Service Consumer
If the service consumer here does not need to be invoked by other services, there are really only two operations involved: Fetch and Update from the registry. If you also need to register with a registry to provide services externally, then the rest of the process is the same as the service provider mentioned above, which is not described here. Let’s see how these two operations are implemented.
Fetch A List of services
After the service consumer starts, it must first get a list of available services from the registry Eureka Server and also cache a copy locally. This operation to get the list of services is performed when the DiscoverClient class is instantiated after the service is started.
As can be seen, the operation of obtaining the service list can occur only when eureka.client.fetch-registry=true is configured, which is true by default. The main call flow is as follows:
Update the list of services
As can be seen from the above Fetch operation process, a local cache is also available, so it is necessary to periodically go to the registry Eureka Server to obtain the latest configuration of the service, and then update the local cache. This update interval can be modified by configuring eureka.client.registry-fetch-interval-seconds. The default interval is 30 seconds. This step can only be done if you configure eureka.client.register-with-eureka=true, which is true by default. The main call process is as follows:
conclusion
The work project uses the Spring Cloud technology stack, which has a very complete set of open source code to integrate Eureka, which is very convenient to use. Before are directly add annotations and modify several configuration attributes at one go, without in-depth understanding of the source code implementation, this article is mainly elaborated service registration, service discovery and other related processes and implementation methods, Eureka service discovery components have a closer understanding.
Refer to the article
Netflix Eureka
Service Discovery in a Microservices Architecture