Micro Services High Availability Program
First, the availability of micro-services
In the registry, before configuring high-availability solutions center to learn about the working principle of registry, explained below divided into two parts, one is acquiring synchronization with the registry of registries and the various micro-services, and second, how to registry maintenance of the registry.
1.1, the registry access and synchronization
The relationship between Eureka Server and Eureka Client, is maintained by the registry, and the registry, the registry of each Client caching locally through Eureka Server centralized management, pull the latest registry information through periodic task . Simple example is shown below.
According to the flow chart shows, the process can understand the essential link between the registry and the micro-services:
1. A start time of service, register their relevant information to the Eureka Server
2. When the service B pulls the latest registry to Eureka Server, you can get a machine registration information service A
3. A service registration information of the other two machines go to registration, when the service B 30s to pull again, you'll get service A three machines
4. Service A, sending a heartbeat message every 30s to Eureka Server, indicate their registration information is still valid
These are generally the interaction process between the registry and the micro-services, in particular the practice, Eureka Server provides multi-level cache, acquisition and synchronization information which the registry, and there will be subtle differences.
1. Eureka Server registry directly based on pure memory, which maintains a data structure in memory.
2. Registration, service off the assembly line, service failures each service, all will maintain and update the registry in memory.
3. Each service every 30 seconds pulling the registry when, Eureka Server is stored directly in memory of a change of registry data to them on it.
4. Similarly, every 30 seconds to initiate a heartbeat, the heartbeat is updated at this time pure memory Map data structure.
Registry Eureka Server is a pure memory handling, and processing speed quickly, while providing readWriteCacheMap and readOnlyCacheMap do caching frequently read and write will not protect the conflict. Diagram below.
The figure Eureka Server introduces the principle of multi-level cache:
1. When the first service A registered, its registration information will be updated to the memory of the registry, if you have the appropriate information readWriteCacheMap, then out of date, if not then do not do the operation
2. When the service B to pull registry information, go first to readOnlyCacheMap, did not find readWriteCacheMap, look no registration information go to memory registry is updated to readWriteCacheMap found, the return to service B, B of registry services , the machine will have a registered service a information
3. It is the synchronization between the timing readWriteCacheMap readOnlyCacheMap and a background task, once every 30s desynchronization, cache synchronization task
4. A second registration desk services, update the memory of the registry, while the readWriteCacheMap out of date
5. When tasks are performed before the cache synchronization service B to pull registry is to get data from readOnlyCacheMap, a new registry, not to get the service B
After 6.30s, synchronous readWriteCacheMap data cache synchronization tasks and readOnlyCacheMap in, the readOnlyCacheMap out of date in the registry, then service B will find readWriteCacheMap take data, readWriteCacheMap get the data from the memory cache, returned to the service B, B's registry service, there will be two services a registered machine information
7. In the next 30s, before the cache synchronization task to synchronize the readWriteCacheMap readOnlyCacheMap, readOnlyCacheMap not registered a second cache service A, and therefore are taken from the latest data readWriteCacheMap
Note:
readOnlyCacheMap cache update interval timer, default is 30 seconds
readWriteCacheMap cache expiration time, the default is 180 seconds
From the above process descriptions, Eureka Server to take a multi-level caching strategy, while the latest registry entry into force of DELAY 30s. What are the advantages of multi-level caching mechanism is:
1. As far as possible to ensure that the registry data memory read and write without frequent conflicts.
2. And further to ensure that a large number of requests Eureka Server, are quick to go from pure memory, high performance.
1.2, micro registry maintenance service registry
Eureka Client registry related behavior is as follows:
1. Service registration (Registry) - executes initialization time, register their information service instance node includes ip, port, instance name, etc. to the server, based on a POST request.
2. Service contract (renew) - default to the server every 30s PUT time, ensure the current service node status information updated in real time, not to be excluded server failure.
3. Update has been registered service list (fetchRegistry) - default once every 30s increment version information from the server GET, and then compares and merges local, to ensure that local can get the latest registration information to other nodes.
4. Service offline (cancel) - when the service shutdown, the need for timely notification service to their end removed to prevent the client calls the service goes offline.
Eureka Client is based on Http protocol Eureka Server to interact with the service by registering Jersey Client, service contract, cancel service, service inquiries. At the same time, Server-side service also maintains a list of examples, for instance is not renewed and 90s were removed every failure.
Eureka Server has a self-protection mechanism, when the network fails, the client and the server fails, it is necessary to start self-protection mechanism of Eureka Server, this will not eliminate the service when the network is restored, exit self-protection. Self-protection has two parameters, the number of heartbeats received last minute (Renews (last min)), the desired number of heartbeats received (Renews threshold), when Renews threshold> Renews (last min), into the self-protection mode.
Renews (last min) = number of instances of the number of instances * 2 # Count Eureka Server self-registration service
Renews threshold = Renews (last min) * 0.85 # 0.85 Configurable
There are 10 instances of registration in the figure:
Recommending more Eureka Server deployment, open self-protection
eureka.client.register-with-eureka = true1.3, a distributed registry
Understand the working principle of the registry, you can start research services distributed, multi-registry, multi-service instance.
When the micro-service registration only to a registration center, when the registry fails, the new service could not continue with the registration up, the registration information of the old service, caches in other registries and client, still can be used, after restart , can not be registered to the registry, but also can not be used.
Therefore, when building a highly available registries, cross-registration required, each registration center as both the server, and when clients register themselves to other registration centers, while micro-services are required to register each registration center, by the registry yourself filtered mutual support, to prevent a single failure caused only registry to register thereon the micro restart service is unavailable. As shown in the diagram.
Currently registry and configuration center together, not split removable, little effect on the overall split in order to configure the registry and does not affect the center of each other. gitlab deployed on one of the machines, all common config reasons gitlab, resulting in the presence of single point of failure risks config distributed. Each config respectively independent gitlab, gave the operation and maintenance caused great inconvenience. Late adopter of apollo, with database storage configuration, the advantages of using a distributed database of alternative gitlab, to solve the problem single point of failure.
1.4, registry pressure measurement
The pressure measurement survey, 8-core 4G of Eureka Server when processing 1000 service instances, there is no pressure, by default, can process 7,000 instances, exceed the time-out error, after modifying tomcat configuration, up to carry examples 8000 and the CPU substantially full.
Upgrade considerations:
1, registered between Eureka Server each other, Eureka Client needs are registered on each side of the Server
2, Eureka Server open self-protection
3, the number of instances Eureka Client is not more than 1000
reference:
[1] https://www.jianshu.com/p/ae4f0c8b8135
[2] https://www.cnblogs.com/xishuai/p/spring-cloud-eureka-safe.html