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

introduction

Eureka is Netflix's open source service for service registration and discovery. Spring Cloud Eureka is based on Eureka for secondary packaging, adding a more user-friendly UI and making it easier to use. However, due to the existence of many caches in Eureka itself, the service status update lags behind. The most common situation is that the status is not updated in time after the service is offline, and the service consumer invokes the offline service, causing the request to fail. Based on Spring Cloud Eureka 1.4.4.RELEASE, this article introduces Eureka's caching mechanism under the premise of default region and zone.

I. AP characteristics

From CAP theory, Eureka is an AP system, which gives priority to availability (A) and partition fault tolerance (P), does not guarantee strong consistency (C), and only guarantees final consistency, so more caches are designed in the architecture.

II. Status of Service

Eureka service status enum class: com. netfli.appinfo.InstanceInfo.InstanceStatus

Status Description Status Description UP ONLINE OUT_OF_SERVICE DOWN FAILURE DOWN UNKNOWN Unknown STARTING Starting III Eureka Server

In the Eureka high availability architecture, Eureka Server can also register with other servers as a Client, and multiple nodes register with each other to form an Eureka cluster, and clusters are regarded as peers. When the Eureka Client registers, renews, or updates its status with the Server, the receiving node updates its own service registration information, and then synchronizes to other peer nodes one by one.

Note: If server-A registers unidirectionally with server-B, server-A regards server-B as a peer node, and the data received by server-A will be synchronized to server-B, but the data received by server-B will not be synchronized to server-A.

3.1 caching mechanism

Eureka Server has three variables: (registry, readWriteCacheMap, readOnlyCacheMap) to store service registration information, scheduled tasks synchronize readWriteCacheMap to readOnlyCacheMap every 30s by default, clean up nodes that have not been renewed for more than 90s every 60s, Eureka Client updates service registration information from readOnlyCacheMap every 30s, and UI updates service registration information from registry.

third-level cache

Cache type description registryConcurrentHashMap real-time update, class AbstractInstanceRegistry member variable, UI request is the service registration information readWriteCacheMapGuava Cache/LoadingCache real-time update, class ResponseCacheImpl member variable, cache time 180 seconds readOnlyCacheMapConcurrentHashMap periodic update, class ResponseCacheImpl member variable, default every 30s update from readWriteCacheMap, Eureka client default update service registration information from here, configurable directly from readWriteCacheMap update

cache correlation configuration

###

Configuration default description eureka.server.useReadOnlyResponseCachetrueClient updates data from readOnlyCacheMap, false skips readOnlyCacheMap updates directly from readWriteCacheMap eureka.server.responsecCacheUpdateIntervalMs30000readWriteCacheMap updates to readOnlyCacheMap cycle, default 30seureka.server.evictionInterValTimerInMs60000 cleanup unrenewed nodes (evict) cycle, default 60seureka.instance.leaseExpiration DurationInSeconds90 cleanup unrenewed nodes timeout, default 90s

key classes

Class Description com. netfli.eureka.registry.AbstractInstanceRegistry holds service registration information, holds registry and responseCache member variables com. netfli.eureka.registry.ResponseCacheImpl holds readWriteCacheMap and readOnlyCacheMap member variables IV. Eureka Client

The Eureka Client has two roles: service provider and service consumer, and as a service consumer it is generally used in conjunction with Ribbon or Feign (Feign internal ribbon). After Eureka Client is started, it immediately registers with Server as a service provider and renews every 30s by default; as a service consumer, it immediately updates the service registration information to Server in full, and updates the service registration information incrementally every 30s by default;Ribbon delays 1s to obtain the service registration information used from Client, and updates the service registration information used by default every 30s, and only stores the service in UP status.

second level cache

Cache type description localRegionAppsAtomicReference periodic update, class DiscoveryClient member variable, Eureka Client save service registration information, immediately update to Server after startup, default update every 30s increment upServerListZoneMapConcurrentHashMap periodic update, class LoadBalancerStats member variable, Ribbon save service registration information in use and status UP, delay 1s update to Client after startup, default update every 30s

cache correlation configuration

Configuration default description eureka. instance. leaseRenewal IntervalInSeconds30Eureka Client renewal cycle, default 30seureka.client.registryFetchIntervalSeconds30Eureka Client incremental update cycle, default 30s (incremental update under normal circumstances, timeout or inconsistent with the Server side, etc., full update) ribbon. ServerListRefresh Interval30000Ribbon update cycle, default 30s

key classes

Class Description com. netfli.discovery.DiscoveryClientEureka Client is responsible for registration, renewal and update, method initScheduledTasks() initializes renewal and update scheduled tasks com. netfli.loadbalancer. PollingServerListUpdateRibbon updates used service registration information, starts initializing update scheduled tasks com. netfli.loadbalancer.LoadBalancerStatsRibbon, saves used service registration information with UP status Maximum perceived time of service consumer under default configuration Eureka Client time description online 30 (readOnly)+30(Client)+30(Ribbon)=90 readWrite-> readOnly -> Client -> Ribbon 30s each Normal offline 30 (readonly)+30(Client)+30(Ribbon)=90s Service normal offline (kill or kill -15 kills the process) will give the process a chance to clean up, DiscoveryClient.shutdown() will update its state to DOWN to the Server, and then send a Delete request to log off itself, registry and readWriteCacheMap update in real time, Therefore, the UI will no longer display an abnormal outage of the service instance 30+60(evil)*2+30 + 30= 240s. An abnormal outage of the service (kill -9 kills or crashes the process) will not trigger the DiscoveryClient.shutdown() method. Eureka Server will delete the service instance from the registry and readWriteCacheMap by cleaning up unrenewed services for more than 90s every 60s.

Consider the following

The service does not notify Eureka Client to log off directly at 0s; the first expiration check evict does not exceed 90s at 29s; the second expiration check evict does not exceed 90s at 89s; the third expiration check evict has not been renewed for more than 90s at 149s, so the service instance is deleted from registry and readWriteCacheMap; the scheduled task is updated from readWriteCacheMap to readOnlyCacheMap at 179s; Eureka Client is updated from readOnlyCacheMap of Eureka Server at 209s; and the Ribbon is updated from Eureka Client at 239s.

Therefore, in the extreme case, the longest perception time of service consumers will approach 240s infinitely.

VI. Response measures

The service registry's choice to use Eureka indicates that it has accepted its preference for availability (A) and partition tolerance (P) over strong consistency (C). If strong consistency (C) is a priority, CP systems such as ZooKeeper should be considered as service registries. Distributed systems are generally configured with multiple nodes, and the status update lag of a single node has no effect on service online. Here, the countermeasures for status update lag after service offline are mainly considered.

6.1 Eureka Server

1. Shorten the readOnlyCacheMap update cycle. Shortening this timed task cycle reduces lag time.

eureka.server.responsecCacheUpdateIntervalMs: 10000 # Eureka Server readOnlyCacheMap update cycle

2. Close readOnlyCacheMap. Small and medium-sized systems can consider this scenario, where Eureka Client updates service registration information directly from readWriteCacheMap.

eureka.server.useReadOnlyResponseCache: false #Whether to use readOnlyCacheMap6.2 Eureka Client

1. Service consumers use fault tolerance mechanisms. For example, Spring Cloud Retrieval and Hystrix, Ribbon, Feign and Zuul can configure Retrieval. When a service consumer visits a offline node, it usually reports ConnectTimeout. At this time, the next node can be retried through the Retrieval mechanism.

2. Service consumers shorten the update cycle. Eureka Client and Ribbon L2 cache affect state updates, shortening these two timed task cycles reduces latency, for example configuration:

eureka.client.registryFetchIntervalSeconds: 5 # Eureka Client Update Period ribbon. ServerListRefresh Interval: 2000 # Ribbon Update Cycle

3. The service provider guarantees that the service is offline normally. Use the kill or kill -15 command when the service is offline to avoid using the kill -9 command. When the kill or kill -15 command kills the process, the shutdown() method of Eureka Client will be triggered, and the registration information in the registry and readWriteCacheMap of the Server will be deleted actively. It is not necessary to rely on the evict of the Server.

4. Service provider delays offline. Before a service goes offline, call the interface to make the service status saved in Eureka Server DOWN or OUT_OF_SERVICE before going offline. The time difference between the two is determined according to the cache mechanism and configuration. For example, by default, a delay of 90s after calling the interface before going offline can ensure that the service consumer will not call the offline service instance. VII. Gateway realizes real-time sensing of service offline

In software engineering, there is no problem that the middle tier cannot solve, and gateways are the middle tier between service providers and service consumers. Take Spring Cloud Zuul Gateway as an example. The gateway stores service registration information as an Eureka Client. The service consumer forwards the request to the service provider through the gateway. When the service provider goes offline, it only needs to notify the gateway to invalidate the service in the service list saved by itself. To maintain gateway independence, an independent service can be implemented to receive outage notifications and coordinate gateway clusters. The next article will detail how the gateway realizes real-time service offline awareness, so stay tuned!

Author: Feng Yongbiao

Source: Yixin Institute of Technology

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.