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

The last article, "Eureka caching mechanism", introduced the caching mechanism of Eureka. I believe you have a better understanding of Eureka. This article will describe in detail how the API gateway realizes the real-time awareness of service referrals.

I. Preface

In cloud-based micro-service applications, the network locations of service instances are dynamically assigned. And service instances often change dynamically due to automatic scaling, failures, and upgrades. Therefore, the client code needs to use a more complex service discovery mechanism.

At present, there are two main modes of service discovery: client discovery and server discovery.

Server discovery: the client initiates a request to the service registry through the load balancer, and the load balancer queries the service registry and routes each request to the available service instance.

The client discovers that the client is responsible for determining the network address of the available service instance, and the client accesses the service registry, that is, a database of available services, to the request load balance in the cluster. then the client uses a load balancing algorithm to select an available service instance and initiate a request.

The biggest difference between client discovery and server discovery is that the client knows (caches) the available service registry information. If the cache on the Client side is not updated in time from the server, there may be inconsistencies between the Client and the server cache data.

Second, the gateway is used in conjunction with Eureka

Netflix OSS provides a good example of client service discovery. Eureka Server is the registry center. Compared with Eureka Server, Zuul means that Eureka Client,Zuul caches the Eureka Server service list locally and updates the service list in the form of scheduled tasks. At the same time, zuul discovers other services through the local list and uses Ribbon to achieve client load balancing.

Normally, the caller initiates a request to the gateway and gets an immediate response. However, in the case of downsizing, offline and upgrading to the producer, due to the multi-level cache design structure of Eureka and the regular update mechanism, the service list B on the LoadBalance side is not updated in time (as can be seen from the previous article "Eureka cache mechanism", the longest perceived time of the service consumer will infinitely approach 240 s). If the consumer initiates a request to the gateway, LoadBalance will initiate a request for a service that no longer exists. The request will time out.

Third, the realization idea of solution 3.1

After the producer goes offline, the first one to be perceived is the readWriteCacheMap in the Eureka Server, and the last one is the LoadBalance in the gateway core. But loadBalance's discovery of producers is in the list maintained locally by loadBalance.

So to achieve the gateway's real-time perception of the offline producer, you can do this: first, the producer or deployment platform actively notifies Eureka Server, then skips the update time between Eureka multi-level caches, directly notifies Eureka Client in Zuul, and finally updates the list of services in Eureka Client to Ribbon.

However, if the logic code of offline notification is placed in the producer, it will cause code pollution, language differences and other problems.

To borrow a famous saying:

"any problem in computer science can be solved by adding an indirect middle layer."

Gateway-SynchSpeed is equivalent to a proxy service, it provides REST API to respond to the caller's offline request, and synchronizes the state of the producer to the Eureka Server and gateway core, playing the role of state synchronization and soft things.

Idea: before the producer downsizes, goes offline, or upgrades, the spider platform (spider is the container management platform) will actively notify Gateway-SynchSpeed that an instance of a producer is going offline, and then Gateway-SynchSpeed will notify the Eureka Server producer that an instance is offline; if the Eureka Server is successfully offline, Gateway-SynchSpeed will directly notify the gateway core.

Design features

Non-invasive and easy to use. Regardless of what language the caller is based on, the caller only needs to make a http rest request to the Gateway-SynchSpeed, and the real implementation logic does not invade the caller but is handed over to the agent to implement.

Atomicity. The caller first goes offline in the Eureka Server, and then the downline is the minimum work execution unit in the core of all relevant gateways. Gateway-SynchSpeed is equivalent to a "soft thing", which ensures the atomic characteristics of the service offline to some extent.

3.2 implementation steps

Step description

Step 1: before the producer downsizes, goes offline, and upgrades, the spider platform will notify the Gateway-SynchSpeed service in the form of a http request with the notification granularity of the container IP where the service instance resides.

Step 2: after receiving the request, Gateway-SynchSpeed verifies the availability of IP, and then notifies Eureka Server.

Step 3: Eureka Server sets Producer to invalid state and returns the processing result (Eureka offline is divided into two forms, one is directly deleted from the service registration list, and the second is offline, that is, setting the status of Producer to OUT_OF_SERVICE. If it is offline in the first form, after the Spider platform issues the offline request, there is no guarantee that the Producer process will be kill immediately. If the Producer still has a heartbeat synchronized to Eureka Server during this period, the service will re-register to Eureka Server).

Step 4: Gateway-SynchSpeed gets the result of the previous step, and if the result is successful, execute the next step; otherwise, stop.

Step 5: Gateway-SynchSpeed is Eureka Client. Gateway-SynchSpeed gets the Application-Name of Producer through IP to the local service registration list.

Step 6: Gateway-SynchSpeed queries all gateway group names related to offline services in the gateway core database through Application-Name.

Step 7: Gateway-SynchSpeed uses the gateway group name to find all the service addresses ipAddress (ip: port) under the gateway group in the local service list.

Step 8: Gateway-SynchSpeed notifies all relevant gateway nodes asynchronously.

Step 9: after receiving the notification, Gateway-Core will offline the Producer and record the instance information of all successful offline instances to the cache DownServiceCache.

Step 10: Gateway-Core updates the local Ribbon service list.

IV. Compensation mechanism

Eureka provides a security mechanism. Before Eureka Client updates the service list from Eureka Server, it verifies whether the relevant hash value has changed (if the Client service list is modified, the hash value will change). If so, the update method will change from incremental update to full update. (as can be seen from the "Eureka cache mechanism", there may be differences between readOnlyCacheMap and readWriteCacheMap data within these 30 seconds. If the Client cache list is overwritten by readOnlyCacheMap, the Ribbon service list will eventually be inconsistent with the readWriteCacheMap data.

For the Eureka mechanism, the listener EurekaEventListener is introduced as the compensation mechanism, which listens for all Eureka Client pull events and resets the status of the service in the cache to OUT_OF_SERVICE for less than 30 seconds.

Fifth, API security design

Considering the security of the system, if it is accessed maliciously, it may make the producer offline in Eureka Server for no reason, so that consumers can not find the producer through Eureka Server.

Use blacklist and whitelist for security filtering. The basic process is as follows:

Set whitelist network segment (IP network segment) in Gateway-Synchspeed

Add a filter to Gateway-Synchspeed to verify the IP of the offline requestor. If the requester IP is in the network segment, it will be released; otherwise, filter.

VI. Log backtracking

Because Gateway-SynchSpeed and Gateway-Core are deployed in the Docker container, if the container is restarted, all the log files will be lost. Therefore, the relevant logs in Gateway-SynchSpeed and Gateway-Core need to be written to Elasticsearch, and finally Kibana is responsible for querying the data of Elasticsearch and displaying it in a visual way.

7. Code snippet display

Gateway-SynchSpeed does status synchronization

EurekaEventListener handles cached data

VIII. Supplementary explanation

Currently, the Zuul and Eureka versions used by the gateway to realize the real-time awareness of offline services are Spring Cloud Zuul 1.3.6.RELEASE and Spring Cloud Eureka 1.4.4.RELEASE.

At present, the gateway realizes real-time awareness of the downstream services of the gateway, and the following conditions need to be met:

Producers need to deploy on the kubernetes container management platform

Producers do normal offline, upgrade or downsizing operations. If the service goes offline abnormally due to insufficient container resources, such as abnormal downtime, it is not supported.

Gateway service offline real-time awareness is an optional solution provided by the gateway to the business side. This feature is not enabled by default in the spider platform. Whether this feature is enabled or not is decided by the business side according to its own system requirements. For more information on how to configure it, please see "Gateway Real-time Awareness configuration documentation on spider" in the API Gateway access Guide.

Author: Xie Guohui

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.