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

This article mainly explains "what is Eureka". The content of the explanation is simple and clear, and it is easy to learn and understand. Please follow the editor's train of thought to study and learn "what is Eureka".

What is service registration?

First of all, let's take a look at the relationship between service registration, service discovery and service registry.

For example, the relationship between the three is like a supplier, a customer and a store.

First of all, local suppliers will provide all kinds of goods to the store, and then customers will go to the store to buy the goods when they need them.

The registration center is like this store, the action of the supplier is to register the service, and the goods are the registered service.

When the deployed service is started, it will be registered with the registry, and consumers will go to the registry to pull what kind of service they need.

So what exactly is service registration and why register the service with the registry?

Service registration means that when the service is started, the information of the service is registered in the registry, and all the registered services are managed uniformly by the registry.

Now let's think about it. If you are a consumer and you need to buy a product, you can go to the store or go directly to the supplier.

But if you want to buy a lot of goods today, and we don't know the address of the supplier corresponding to each item, then you have to go door to door to go to the supplier to buy goods.

Is it very troublesome? if there is a store with a collection of goods from multiple suppliers, do you only need to go to this one store to buy all the goods you need?

Wouldn't that be convenient?

In our real development, for example, when we need to obtain user information, and at this time, our user service is deployed with only one node, then we can access the service in the form of IP+ port.

When our service is deployed with 10 nodes, we can access it through the domain name, forward it to a node through nginx, and access the service of that node.

Partners who have used nginx know that every time we need to add a new node, we need to modify the configuration file of nginx. Once there are too many nodes in the service deployment, it becomes extremely troublesome to modify the configuration file frequently.

At this time, our registration center should be on the stage.

As soon as the registry enters the stage, we deploy the service node. After the deployment is completed, the service starts, and the service information will be registered with the registry. We do not need to worry about whether to modify the configuration file again.

What is service discovery?

There are two modes of service discovery: one is the client discovery mode, and the other is the server discovery mode. Eureka uses the client-side discovery mode.

The client found that the pattern was like I was a tuhao customer. I went to the store. I bought all the goods home and looked for them when I needed them.

Because I am a local tycoon, of course I can't stand having new products on the shelves in the store, but I don't, so I get the latest products in the store every once in a while.

This is the Fetch Registry in Eureka, which grabs registration information.

Eureka Client gets registry information from Eureka Server and caches it locally.

Note here that Eureka Client does not go directly to the service registry to get data, but rather from the ReadOnly cache.

And incremental updates are obtained between the previous acquisition cycle and the current acquisition cycle, and this information is updated periodically (every 30 seconds).

The same instance may be returned when it is obtained. Eureka Client automatically handles duplicate information.

Because of my tuhao behavior, I have been recorded by the store owner on its VVIP list. Unfortunately, there is an unexpected situation. I am bankrupt. I can no longer be so rich. I can't help it. I told my boss that I was broke. The boss listened to me and didn't even think about it. He just removed my name from his VVIP list. This is the reality of society.

This is the Cancel in Eureka. Cancel.

When each microservice node shuts down, Eureka Client sends a cancellation request to Eureka Server.

When Eureka Server receives your cancellation request, it will remove you from the service registry.

The shopkeeper is an arrogant person, and she has made a rule that if you are on her VVIP list, you must go to the store to buy goods from time to time.

Once you don't come shopping for a while, she feels that you have no purchasing power and are no longer fit to be on her VVIP list.

She will mercilessly remove my name from her VVIP list.

This is the Renew in Eureka (update / renew)

Eureka Client has a built-in load balancer that uses the round-robin load algorithm.

After the service starts, a heartbeat is sent to Eureka Server every certain period (default is 30 seconds).

If Eureka Server does not receive a heartbeat from Eureka Client within multiple heartbeat cycles (default is 90 seconds), Eureka Server will remove the node from the service registry.

Of course, the service discovery goes to the registry to pull the service information, and then needs to obtain the node information of the service deployment from the service information, and then access the service of the node through the domain name address.

Just like a store, because the space is too small, it only stores a miniature model of some goods, and the model says the address of the supplier to which the product belongs. After we go to the store to get the model, we see the address of the supplier. Then we can go directly to the supplier to buy the goods.

What is the registry and the role of the registry?

The registry is a manager, each service provider registers the service to the registry, and there is a registry for unified storage and management.

At the same time, the registry also has the function of judging whether services are available and eliminating services that are not available.

As for how to determine the availability of services and how to eliminate unavailable services, there will be a detailed explanation later.

What is Eureka and what does it do?

Eureka adopts CS architecture, which is divided into two major components.

One is Eureka Server, the registry server.

When each micro-service node starts, Eureka Server stores the service information registered by the service provider and provides a two-tier cache mechanism to maintain the entire registry.

The other is Eureka Client, the registry client.

Eureka Client is a java client that simplifies interaction with Eureka Server.

Eureka Client pulls, updates, and caches information in the Eureka Server.

So when all the Eureka Server nodes are down, the service consumer can still use the information in the cache to find the service provider, but there will be information inconsistencies when the service changes.

Detailed explanation of Eureka Architecture

As shown in the following figure, this is the architecture of the Eureka architecture diagram Eureka provided to us by the official website, which is mainly divided into two parts: Eureka Server and Eureka Client. Eureka Client is divided into Applicaton Service and Application Client,Applicaton Service, which is the service provider, and Application Client is the service consumer.

We will first rely on Eureka Client in the application, and after the project starts, Eureka Client will send a request to Eureka Server, register, and send some of its own information to Eureka Server.

After the registration is successful, Eureka Client will send a heartbeat to Eureka Server at regular intervals to renew the service, that is, to report the health status. If the client does not renew the contract for a long time, Eureka Server will delete the client's information from the server registry in about 90 seconds.

Eureka Client will also regularly pull registry information from Eureka Server, then get a target according to the load balancing algorithm, and initiate remote calls. Load balancing will be described in detail later in class, that is, Ribbon components.

When the application stops, the Eureka Server will also be notified to remove the relevant information. After the information is successfully removed, the corresponding client will update the information of the service, so that the service that has been offline will not be called. Of course, there will be a delay, and the invalid service may be called, so the failure retry feature will be enabled on the client to avoid this problem.

Eureka Server will have multiple nodes to form a cluster to ensure high availability. Eureka Server does not integrate other third-party storage, but is stored in memory.

So registration information is copied between Eureka Server to all nodes of Eureka Server in the cluster.

In this way, the data is shared, and any Eureka Client can look up registry information in any Eureka Server node.

The workflow of Eureka

Self-protection Mechanism of Eureka

What is the self-protection mechanism?

Official definition: self-protection mode is a kind of security protection measure against abnormal fluctuations of the network. The use of self-protection mode can make the Eureka cluster run more robust and stable.

Why turn on the self-protection mechanism?

If Eureka Server does not receive a heartbeat from a service node within a certain period of time (default 90s) (optimizable), Eureka Server will remove the service instance.

However, in some cases, when the network partition failure occurs, the service node is actually in a normal inventory state, but it can not communicate with Eureka Server normally. At this time, if there is no self-protection mechanism, Eureka Server will eliminate the service node.

The working mechanism of self-protection mode

If more than 85% of the client nodes do not have a normal heartbeat within 15 minutes, then Eureka Server will assume that there is a network failure between the client and the registry, and Eureka Server enters the self-protection mechanism.

The shortcomings of the self-protection mechanism

If in the self-protection mechanism, some service nodes happen to be offline abnormally, but Eureka Server will not remove the service node, the service consumer will get an invalid service instance.

Solution

①: turn off the self-protection mechanism (not recommended)

②: switch requests or circuit breakers. Use load balancer to set the speed switch request to the next registration service when a request is not answered for more than a few seconds. For example, use Ribbon+Hystrix to configure load balancer and circuit breaker.

After Eureka Server enters the self-protection mechanism,

1. Eureka Server does not remove service nodes from the registry because they have not renewed their contracts with the registry for a long time.

2. Eureka Server can still accept registration and query requests for new services, but it will not be synchronized to other Eureka Server nodes

3. When the network is normal, the current Eureka Server node will synchronize the new service node information to other Eureka Server nodes.

How to turn on self-protection

Turn the self-protection mechanism on or off through eureka.server.enable-self-preservation=true/false.

Other key configurations:

Interval to clean up failed service nodes: default for eureka.server.evication-interval-timer-in-ms is 60s

Renewal interval: eureka.instance.lease-renewal-interval-in-seconds defaults to 30s

Renewal expiration time: eureka.instance.lease-expiration-duration-in-seconds defaults to 90s

Explore how Eureka opens the mechanism of self-protection through source code.

As a first step, we introduce Eureka Server dependencies.

In the second step, we find that the path under the eureka-core jar package is the registry package under com.netflix.eureka

The third step is to go to the AbstractInstanceRegistry class and find the evict method, which is the final execution method of the thread that periodically removes the task.

Public void evict (long additionalLeaseMs) {logger.debug ("Running the evict task"); / / determine whether automatic protection is enabled. If automatic protection is enabled, / / the operation of removing the service will not be performed, and the service if (! this.isLeaseExpirationEnabled ()) {logger.debug ("DS: lease expiration is currently disabled.");} else {.}} will not be removed.

Step 4, we find the implementation of the isLeaseExpirationEnabled () method

Public boolean isLeaseExpirationEnabled () {/ / first determines whether self-protection is turned off in the configuration file. If self-protection is turned off and returns true directly, the / / evict method can continue to execute useless service elimination operation if (! this.isSelfPreservationModeEnabled ()) {return true } else {/ / if the self-protection mechanism is enabled, then further determine whether to enable the self-protection mechanism / / numberOfRenewsPerMinThreshold (minimum number of renewals per minute) is greater than 0 / / and getNumOfRenewsInLastMin (last minute renewals) must be greater than the minimum number of renewals per minute / / when the above two conditions are met, the renewal is normal, and the return true,evict method can continue to execute. Perform useless service elimination operation / / so, only if the above two conditions are not met, the false,evict method will be returned and will not be executed downwards, even if there are no services with normal renewal, return this.numberOfRenewsPerMinThreshold > 0 & & this.getNumOfRenewsInLastMin () > (long) this.numberOfRenewsPerMinThreshold will not be removed. }}

Step 5, we notice that the variable numberOfRenewsPerMinThreshold is critical, which means the minimum number of renewals per minute

This variable is updated in the service registration register and service offline cancel methods as follows:

/ * * the minimum number of renewals expected per minute = the number of service instances expected to renew normally * (60 / (our configured heartbeat interval (default is 30 seconds)) * 0.85 * serverConfig.getRenewalPercentThreshold () defaults to 0.85 (which can be configured via eureka.server.renewal-percent-threshold) * * / protected void updateRenewsPerMinThreshold () {this.numberOfRenewsPerMinThreshold = (int) ((double) this. ExpectedNumberOfClientsSendingRenews * (60.0D / (double) this.serverConfig.getExpectedClientRenewalIntervalSeconds ()) * this.serverConfig.getRenewalPercentThreshold ()) }

This is the whole logical process that Eureka starts to protect itself.

Remove the self-protection mechanism

1. When the network partition failure of the service is released and the client is able to interact with the service, the number of renewals per minute is updated when the contract is renewed, and automatically when the number of renewals per minute is greater than 85%.

two。 Restart the service

Health examination of Eureka

In fact, many frameworks manage health status through actuator, and extend health endpoints.

So as long as we integrate Actuator into the project, we can manage and monitor the health of the project.

The same is true of Eureka. We can tell Eureka Server the status of some unhealthy service nodes, and then Eureka Server will take the initiative to take them offline.

This is Eureka's health check.

How to implement Eureka-Actuator health check?

First of all, we will rely on spring-boot-starter-actuator in pom.

Org.springframework.boot spring-boot-starter-actuator 2.3.3.RELEASE

The second step is to add eureka.client.healthcheck.enabled=true configuration to the configuration file

Principle analysis:

First of all, we decide whether to assemble EurekaHealthCheckHandler according to the value of eureka.client.healthcheck.enabled in EurekaDiscoveryClientConfiguration, and then we register HealthCheck in EurekaClientAutoConfiguration, but after we complete the registration, we will call the task to update the status, and in com.netflix.discovery.InstanceInfoReplicator.run () we will update the status.

Multi-level caching Mechanism of Eureka

What is a multi-level caching mechanism

In order to avoid concurrency conflicts caused by colleagues reading in-memory data, Eureka Server uses a multi-level cache mechanism to improve the response speed of service requests.

Eureka Server caching is implemented through a read-only cache and a read-write cache.

First-level cache: concurrentHashMapreadOnlyCacheMap is essentially HashMap with no expiration time and saves data and information for output.

ReadOnlyCacheMap depends on the update of the timer. By comparing with the value of readWriteCacheMap, readWriteCacheMap prevails.

ResponseCacheUpdateIntervalMs:readOnlyCacheMap cache update interval. Default is 30s.

Second-level cache: LoaDingreadWriteCacheMap is essentially Guava cache, including failure mechanism to protect the output of data information.

ResponseCacheAutoExpirationInSeconds:readWriteCacheMap cache expiration time. Default is 180 s.

When the service node changes such as registration, offline, expiration, status change, etc.

1. Update registry information in memory

two。 At the same time, when the readWriteCacheMap cache expires, cache cleanup will only clear the readWriteCacheMap cache, and the readOnlyCacheMap read-only cache is not updated, that is, when the client's information changes, the read-only cache is not immediately perceived. Updates to the read-only cache can only be updated on that 30-second scheduled task.

3. After a period of time (the default is 30s), the background thread finds that the readWriteCacheMap cache is empty and empties the cache in the readOnlyCacheMap as well.

4. When a service consumer pulls registry information, the load method of ClassLoader is called to load the registry information in memory into all levels of cache and return the registry information.

In Eureka Server, there will be two threads, one is to regularly synchronize the two cached data, the default is 30s, and the other is to detect heartbeat failure regularly, the default is 90s.

Service pull

1. Service consumers pull registry information every 30s by default

two。 Get the information from readOnlyCacheMap, if the get is empty

3. Get it from readWriteCacheMap, if it is still empty

4. Call the load method of ClassLoader, load the registry information in memory into all levels of cache, and return the registry information.

Regional configuration of Eureka

When the geographical distribution of users is very wide, such as when the company has branches in Shanghai, Hangzhou, Qingdao and so on, there will generally be multiple computer rooms.

So for users, of course, they want to call the micro-service application in the computer room of the local branch.

For example: Shanghai user A, calling the OAuth3 service, user A certainly wants to call the micro-service application in the Shanghai computer room. If Shanghai user A calls the OAuth3 service of Hangzhou computer room, it will increase the delay time.

Therefore, we hope that the services in one computer room will first call the services in the same computer room, and when the services in the same computer room are not available, we will call the services in other computer rooms in order to reduce the delay.

For this reason, eureka provides two concepts of region and zone for zoning. Eureka is designed based on Amazon, so the distinction between regions is the same as Amazon. Amazon is divided into multiple region, and each region contains multiple zone, so when Eureka is designed, you can also set region and zone. When you request, you can give priority to services that are in the same zone as the request service.

Basic configuration

Eureka: client: region: shanghai availability-zones: shanghai: zone1, zone2 service-url: zone1: http://localhost:8081/eureka, http://localhost:8082/eureka zone2: http://localhost:8083/eureka, http://localhost:8084/eureka instance: metadata-map: zone: zone1

At this point, no matter how many times we call, we call the service under zone1 under shanghai.

Generally speaking, we will combine Ribbon to achieve load balancing of micro-services, and there will be some special load policy algorithms within Ribbon, although we just said that we will give priority to requesting service instances in the specified Zone region under the specified region.

But sometimes, for example, when there is no zone available under Region=shanghai, the system will load DEFAULT_ZONE by default, or the service load in the same region is too high. And so on, it will also automatically switch to services in other areas.

Retry Mechanism of Eureka

Because the service governance mechanism implemented by Spring Cloud Eureka emphasizes AP in the principle of CAP, that is, availability and reliability, at the expense of a certain degree of consistency (in extreme cases, it would rather accept failed instances than lose "healthy" instances, such as the self-protection mechanism we mentioned above).

However, whether it is due to the trigger of the protection mechanism or the delay of service elimination, the service calls to these abnormal services will fail, resulting in other services not working properly!

This is obviously not what we would like to see, and we still hope to enhance fault tolerance for such problems. Therefore, we usually add some retry mechanism when implementing service invocation.

Since the Camden SR2 version, Spring Cloud has integrated Spring Retry to enhance the retry ability of RestTemplate. For developers, through simple configuration, the original service access through RestTemplate will automatically implement the retry policy according to the configuration.

The retry mechanism for turning on Eureka is simple. First, we introduce the dependency of Spring Retry in pom:

Org.springframework.retry spring-retry

Then configure the spring.cloud.loadbalancer.retry.enabled parameter in the configuration file to control the switch of the retry mechanism, because Spring Retry is on by default, so we just need to introduce dependencies, and if we want to turn it off, we just need to set spring.cloud.loadbalancer.retry.enabled to false.

In fact, in the architectural components of SpringCloud, both Fegin,Ribbon and Zuul provide a retry mechanism, which will be analyzed later when it comes to specific components.

Deployment of practical Eureka registry

Eureka Server project building

1. Create a springcloud-eureka-server project, and then add spring-cloud-starter-netflix-eureka-server dependencies in pom.

two。 Add spring-cloud-starter-netflix-eureka-server dependency in pom.xml file

Org.springframework.cloud spring-cloud-starter-netflix-eureka-server

3. Use @ EnableEurekaServer on the startup class SpringcloudEurekaServerApplication to turn on the auto-assembly function of EurekaServer.

@ SpringBootApplication@EnableEurekaServerpublic class SpringcloudEurekaServerApplication {public static void main (String [] args) {SpringApplication.run (SpringcloudEurekaServerApplication.class, args);}}

4. Add profile application.properties

# server (eureka default port: 8761) whether server.port=8761# springspring.application.name=spring-cloud-eureka-server# eureka# registers with eurekaeureka.client.register-with-eureka=false# whether to obtain registration information from eureka the address of the eureka.client.fetch-registry=false# eureka server (note: the address at the bottom of the address / eureka/ is a fixed value) eureka.client.serviceUrl.defaultZone= http://localhost:${server.port}/eureka/

5. Start the project, and then visit http://localhost:8761/, to see the administration page of Eureka, indicating that Eureka started successfully.

Eureka Client project building

1. Create a springcloud-eureka-client project, and then add spring-cloud-starter-netflix-eureka-client dependencies in pom.

Org.springframework.cloud spring-cloud-starter-netflix-eureka-server

two。 Use @ EnableEurekaClient on the startup class SpringcloudEurekaClientApplication to turn on the auto-assembly function of EurekaServer.

@ SpringBootApplication@EnableEurekaClientpublic class SpringcloudEurekaClientApplication {public static void main (String [] args) {SpringApplication.run (SpringcloudEurekaClientApplication.class, args);}}

Configure the address of the eureka.client.serviceUrl.defaultZone, that is, the address of the Eureka Server you just started, http://localhost:8761/eureka/.

Server.port=8762spring.application.name=spring-cloud-eureka-clienteureka.client.serviceUrl.defaultZoon= http://localhost:8761/eureka/

Start the client, then refresh the Eureka home page that just opened, and we find that the service has been registered successfully.

Eureka registry adds password authentication

Above, we can see that after we have built the Eureka Server, we can directly see the management page of the Eureka if we visit http://localhost:8761/, without logging in.

If in practical use, the registry address has a public network IP, it must be directly accessible, which is not secure. So we need to transform Eureka, through the integration of Spring-Security for security authentication, coupled with authority authentication to ensure security.

First, introduce Spring-Security dependencies into pom.xml

Org.springframework.boot spring-boot-starter-security

Then add the authentication configuration information to the application.properties

Spring.security.user.name=javaer123456 # username spring.security.user.password=123456 # password

Finally, add the Spring Security configuration class

@ Configuration @ EnableWebSecurity public class WebSecurityConfig extends WebSecurityConfigurerAdapter {@ Override protected void configure (HttpSecurity http) throws Exception {/ / turn off CSRF authentication for Spring Security (if not, the client cannot connect) http.csrf () .disable (); / / support httpBasic http.authorizeRequests () .anyRequest () .authenticated () .and () .httpBasic ();}}

In this way, after we successfully start Eureka Server, we visit http://localhost:8761/, and the browser will prompt you to enter your user name and password, and enter it correctly before you can continue to visit the management page provided by Eureka.

Note: after Eureka Server enables authentication, the configuration of Eureka Client registration should also include the user name and password information of the authentication.

Eureka.client.serviceUrl.defaultZone= http://javaer23456:123456@localhost:8761/eureka/

Thank you for your reading, the above is the content of "what is Eureka", after the study of this article, I believe you have a deeper understanding of what is Eureka, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

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.