“This is the 10th day of my participation in the First Challenge 2022. For details: First Challenge 2022”

I. Brief process of service registration discovery

Here’s a quick look at what eureka’s service registration discovery process looks like:

1. The service provider provides application services and registers with eureka Server.

2. Service consumers go to the registry every 30 seconds to pull service IP, port, interface address and other information.

3. After the service consumer pulls the application information of the service provider, it can directly invoke the interface of the service provider.

Second, the overall process of service discovery registration

Iii. Main concepts and principles

The service registry

The principle of service registration mainly involves the storage structure of Eureka Server, using a three-tier cache structure. The concrete internal implementation logic refers to the figure in the second.

The hierarchy The name of the implementation Update the way Data changes
The first layer ReadOnlyCacheMap (read-only) ConcurrentHashMap Scheduled update (default 30s) ReadWriteCacheMap is pulled periodically
The second floor readWriteCacheMap guava Updated in real time Guava’s load mechanism
The third layer Register Double ConcurrentHashMap Updated in real time Client registration, renewal, and offline

The service contract

When the service provider finishes registering the service information, it maintains a heartbeat and periodically sends rest requests to the Eureka Server to tell it that it is still alive. The default heartbeat interval is 30 seconds.

Service access

The Eureka client obtains registered service information from the Eureka Server periodically (default 30s). The acquisition can be full or incremental.

By default, after the client is started for the first time, it sends a full fetch to the server and caches local information. After that, it sends an incremental fetch to the server every 30 seconds to update the local cache.

The service call

Typically, inter-service invocations use the component Feign to initiate REST requests;

The ribbon is integrated with eureka. By default, the ribbon uses the polling load strategy to pull the registration information pulled by Eureka client to itself to achieve load.

Service offline

Indicates to remove the registration information for the service from the registry so that the service cannot be invoked.

Service offline:

way implementation The effect
Direct suspension of service Direct Kill service In the 90s, the registry detected that the service was not renewed, so it deleted the service and could not be offline immediately
Force offline through the registry interface Send delete to the Eureka registry By default, the heartbeat mechanism is set to 30 seconds. If the service is not stopped during this period, the service will come online again
The client is logged out @GetMapping(“/offline”)

public void offline(){

DiscoveryManager.getInstance().shutdownComponent();

}		 Elegant referral service

Failure to eliminate

Eureka Server has a scheduled task Evict, which is executed every 60 seconds by default. Its scope is on readWriteCacheMap and Register.

When some service providers do not renew their services within the default 90s, the invalid registration information will be removed when Evict is executed. Usually the service is down or forced to kill the service.

To protect themselves

Official definition: Self-protection mode is a security protection measure against abnormal network fluctuations. Using self-protection mode can make Eureka cluster more robust and stable operation.

During the Eureka Server run, the Eureka Server will count whether the rate of heartbeat failures is less than 85% within 15 minutes. If the rate is lower, the Eureka Server will protect the current instance registration information and will not let it expire immediately.

This configuration is enabled by default.

Problems of self-protection: During self-protection, the service is suspended and cannot be offline. As a result, the interface fails to be invoked.

After the Eureka outage, services can still communicate with each other.

Because The Eureka client caches registry information locally, services can still be accessed after the Eureka Server is down, but the service provider and service consumer are divided into the following situations:

  • After the service consumer is restarted, the local cache is invalid and the mapping between the service provider and the service consumer does not exist. Therefore, service invocation cannot be performed.
  • After the service provider is restarted, the local cache of the service caller still contains the cached information before eureka is down, and the service can be invoked normally.

Synchronize cluster registration information

  • Eureka adopts peer to peer (peer replication) synchronization. There is no master or slave between copies. Any copy can receive write operations and then each copy updates data.

  • The Eureka Server itself relies on the Eureka Client, that is, each Eureka Server acts as a Client of other Eureka servers.

  • After the Eureka Server is started, the Eureka Server requests a node of other Eureka Server nodes through the Eureka Client to obtain the registered service information and copy it to other peer nodes.

  • When the Eureka Server changes its own information, for example, the Client sends a request for registration, renewal, or deregistration to the Eureka Server, the Eureka Server sends the latest information to other Eureka servers to ensure data synchronization.

  • Existing problems:

    • (1) Each node can be written, resulting in data conflicts.

    • (2) If your information changes are synchronized from another Eureka Server, and then synchronized back, there will be a data synchronization loop.

  • Problem (1) Solution:

    Eureka solves this problem with a version-like attribute called lastDirtyTimestamp. LastDirtyTimestamp is an attribute of a service instance in the registry that represents the last time this service instance was changed.

  • Solution to Problem (2) :

    When the Eureka Server performs the replication operation, it uses the HTTP header HEADER_REPLICATION to distinguish normal requests of common application instances. This indicates that the request is a replication request. In this way, other peer nodes do not replicate the request. Avoid the loop.

Eureka guarantees AP in CAP

As we have learned above, Eureka does not guarantee strong data consistency, but only final data consistency and high availability through cluster mode.