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

This article mainly introduces "how to realize the smooth online and offline of SpringCloud service". In the daily operation, I believe that many people have doubts about how to realize the smooth online and offline of SpringCloud service. The editor has consulted all kinds of materials and sorted out simple and easy-to-use operation methods. I hope it will be helpful to answer the doubt of "how to realize the smooth online and offline of SpringCloud service". Next, please follow the editor to study!

On the whole, SpringCloud is fully functional and very comfortable to use after a period of stepping on the pit.

Our microservices generally integrate the following.

Well, a huge ecology

problem

So the problem is that the registration of SpringCloud to the registry is called through the Rest interface. It cannot be like ZooKeeper, where feedback from problem nodes takes effect in a timely manner. Can not go to the rotation training as quickly as Redis, too delicate for fear that the wheel is broken. As shown below:

There are three requirements:

1) after an instance of ServiceA is logged off, the call to Zuul gateway cannot fail.

2) after an instance of ServiceB is offline, the Feign call of ServiceA cannot fail.

3) when the service is online and offline, the Eureka service can quickly perceive

To put it bluntly, one thing is how to minimize the discovery time of Zuul and other dependent services after the service is offline, and ensure that the request does not fail during this period.

Solve the problem of time

Influence factor

1) the two-tier cache problem of Eureka (what the heck is this?

EurekaServer has two caches by default, one is ReadWriteMap and the other is ReadOnlyMap. The ReadWriteMap is modified when a service provider registers the service or maintains a heartbeat. When a service caller queries the list of service instances, it is read from ReadOnlyMap by default (this can be configured in native Eureka, but not in SpringCloud Eureka, and ReadOnlyMap reading must be enabled). This can reduce contention for ReadWriteMap read-write locks and increase throughput. EurekaServer updates data from ReadWriteMap to ReadOnlyMap regularly.

2) heartbeat time

After the service provider registers the service, it will have a regular heartbeat. This is based on the service refresh time in the service provider's Eureka configuration. Another configuration is the service expiration time, which is configured by the service provider but used in EurekaServer, but the default configuration EurekaServer does not enable this field. The scan failure time of EurekaServer needs to be configured before the active failure mechanism of EurekaServer is enabled. When this mechanism is enabled: each service provider will send its own service expiration time, and EurekaServer will regularly check each service expiration time and the last heartbeat time. If no heartbeat has been received within the expiration time and is not in protected mode, the instance will be removed from the ReadWriteMap.

3) the rotation interval of the caller service pull list from Eureka

4) Ribbon caching

Solution method

1) disable ReadOnlyMap caching for Eureka (Eureka side)

Eureka.server.use-read-only-response-cache: false

2) enable active failure, and each active failure detection interval is 3s (Eureka side)

Eureka.server.eviction-interval-timer-in-ms: 3000

Things like eureka.server.responseCacheUpdateInvervalMs and eureka.server.responseCacheAutoExpirationInSeconds are really useless after enabling active failure. The default 180s is really driving people crazy.

3) Service expiration time (service provider)

Eureka.instance.lease-expiration-duration-in-seconds: 15

If you do not receive a heartbeat beyond this time, the EurekaServer will remove the instance. EurekaServer must set eureka.server.eviction-interval-timer-in-ms or this configuration is invalid, which is generally three times the configuration of the service refresh time. The default is 90s!

4) Service refresh time configuration, with an active heartbeat every other time (service provider)

Eureka.instance.lease-renewal-interval-in-seconds: 5

The default is 30s

5) pull service list interval (client)

Eureka.client.registryFetchIntervalSeconds: 5

The default is 30s

6) ribbon refresh time (client)

Ribbon.ServerListRefreshInterval: 5000

Ribbon also has a cache, which defaults to 30s.

These timeouts affect each other, and even three places need to be configured. If you are not careful, there will be an embarrassing situation in which the service is not offline or online. I have to say that this set of default parameters for SpringCloud is hilarious.

Retry

So what is the longest unavailable time for a server to go offline? (that is, the request will fall on the offline server and the request fails). If you are in a hurry, the basic time is eureka.client.registryFetchIntervalSeconds+ribbon.ServerListRefreshInterval, which is about 8 seconds. If the active failure time of the server is taken into account, the time will be increased to 11 seconds.

If you only have two instances, and in extreme cases, it takes 11 seconds to find a service online, that's 22 seconds.

Ideally, within these 11 seconds, the request fails. If your QPS is 1000 and four nodes are deployed, the number of failed requests in 11 seconds will be 1000 / 4 * 11 = 2750, which is unacceptable. So we need to introduce a retry mechanism.

It is relatively easy for SpringCloud to introduce a retry. However, it is not just a configuration, since you have used a retry, then you still need to control the timeout. You can follow these steps:

1) introduce pom (don't forget)

Org.springframework.retry spring-retry

2) add configuration

Ribbon.OkToRetryOnAllOperations:true # (retry all operations, only get requests retry if false) ribbon.MaxAutoRetriesNextServer:3 # (maximum number of retries for other instances of load balancer, excluding first instance) ribbon.MaxAutoRetries:1# (maximum number of retries for the same instance, excluding first call) ribbon.ReadTimeout:30000ribbon.ConnectTimeout:3000ribbon.retryableStatusCodes:404500503# (retry in those states) spring.cloud.loadbalancer.retry.enable:true# (retry switch)

Release system

OK, the mechanism has been explained clearly, but it is still very complicated and irritating in practice. For example, there are two instances of a service. I want to release it one by one. I have to wait at least 11 seconds before releasing the second one. If the hand speed is too fast, it is a disaster. Therefore, a matching release system is necessary.

First of all, you can request the Eureka through the rest request and take the initiative to isolate an instance. With this step, the service unavailability time can be reduced by at least 3 seconds (or more cost-effective).

Then pack and push the package through the packaging tool. Go online and replace it in turn.

There is no such continuous integration tool on the market, so the release system needs to be customized, which is also part of the workload.

At this point, the study on "how to achieve smooth online and offline SpringCloud services" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

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.