What is service registration?

First, let's understand the relationship between service registration, service discovery, and service registries.

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

First, suppliers around the world provide a variety of goods to stores, and then customers go to the stores to buy goods when they need them.

The registration center is like the store, the supplier's action is the service registration, and the goods are the registered services.

When a deployed service is activated, it is registered to the registry, and the consumer goes to the registry and pulls it up on their own when they need a service of any kind.

So what exactly is service registration, and why register services to the registry?

Service registration means that a service is registered with the registry at startup, and the registry manages all the registered services in a unified way.

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

But if you have to buy a lot of items today, and we don't know the address of the supplier for each item, then you have to go door-to-door and run to the supplier to buy the item.

Isn't it a pain in the ass to have a store that aggregates goods from multiple suppliers, so you only need to go to that one store to buy all the goods you need?

This is convenient.

In our real-world development, for example, when we need to get user information, and at this point, our user service is deployed only one node, then we can use the form of IP + port to access the service.

When at this point, our service is deployed 10 nodes, we can access the service through the domain name, which is forwarded to a node through nginx to access the service on that node.

Partners who have used nginx know that whenever we need to add a new node, we need to modify the nginx configuration file, once the service is deployed in too many nodes, frequent modification of the configuration file becomes an extremely troublesome thing.

At this time, our registration center, it should be powder.

Once the registry is up, we deploy the service nodes, and when the deployment is complete and the service starts, the service information is registered with the registry, so we don't need to worry about modifying the configuration file again.

What is service discovery?

There are two modes of service discovery: a client-side discovery mode and a server-side discovery mode.Eureka uses the client-side discovery mode.

The client-side discovery model is like I'm a landed customer, I go to the store, I buy all the items, I take them home, and I look inside those items when I need them.

Because I'm a tycoon, of course I can't stand the fact that there are new products in the store that are on the shelves and I don't have them, so I store incrementally every once in a while to get the newest items.

This is Fetch Registry in Eureka, grabbing registration information.

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

Let's note here that the Eureka Client doesn't go directly to the service registry to fetch the data, but fetches it from the ReadOnly cache.

And it will do so by fetching incremental updates between the last fetch cycle and the current fetch cycle, which are updated periodically (every 30 seconds).

Fetches may return the same instance. the Eureka Client automatically handles duplicate information.

Because of my dirt-cheap behavior, I have been recorded by the store owner on its VVIP list. Unfortunately, I went bankrupt, and I can't be that generous anymore. I had no choice but to tell the owner that I was broke, and the owner listened to me, and without even thinking about it, he just took my name off his VVIP list, that's how realistic society is.

This is Cancel in Eureka, cancel.

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

Once Eureka Server receives your cancel request, it drops you from the service registry.

The owner of the store is a prissy person, and she makes a rule that if you're on her VVIP list, you have to go to the store every once in a while to purchase items.

Once you don't come to make purchases for a period of time, she feels that you no longer have the purchasing power to exist on her VVIP list.

She'll then be ruthless and take you off her VVIP list by removing my name from it.

This is Renew in Eureka

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

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

If Eureka Server does not receive a heartbeat from an Eureka Client for multiple heartbeat cycles (90 seconds by default), Eureka Server will drop the node from the service registry.

Of course, service discovery goes to the registry to pull information about the service, and then you need to get the information about the node where the service is deployed from the service information, and then access the service on that node through the domain address.

It's like a store that, because the space is so small, just holds a miniature model of some commodity, with the address of the supplier that the commodity belongs to written on the model, and we go to the store and get the model, and see the supplier's address, and then we can just go to the supplier and buy the commodity directly.

What is the Registry and what does it do?

A registry is a manager where service providers register their services with the registry, and the registry stores and manages them in a unified way.

The registry also determines whether a service is available and removes unavailable services.

How to determine the availability of a service and how to remove unavailable services will be explained in more detail later.

What is Eureka and what does it do?

Eureka uses a CS architecture, which is divided into two main components.

One is Eureka Server, the registry server.

When each microservice node is started, the Eureka Server stores the service information registered by the service provider and provides a two-tier caching mechanism to maintain the entire registry.

The other is the Eureka Client, the registry client.

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

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

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

Eureka Architecture Explained

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

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

After successful registration, every certain period of time, the Eureka Client sends a heartbeat to Eureka Server to renew the service, that is, to report the health status. If the client does not renew for an extended period of time, then Eureka Server removes the client's information from the server registry in approximately 90 seconds.

The Eureka Client also periodically pulls registry information from the Eureka Server and then gets a target and initiates a remote call based on a load balancing algorithm, which will be covered in more detail later in the lesson, the Ribbon component.

When the application stops, Eureka Server is also notified to remove the relevant information. After the information is successfully removed, the corresponding client will update the information about the service so that it does not call a service that is already offline, but of course there will be a delay, and there is a possibility that it will call a service that has already failed, so the client will turn on the fail-over function to avoid this problem.

Eureka Server has multiple nodes that form a cluster to ensure high availability, and Eureka Server does not integrate any other third-party storage, but rather stores it in memory.

So Eureka Server replicates the registration information between all the nodes of Eureka Server in the cluster.

This way the data is ****-enabled and any Eureka Client can look up the registry information at any Eureka Server node.

The workflow of Eureka

Eureka's self-protection mechanism

What is self-protection

Officially, self-protection is a security measure against abnormal network fluctuations. Self-protecting mode is a security measure to protect against network fluctuations, and it enables Eureka clusters to run more robustly and stably.

Why enable self-protection?

If Eureka Server does not receive a heartbeat from a service node for a certain period of time (90s by default) (which can be optimized), Eureka Server will remove that service instance.

However, at some point, a network partition failure is encountered, and the service node is actually in a normal state of survival, but is unable to communicate normally with Eureka Server, at which point Eureka Server will cull the service node if a self-protection mechanism has not been introduced.

Mechanism of how self-protection mode works

If more than 85% of client nodes do not have a normal heartbeat for 15 minutes, then Eureka Server assumes that the client and the registry are experiencing a network failure, and Eureka Server enters the self-protection mechanism.

Disadvantages of the self-protection mechanism

If during the self-protection mechanism it happens that some service node goes offline abnormally, but Eureka Server does not reject the service node, the service consumer gets an invalid service instance.

Solution

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

② : Switch the request or circuit breaker, use load balancing, set the number of seconds after a request is not responded to, the speed of the request to switch to the next registered service, for example, using Ribbon + Hystrix. Configure load balancing and circuit breakers.

After Eureka Server enters the self-protection mechanism

1. Eureka Server no longer removes service nodes from the registry because they have not renewed their registry contracts for a long period of time

2. Eureka Server is still able to accept registration and query requests for new services. requests, but they 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

By < /p>

eureka.server.enable-self-preservation=true/false to turn the self-preservation mechanism on or off.

Other key configurations:

Interval to clean up failed service nodes:

eureka.server.evacuation-interval-timer-in-ms default 60s

Lease renewal interval:

eureka.instance. lease-renewal-interval-in-seconds default 30s

Renewal expiration time:

eureka.instance.lease-expiration-duration-in-seconds default 90s

A peek through the source code to see how Eureka turns on its self-protection mechanism

In the first step, we introduce the Eureka Server dependency.

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

In the third step, we go to the AbstractInstanceRegistry class, and we find the evict method, which is the one that is ultimately executed by the thread that periodically culls out tasks. method

In the fourth step, we find the implementation of the isLeaseExpirationEnabled() method

In the fifth step, we notice that

the variable numberOfRenewsPerMinThreshold is critical, it means the minimum number of renewals per minute

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

This is the entire logical flow of Eureka turning on self-protection.

Disabling the self-protection mechanism

1. When the client is able to interact with the service after the service's network partition failure has been lifted, the number of renewals per minute is updated during renewal, and is automatically lifted when the number of renewals per minute is greater than 85%.

2. Restarting the service

Health checking in Eureka

In fact, many frameworks manage health status monitoring through actuator and extend the health endpoint. strong> endpoint.

So that means we just need to integrate Actuator in our project and we can manage monitoring the health state of the project.

The same goes for Eureka, we can tell Eureka Server the status of certain unhealthy service nodes and then Eureka Server will proactively take them offline.

This is Eureka's health check.

How do I implement Eureka-Actuator health checks?

First we have to depend on

spring-boot-starter-actuator in the pom.

Second step, add

eureka.client.healthcheck.enabled=true configuration in the configuration file<

Principle analysis:

First add eureka.client.healthcheck.enabled to the EurekaDiscoveryClientConfiguration based on the value of eureka.client.healthcheck. enabled value to decide whether to assemble the EurekaHealthCheckHandler or not, and then in the EurekaClientAutoConfiguration it will register the HealthCheck, but after we have registered there will be a call to the task to do the state update, which will be done in com.netflix.discovery.InstanceInfoReplicator.run().

Eureka's Multi-Level Caching Mechanism

What is the Multi-Level Caching Mechanism

Eureka Server uses the Multi-Level Caching Mechanism to improve the response time of service requests in order to avoid concurrency conflicts caused by simultaneous reads of memory data. response time for service requests.

Eureka Server's caching is accomplished with a read-only, and a read-write cache.

First-level cache: concurrentHashMap<key,value> readOnlyCacheMap is essentially a HashMap with no expiration time, which saves data information for external output.

readOnlyCacheMap relies on a timer to update, by comparing the value with readWriteCacheMap, readWriteCacheMap prevails.

responseCacheUpdateIntervalMs: readOnlyCacheMap cache update interval, default 30s

Second-level cache: LoaDing<key,value> readWriteCacheMap is essentially a Guava cache. Includes an invalidation mechanism to protect data and information from being exported to the outside world.

responseCacheAutoExpirationInSeconds: readWriteCacheMap cache expiration time, default 180s.

When a service node registers, goes offline, expires, changes state, etc.

1. update the registry information in memory

2. expire the readWriteCacheMap cache at the same time, the cache clearing will only go to clear the readWriteCacheMap cache, readOnlyCacheMap read-only cache is not updated, that is, when the client's information changes, read-only cache is not the first time to sense. readOnlyCacheMap The read-only cache can only be updated by the 30-second timed task.

3. After a period of time (30s by default), the background thread finds that the readWriteCacheMap cache is empty, so it also empties the cache in the readOnlyCacheMap

4. When a service consumer pulls the registry information, it calls the load method of the ClassLoader and loads the registry information from memory into all levels of the cache. registry information into the caches at all levels and returns the registry information.

There are two threads in Eureka Server, one that synchronizes the data in the two caches at regular intervals, 30s by default, and one that detects heartbeat failures at regular intervals, 90s by default.

Service pulls

1. The service consumer, by default every 30s, pulls the registry information

2. > 2. fetch the information from readOnlyCacheMap, if fetch is empty

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

4. call ClassLoader's load method to load the in-memory registry information into all levels of the cache and return the registry information.

Regional Configuration for Eureka

When users are geographically distributed over a wide range, such as when a company has branches in Shanghai, Hangzhou, Qingdao, and so on, there are usually multiple server rooms.

So for users, of course, they want to invoke microservices from the local branch's server room.

For example, if user A in Shanghai calls the OAuth2 service, of course user A wants to call the microservice application in the Shanghai server room. If user A in Shanghai calls the OAuth2 service in the Hangzhou server room, it increases the latency time.

So we want to prioritize services in one server room to call services in the same server room, and when services in the same server room are unavailable, then call services in other server rooms to reduce latency.

To this end, eureka provides two concepts of region and zone for partitioning. Eureka is based on the Amazon design, so the distinction between geography is also consistent with Amazon, which is divided into multiple regions, and each region contains multiple zones, so the Eureka design can also be set up. region and zone, the request can be prioritized with the request service in the same zone of the service.

Basic Configuration

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

Generally speaking, we use Ribbon to load-balance microservices, and Ribbon has some specialized load policy algorithms, although as we said, we prioritize requests for service instances in the specified Zone under the specified region.

But in some cases, for example, when there is no available zone under Region=shanghai, the system will load DEFAULT_ZONE by default, or if the load on a service in the same region is too high..., it will also automatically switch to another service in the same region.

The system automatically switches to a different zone if there is no zone available in Shanghai.

Eureka's retry mechanism

Since the service governance mechanism implemented in Spring Cloud Eureka emphasizes the CAP principles of AP, Availability and Reliability, at the expense of a certain amount of consistency (in the extreme case it would rather accept a failed instance than lose a "healthy" one, it's not a good thing that we're not able to use it), it's a good thing that we're able to use it as a service. This is like the self-protection mechanism we described above).

But whether the protection mechanism is triggered or there is a delay in service culling that causes a service to call one of these malformed services, the call will fail, and the other services won't work!

This is obviously not something we want to see, and we still want to enhance fault tolerance for these kinds of problems. So, we usually include some kind of retry mechanism when implementing service calls.

Starting with the Camden SR2 release, Spring Cloud has integrated Spring Retry to enhance the retry capabilities of RestTemplates, so that developers can simply configure the service accesses that were originally implemented through RestTemplates to automatically implement retry policies based on the configuration.

Turning on Eureka's retry mechanism is simple, first we introduce the Spring Retry dependency in pom:

Then configure

spring.cloud.loadbalancer.retry.enabled parameter in the configuration file to control the retry mechanism on/off, as the Spring Retry is on by default, so that we just need to introduce the dependency, if we want to turn it off we just need to set spring.cloud.loadbalancer.retry.enabled to false.

In fact, in the SpringCloud architecture components whether Fegin, Ribbon, or Zuul provides a retry mechanism, these are not for the time being, and then talk about the specific components and then analyze the specifics.

Practical Eureka Registry Deployment

Eureka Server project build

1. Create a springcloud-eureka-server project, and then in the pom add

spring-cloud-starter-netflix-eureka-server dependency in the pom.

2. Add the

spring-cloud-starter-netflix-eureka-server dependency to the pom.xml file

3. On the startup class

SpringcloudEurekaServerApplication use the @EnableEurekaServer to enable auto-assembly of EurekaServer.

4. Add the configuration file application.properties

5. Start the project and then access the flix-eureka-client dependency.

2. Turn on auto-assembly of EurekaServer using @EnableEurekaClient on the startup class

SpringcloudEurekaClientApplication.

Configure

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

Launching the client and refreshing the Eureka home page that we just opened, we find that the service has been successfully registered.

Adding Password Authentication to the Eureka Registry

Above, we see that after we set up the Eureka Server, we went to http://localhost:8761/ , and were able to see the Eureka administration page without logging in.

In practice, if the registry address has a public IP, it will be directly accessible, which is not safe. So we need to transform Eureka by integrating Spring-Security for secure authentication, plus permissions authentication to ensure security.

First, introduce the Spring-Security dependency in pom.xml

Then add the authentication configuration information in application.properties

Finally, add the Spring Security configuration class

This way, we start the Eureka After the Server is up and running, go to http://localhost:8761/ and your browser will prompt you for a username and password, which you will need to enter correctly before you can continue to access the management pages provided by Eureka.

Summary

In this chapter, we learned about Eureka. Although Eureka has been discontinued, many companies still use it, and it is stable enough to provide enough functionality for most companies. So now in the interview, Eureka related topics still often appear. Anyway, if you learn it, it's your own.

I wish you all to become big bulls with black hair soon.