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

This article mainly explains "Can Eureka still tune in after hanging up micro-services"? The explanation content in this article is simple and clear, easy to learn and understand. Please follow the ideas of Xiaobian to study and learn "Can Eureka still tune in after hanging up micro-services" together?

1. Practice it.

This kind of problem, listen to others say N times, it is better to practice it manually and remember clearly.

You can quickly set up an Eureka service registry, then set up a service consumer and service provider, register the two services to Eureka, and finally simply invoke the service provider on the service consumer. This process is very simple, I believe that everyone who has learned Spring Cloud a little can do it, if you can't do it, you can refer to Song Ge's video (Spring Boot + Vue + Spring Cloud series video tutorial).

After the service is tuned, close Eureka, pay attention not to close the service provider and service consumer, after closing, continue to call the service provider with the service consumer,"at this time you will be surprised to find that the service can still be tuned!"

2. cause analysis

Why can services be invoked after Eureka is shut down? Let's start with a simple service invocation diagram:

Let me explain this process:

Eureka starts as a service registry.

Provider and Consumer are started as services respectively, and registered to Eureka. Take provider as an example. When provider registers, it will tell eureka, my name is provider, my address is xx.xx.xx, my port is xx, and my xx is xx. That is to say, provider will tell eureka some metadata information of itself; similarly, consumer is the same.

Next, the consumer wants to call the provider's interface, but it does not know what the provider's address is, he only knows that the service to be invoked is called provider, so the consumer finds eureka and queries the specific address and port of the provider from eureka. This specific address and port may be one or more (clustered deployment).

After the consumer obtains the address and port of the provider, it then directly calls the provider.

From the above flowchart, you can see that once the consumer gets the specific address of the provider, the next call actually has no eureka.

So, we say that once Eureka dies, microservices can be tuned,"but only if there are preconditions."

What premise? The address of the provider has not changed! If the provider changes an IP address or port, at this time, the consumer will not be able to detect this change in time, and it will not be able to adjust. When Eureka does not hang up, the IP change of the provider can be perceived by the consumer through Eureka, and then the call address can be adjusted. Now Eureka hangs up, the consumer cannot perceive it.

Since the article has been written here, let's take a look at some of the principles involved in Spring Cloud here.

3. related principles

Eureka itself can be divided into two main parts, Eureka Server and Eureka Client.

Let's look at Eureka Server:

3.1 Eureka Server

Eureka Server provides three main functions:

Service registration, all services are registered to Eureka Server, this is Eureka basic function.

Provide registry, registry is a list of all registered services, Eureka internal through a two-tier cache mechanism to maintain this registry. Eureka Client needs to obtain this registry when invoking the service. Generally speaking, this registry will be cached. If the cache fails, it will directly obtain the latest registry.

Eureka Client synchronizes the state of the current client with Eureka Server through registration, heartbeat and other mechanisms, so that Eureka Client can detect changes in time.

3.2 Eureka Client

Services to register to Eureka above, this registration itself is an HTTP request, but their own handwritten registration process is too cumbersome, Eureka Client can help us simplify the registration process.

In general, the Eureka Client has several features:

service registration

The service provider registers itself in the service registry (Eureka Server). It should be noted that the so-called service provider is only a division of the business. In essence, it is an Eureka Client. When an Eureka Client registers with an Eureka Server, it needs to provide some metadata information about itself, such as IP address, port, name, running state, etc., which will also be obtained by future service consumers.

Get registration information

The Eureka Client gets the registration information for the service from the Eureka Server and caches it locally.

When Eureka Client needs to invoke a remote service, it will look up the IP address and port corresponding to the remote service from this information. The service registry information cached on the Eureka Client is updated periodically (30 seconds) and if the registry information returned by the Eureka Server differs from the registry information cached locally, the Eureka Client automatically handles it.

There are also two attributes involved:

One is whether registry information is allowed: eureka.client.fetch-registry=true.

The other is the service registration information cached on the Eureka Client, which is updated periodically at intervals of 30 seconds by default and can be modified by the following attribute: eureka.client.registry-fetch-interval-seconds=30.

service renewal

Once Eureka Client is registered on Eureka Server, Eureka Client sends a heartbeat message to Eureka Server every 30 seconds by default to tell Eureka Server that it is still running.

If Eureka Server does not receive an Eureka Client renewal message for 90 seconds (three consecutive times), it assumes that the Eureka Client has been disconnected and removes the disconnected Eureka Client from the current service registration list.

There are two related attributes (generally not recommended to modify):

eureka.instance.lease-renewal-interval-in-seconds indicates the renewal time of the service, which defaults to 30 seconds.

eureka.instance.lease-expiration-duration-in-seconds indicates the service expiration time, which defaults to 90 seconds.

Service offline

When the Eureka Client goes offline, it sends a message telling the Eureka Server that it is offline.

Thank you for reading, the above is the content of "Eureka hanging micro-service can still be tuned", after the study of this article, I believe everyone has a deeper understanding of Eureka hanging micro-service can still be tuned, the specific use situation still needs to be verified by practice. Here is, Xiaobian will push more articles related to knowledge points for everyone, welcome to pay attention!

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.