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

This article will explain in detail how Eureka is about service governance in Spring Cloud. The content of the article is of high quality, so the editor will share it with you for reference. I hope you will have a certain understanding of the relevant knowledge after reading this article.

First, please tell the difference between eureka and zookeeper & why microservice governance chooses Eureka over zookeeper?

The so-called CAP principle: C:Consistency consistency A:Availability availability P:Partition tolerance partition fault tolerance

A distributed system cannot satisfy C (consistency), A (availability) and P (partition fault tolerance) at the same time. Since partition fault tolerance P must be guaranteed in distributed systems, we can only make a tradeoff between An and C.

Zookeeper complies with CP

When querying the list of services from the registry, we can tolerate that the registry returns the registration information from a few minutes ago, but we cannot accept that the service is directly down unavailable. In other words, the service registration function requires consistency higher than availability.

However, there will be such a situation in zookeeper, when the master node loses contact with other nodes because of a network failure, the remaining nodes will re-elect leader.

The problem is that the election time of leader is too long, 30 seconds and 120s, and the whole zookeeper cluster is not available during the election, which leads to the paralysis of the registration service during the election.

In the cloud deployment environment, it is highly likely that the zookeeper cluster will lose its master node due to network problems. Although the service can eventually be restored, the long-term unavailability of registration caused by a long election time cannot be tolerated.

Perhaps this answer is too abstract to put it in another way:

When one zookeeper is dead, the other zookeeper will have an election (strong consistency: I must keep the data consistent). During this election, zookeeper is not available, and users are upset when there are users currently using it.

Eureka complies with AP

Eureka: I understand this, so usability is a priority at design time.

All the nodes in Eureka are equal, the failure of several nodes will not affect the work of normal nodes, and the remaining nodes can still provide registration and query services.

When the client of Eureka registers with an Eureka, if the connection fails, it will automatically switch to another node.

As long as there is an Eureka, the registration service can be guaranteed (guaranteed availability), but the information found may not be up-to-date and does not guarantee strong consistency.

In addition, Eureka also has a self-protection mechanism. If more than 85% of the nodes do not have a normal heartbeat within 15 minutes, then Eurekas believes that there is a network failure between the client and the registry, and the following situations will occur:

1. Eureka no longer removes services from the registration list that should expire because they have not received a heartbeat for a long time.

2. Eureka can still accept registration and query requests for new services, but it will not be synchronized to other nodes (that is, to ensure that the current node is still available)

3. When the network is stable, the new registration information of the current instance will be synchronized to other nodes

Therefore, Eureka can well deal with the situation that some nodes lose contact due to network failure, and it will not paralyze the whole registration service like zookeeper.

Basic principles

After the service starts, it registers with Eureka, and Eureka Server synchronizes the registration information with other Eureka Server.

When the consumer invokes the provider, it obtains the service provider address from the service registry, then caches the service provider address locally, and the next time it is called, it is read directly from the local cache to complete a call.

When the service registry EurekaServer detects that the provider is unavailable due to downtime, network reasons, etc., the service is set to Down status in the service registry, and the status of the current service provider is published to the subscriber, and the subscribed consumers update the local cache.

After startup, the service provider periodically (default is 30 seconds) sends a heartbeat to Eureka Server to prove that the current service is available. If Eureka Server does not receive the heartbeat of the client for a certain period of time (default is 90 seconds), the service is considered to be down and the instance is logged out.

Summary: it is better to choose Eureka as the service registry, because the registration service is more important for availability, and we can accept that we can not achieve consistency in a short period of time.

II. Eureka High availability principle

By default, Eureka allows the service registry not to register itself

# because the application is a registry, it will not register itself

Register-with-eureka: true

# there is no need to retrieve services on the registry

Fetch-registry: true

Eureka High availability actually registers itself as a service with other service registries, so that it can form a set of service registries that register with each other, thus realizing the synchronization of service lists and achieving high availability.

So much for the sharing of service governance Eureka in Spring Cloud. I hope the above content can be helpful to you and learn more knowledge. If you think the article is good, you can share it for more people to see.

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.