The article "Eureka caching mechanism" describes the Eureka caching mechanism, I believe we have a better understanding of Eureka, this article will detail how to achieve real-time API Gateway aware services offline.
I. Introduction
Cloud-based service applications in the micro network location service instances allocated dynamically. And because auto-scaling, fault and upgrades, service instances will often change dynamically. Therefore, the client code needs to use more complex service discovery mechanism.
Currently serves mainly found in two modes: client-side service discovery and discovery.
- Server discovery: Client initiated by the load balancer to the service registry request, load balancer inquiry service registry, each request is routed to an available service instances.
- Client Discovery: The client is responsible for determining available network address of the service instance, and the request load balancing, client access service registration form, which is a database of available services in the cluster, and then the client uses a load balancing algorithm to select a examples of services available and then initiates a request.
The client-side service discovery with respect to the discovery biggest difference is: the client knows (cache) services available registry information. Client-side caching if not timely updates from the server, then inconsistent Client and server cache data may happen.
Second, the combination gateway and Eureka
Netflix OSS provides a good example of a client service discovery. Eureka Server as the registry, Zuul relative to Eureka Server is Eureka Client, Zuul Eureka Server will end service to the local cache list, and in the form of regular tasks of updating the list of services, and other services through local zuul found list, use the Ribbon implement the client load balancing.
Under normal circumstances, the caller initiates a request to the gateway can get immediate response. But when the producers do volume reduction, off the assembly line, upgrade of the situation, due to the design of this multi-level cache architecture Eureka and mechanisms regularly updated, LoadBalance end of the list of B services exist not updating the situation (by the previous article " Eureka caching mechanism " can be seen, the longest serving consumers perceive time infinitely approaching 240s), then if the consumer initiates a request to the gateway, LoadBalance have a non-existent service initiation request, the request will time out.
Third, the solution
3.1 realization of ideas
After the producers off the assembly line, the first to get the perception that the Eureka Server in readWriteCacheMap, finally get the perception of a gateway in the core LoadBalance. But loadBalance found to producers in loadBalance locally maintained list.
So in order to achieve real-time gateway perception of producers off the assembly line, you can do this: First, the producer or deployment platform for proactive notification Eureka Server, and then skip the update time between Eureka multi-level cache, directly notified Zuul in Eureka Client, Finally, the list of services Eureka Client is updated to the Ribbon.
However, if an offline notification logic code on producers, the code that will cause pollution problems, language differences.
Borrowing a famous saying:
"Any problem in computer science can be solved by adding an indirect middle layer"
Gateway-SynchSpeed the equivalent of a proxy service, which provide external REST API for offline responds to the caller's request, while the state will be synchronized to the producers of Eureka Server and gateway core, synchronization status and plays the role of soft things.
Ideas : the producer to do volume reduction, off the assembly line, upgrade ago, spider platform (spider container management platform) will take the initiative to inform an instance of Gateway-SynchSpeed a producer to be down, then Gateway-SynchSpeed will notify Eureka an instance of producers Server is down; if Eureka Server offline success, gateway-SynchSpeed core gateways will be notified directly.
Design Features
-
Non-invasive, easy to use. Do not care what language the caller, the caller as long as Gateway-SynchSpeed initiate a request to http rest based on the true realization of logic but not intrusive to the caller to the agent to achieve.
-
Atomicity. The caller first in Eureka Server offline, then the next line is the minimum operating execution units in all relevant core gateways, Gateway-SynchSpeed the equivalent of a "soft thing" to ensure some degree atomic nature of the service offline.
3.2 Implementation steps
Step Description
-
The first step: the producer do volume reduction, offline, upgrade before, Spider platform will notify the Service Gateway-SynchSpeed http request form, the particle size of the notification service IP instance where the container.
-
Step Two: Gateway-SynchSpeed after receiving the request, to check the availability of IP, and then notify the Eureka Server.
-
The third step: Eureka Server to set Producer failure condition, and returns the processing result (the Eureka offline form divided into two, one is directly removed directly from the service registry listing, the second state is offline, that is the Producer the state set
OUT_OF_SERVICE. If the form is first off the assembly line, Spider platform issue disconnection requests can not be guaranteed Producer process immediately kill, if this period Producer heartbeats synchronized to Eureka Server, the service will be re-registered to Eureka Server ). -
Step Four: Gateway-SynchSpeed results obtained in the previous step, if the result is successful, the next step is executed; otherwise, stop.
-
Step five: Gateway-SynchSpeed as Eureka Client. IP Gateway-SynchSpeed by local registration list to get service in the Producer Application-Name.
-
Step Six: Gateway-SynchSpeed by Application-Name all queries related to the offline services gateway to the core library .
网关组名字 -
Step Seven: Gateway-SynchSpeed through to find all services under the gateway address ipAddress group (: port ip) to the local service list.
网关组名字 -
Step eight: Gateway-SynchSpeed asynchronous notification of all relevant gateway node.
-
Ninth step: Gateway-Core after receiving the notification, the state of Producer done offline, and record all offline status information to the examples of success in the cache DownServiceCache.
-
Step Ten: Gateway-Core Ribbon update the local list of services.
Fourth, the compensation mechanism
Eureka provides a security mechanism. Eureka Client from the list of former Eureka Server Update Services, will check whether the relevant Hash values change (Client service list is modified, hash value will change), if changed, will become a way to update the full amount of the incremental update from the update, (the "Eureka caching " shows that within readOnlyCacheMap 30s and readWriteCacheMap data may be different), it is covered readOnlyCacheMap If the Client side caching list, will eventually lead to inconsistent Ribbon end service list readWriteCacheMap data.
For Eureka This mechanism, introduced listeners EurekaEventListener as a compensation mechanism, which listens to Eureka Client full amount of pull events for the cache service does not exceed the 30s, its status will be re-set . OUT_OF_SERVICE
Five, API security design
Taking into account the security issues of the system, if a malicious person access, may make producers for no reason off the assembly line in Eureka Server, resulting in consumers unable to find producers by Eureka Server.
Use black and white list filter do security, the basic process is as follows:
-
Whitelist segment (IP network) to the Gateway-Synchspeed
-
Gateway-Synchspeed added in a filter, for offline IP checksum for the requestor, if the requester IP subnet, the release; the other hand, and filtered.
Sixth, log back
Because Gateway-SynchSpeed and Gateway-Core is deployed in a Docker container, if the container is restarted, it will cause the log file lost. So it is necessary to Gateway-SynchSpeed and Gateway-Core relevant logs are written to Elasticsearch, is ultimately responsible for the Kibana Elasticsearch query data and visual way to represent.
Seven, code snippet shows
Gateway-SynchSpeed do state synchronization
EurekaEventListener processing cache data
Eight, supplement
Currently perception of real-time gateway service off the assembly line in, Zuul and Eureka version of Spring Cloud Zuul 1.3.6.RELEASE, Spring Cloud Eureka 1.4.4.RELEASE.
Current gateway implementations of real-time gateway perception of downstream services, but also must meet the following conditions:
- Producers need to be deployed in kubernetes container management platform
- Producers do normal offline, upgrade or volume reduction operation. If the vessel is due to lack of resources, resulting in abnormal service outages and other non-normal off the assembly line, it is not supported.
Gateway service off the assembly line is an optional real-time perception of the business gateway solutions provided by default this feature is not turned on in the spider platform, this feature is turned on by the parties according to their own business system requirements determine the specific configuration, see how API gateway access guidelines in "real-time gateway-aware configuration documentation on the spider".
Author: Xie Guohui
Source: CreditEase Institute of Technology