Shulou(Shulou.com)06/03 Report--

This article shows you a sample analysis of SpringColud Eureka service registration and discovery, which is concise and easy to understand. I hope you can get something through the detailed introduction of this article.

A brief introduction to Eureka

All the code in this article will be uploaded to git. Please feel free to browse the project git address: https://github.com/839022478/Spring-Cloud

In traditional applications, the invocation between components is realized through a standardized constrained interface, so as to achieve good cooperation between different modules. However, after being split into micro-services, the network address of each micro-service instance may change dynamically, and the number will also change, making the original hard-coded address useless. A centralized component is needed to register and manage services. In order to solve the above problems, service governance appears, that is, to manage all service information and status, that is, what we call a registry.

1.1 Registration Centre

For example, when we go to take a train or bus, we need to buy a ticket to take the bus, just to see if we have a ticket (whether there is a service), buy a ticket (get a registration list), and then take a bus (call), regardless of how many cars are running.

Flow chart:

Using a registry, we don't need to care about how many providers there are, just call it, so what are the registries?

Registry: Eureka,Nacos,Consul,Zookeeper

What is explained in this article is that Eureka,Eureka under the hot Spring Cloud micro-service is a service discovery framework developed by Netflix, a RESTful-style service, a basic component for service discovery and registration, and one of the prerequisites for building Spring Cloud micro-services. it shields the interaction details between Server and client, making developers focus on business.

Service registration and discovery mainly consists of two parts: server side (EurekaServer) and client side (EurekaClient)

Server (Eureka Server): a public service that provides Client with the function of service registration and discovery, maintains the relevant information registered to its own Client, and provides an interface for Client to obtain the information of other services in the registry, so that the dynamically changing Client can call each other between services.

Client (Eureka Client): Client registers its own service information on Server in a certain way, and maintains its own information consistency within the normal range, making it convenient for other services to find themselves. At the same time, it can obtain other service information that it depends on through Server, complete service calls, and has a built-in load balancer for basic load balancing.

Eureka GIt official website: https://github.com/Netflix/Eureka

1.2 Service Registration and Discovery

Service registration and discovery diagram:

1.3 client function and server function

1.3.1 client function

Hongmeng official Strategic Cooperation to build HarmonyOS Technology Community

Registration: when each microservice starts, it registers its own network address and other information with the registry, which stores this information (in memory).

Get the service registry: the service consumer queries the service provider's network address from the registry, and uses this address to invoke the service provider. In order to avoid checking the registry information every time, client will regularly go to server to pull the registry information to the cache local to client.

Heartbeat: each microservice communicates with the registry through some mechanism (heartbeat). If the registry does not communicate with each other for a long time, the instance will be logged out.

Invocation: the actual service invocation, through the registry, parses the corresponding relationship between the service name and the specific address, finds the specific service address, and makes the actual invocation.

1.3.2 server registry functionality

Hongmeng official Strategic Cooperation to build HarmonyOS Technology Community

Service registry: record each micro-service information, such as service name, ip, port, etc. The registry provides querying API (querying available microservice instances) and managing API (for registering and unregistering services).

Service registration and discovery: registration: registering microservice information with the registry. Discovery: query the list of available microservices and their network addresses.

Service check: regular detection of registered services. If an instance is found to be inaccessible for a long time, it will be removed from the registry.

2. Eureka builds 2.1 pom.xml on a single node

In some tutorials, spring-boot-starter-web will be introduced, but this dependency is not needed, because the dependency of spring-cloud-starter-netflix-eureka-server already contains it, and you can rely on it in pom.

Org.springframework.cloud spring-cloud-starter-netflix-eureka-server 2.2 application.ymlserver: port: 8500 eureka: client: # whether to register yourself with Eureka Server. The default is true. Since it is currently server, it is set to false, indicating that the service will not register its own information with eureka. Register-with-eureka: false # whether to obtain registration information from eureka server, because of a single node, there is no need to synchronize other node data Use false fetch-registry: false # to set the URL of the service registry, which is used for client and server to communicate service-url: defaultZone: http://localhost:8080/eureka/2.3 server startup class

Add this annotation to the startup class to identify the service as configuration center @ EnableEurekaServer

Import org.springframework.boot.SpringApplication; import org.springframework.boot.autoconfigure.SpringBootApplication; import org.springframework.cloud.netflix.eureka.server.EnableEurekaServer; @ EnableEurekaServer @ SpringBootApplication public class EurekaServerApplication {public static void main (String [] args) {SpringApplication.run (EurekaServerApplication.class, args);}} 2.4 launch

We start EurekaDemoApplication, and then enter the address http://localhost:8500/ in the browser to start our Eureka. Let's take a look at the effect. This screen shows that we have successfully started ~, but at this time there is no client to register in our service.

III. Service registration

Note: we need to add spring-boot-starter-web to the client pom, otherwise the service will not start normally.

3.1 pom.xml org.springframework.boot spring-boot-starter-web org.springframework.cloud spring-cloud-starter-netflix-eureka-client 3.2 application.yml# registry eureka: client: # set the URL service-url: defaultZone: http://localhost:8500/eureka/ # service name of the service registry instance: appname: mxn3.3 client startup class

We need to add @ EnableDiscoveryClient to the client startup class

Import org.springframework.boot.SpringApplication; import org.springframework.boot.autoconfigure.SpringBootApplication; import org.springframework.cloud.client.discovery.EnableDiscoveryClient; @ EnableDiscoveryClient @ SpringBootApplication public class EurekaClientApplication {public static void main (String [] args) {SpringApplication.run (EurekaClientApplication.class, args);}} 3.4 View effect

After the project starts, refresh the http://localhost:8500/ page, and we can find that the service has been registered successfully

And we can see it in the idea log print.

DiscoveryClient_MXN/DESKTOP-5BQ3UK8-registration status:204

It shows that the connection between Eureka Server and Eureka Client is mainly realized by heartbeat. Heartbeat means that Eureka Client reports the current status of this service instance to Eureka Server regularly to maintain the validity of the lease of this service instance in the registry.

Eureka Client will regularly pull information from the registry from Eureka Server and cache it locally for service discovery

IV. Eureka endpoint

Official website address: https://github.com/Netflix/eureka/wiki/Eureka-REST-operations

The Eureka server also provides an endpoint (eureka/apps/ {applicaitonName}) to view the details of the registered services. ApplicaitonName is the name of the microservice. For example, here we visit http://localhost:8500/eureka/apps/mxn.

5. The essence of Eureka principle

The registration information for each client is stored. EurekaClient gets a list of service registrations from EurekaServer synchronization. Select a service to invoke according to certain rules

5.2 Eureka Architecture Diagram

Service provider: an eureka client that registers and updates its own information with Eureka Server and can obtain information about other services from the Eureka Server registry.

Service registry: provides the function of service registration and discovery. Each Eureka Cient registers its own information with Eureka Server, and can also obtain information about other services through Eureka Server to achieve the purpose of discovering and calling other services.

Service consumer: an eureka client that obtains information registered with other services through Eureka Server, and then finds the required service to initiate remote invocation based on the information.

Synchronous replication: synchronous replication of registry information between Eureka Server to keep the service instance information consistent in different registries in the Eureka Server cluster.

Remote invocation: a remote call between service clients.

Registration: the Client side registers its own metadata with the server side for service discovery.

Renewal: maintain and update the validity of service instance metadata in the registry by sending a heartbeat to Server. When Server does not receive the heartbeat information from Client within a certain period of time, the default service will be offline and the information of the service instance will be deleted from the registry.

Offline: when Client actively logs out the service instance metadata to Server when it is closed, the service instance data of Client will be deleted from the registry of Server.

Get registry: Client requests registry information from Server for service discovery to initiate remote calls between services.

5.3 Eureka self-protection

Sometimes we see messages like this:

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.

This is because by default, Eureka Server does not receive a heartbeat of a microservice for a certain period of time and will log out a microservice (90s). However, when the network fails, the microservice and Server cannot communicate properly, so the above behavior is very dangerous, because the microservice is normal and should not be logged off. Its guiding idea is that we would rather keep the healthy and unhealthy than blindly cancel any healthy service. We can also turn off the self-protection function by command:

Eureka: server: enable-self-preservation: false

So how does self-protection trigger?

The trigger condition of the self-protection mechanism is: when the number of heartbeats per minute (renewsLastMin) is less than numberOfRenewsPerMinThreshold, and when the automatic protection mode switch (eureka.server.enable-self-preservation=true) is turned on, it triggers the self-protection mechanism, and no longer automatically expires the lease. All of us are less than numberOfRenewsPerMinThreshold. How on earth is it calculated? We can know in the eureka source code: numberOfRenewsPerMinThreshold = expectedNumberOfRenewsPerMin * Renewal percentage (default is 0.85) expectedNumberOfRenewsPerMin = currently registered application instances x 2 currently registered application instances x 2 because, by default, registered application instances are renewed every half minute, so the heartbeat is twice a minute, so x 2

For example, we have 10 services, expected renewal per minute: 10 * 2: 20, expectation threshold: 20: 0.85: 17, when less than 17:00, the self-protection mechanism will be triggered.

5.4 Health check

Because server and client keep the service state through the heartbeat, only services with a status of UP can be accessed. Look at the status in the eureka interface.

For example, the heartbeat has been normal, the service has been UP, but this service DB (database) can not be connected, can not provide services normally.

At this point, we need to synchronize the health status of the microservice to server. All you need to do is start a health check for eureka. In this way, the microservice will synchronize its health status to the eureka. The configuration is as follows.

Configure on the client side: propagate your health status to server.

Eureka: client: healthcheck: enabled: true5.5 Eureka listening event import com.netflix.appinfo.InstanceInfo; import org.springframework.cloud.netflix.eureka.server.event.*; import org.springframework.context.event.EventListener; import org.springframework.stereotype.Component; import java.time.LocalDateTime @ Component public class CustomEvent {@ EventListener public void listen (EurekaInstanceCanceledEvent event) {System.out.println (LocalDateTime.now ()) + "Service offline event:" + event.getAppName () + "-" + event.getServerId (); / / send nails} @ EventListener public void listen (EurekaInstanceRegisteredEvent event) {InstanceInfo instanceInfo = event.getInstanceInfo () System.out.println (LocalDateTime.now () + "Service launch event:" + instanceInfo.getAppName () + "-" + instanceInfo.getInstanceId ());} @ EventListener public void listen (EurekaInstanceRenewedEvent event) {System.out.println (LocalDateTime.now () + "Service Renewal / heartbeat escalation event:" + event.getAppName () + "-" + event.getServerId ()) } @ EventListener public void listen (EurekaRegistryAvailableEvent event) {System.out.println (LocalDateTime.now () + "registry available events");} @ EventListener public void listen (EurekaServerStartedEvent event) {System.out.println (LocalDateTime.now () + "registry startup event");}} 5.6Renew: service renewal

Eureka Client will send a heartbeat every 30 seconds to renew the contract. Inform Eureka Server that the Eureka Client is working properly and that there is no problem by renewing the contract. By default, if Eureka Server does not receive a renewal from Eureka Client within 90 seconds, the Server side will delete the instance from its registry. This time is configurable and generally not recommended.

5.6 Service culling

If Eureka Client is neither renewed nor offline (for reasons such as service crash or network exception) after registration, the status of the service is unknown and there is no guarantee that it can get feedback from the service instance. Therefore, it is necessary for the service to remove this method to clean up these unstable services on a regular basis. This method will remove all expired leases from the registry in batches, which is a fixed-time task. It is executed every 60 seconds by default. Delay 60 seconds, interval 60 seconds

Restrictions to be removed: 1. It is not cleared during the period of self-protection. two。 Cleared in batches.

VI. Eureka defects

Because the synchronous replication between clusters is carried out through HTTP, based on the unreliability of the network, it is inevitable that there are asynchronous time nodes in the registry information between the Eureka Server in the cluster, which does not meet the C (data consistency) in CAP.

VII. Summary

In the middle, we explained the node construction and principle of eureka. For the hot micro-services, it is very necessary for us to understand Eureka.

The above is a sample analysis of SpringColud Eureka service registration and discovery. Have you learned any knowledge or skills? If you want to learn more skills or enrich your knowledge reserve, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.