How to check whether graceful shutdown is in effect? - Enterprise Distributed Application Service

Graceful shutdown is imperceptible to the consumers of your online application, who can continuously use your application without hiccups during application restart or shutdown. By default, Enterprise Distributed Application Service (EDAS) supports graceful shutdown for Spring Cloud applications. You do not need to configure graceful shutdown for Spring Cloud applications.

Background information

Graceful shutdown ensures that the service requests of consumers are processed as expected when applications are stopped. Ideally, applications can be updated in a secure and reliable manner when no service requests exist. However, this is extremely rare in actual practices.

A traditional solution is to manually perform the following steps: Remove traffic, stop your application, update your application, and then restart the application. If you use this solution to update your application, the business continuity of your client is not affected.

An innovative solution is to use an automated mechanism at the container or framework level. This solution can be used to automatically remove traffic and process all received requests to make the update process imperceptible to your business and the O&M work during the update efficient. Graceful shutdown is such an innovative solution.

Benefits of graceful shutdown of EDAS

If you use the graceful shutdown solution provided by open source Spring Cloud, you must use shutdown hooks, Spring Boot Actuator, and Ribbon. This solution requires extra development efforts and may cause traffic loss to registries for a short period of time.

EDAS integrates graceful shutdown into the release process to automatically implement graceful shutdown when you stop, deploy, roll back, scale in, and reset applications. Compared with graceful shutdown of open source Spring Cloud, the graceful shutdown of EDAS provides the following advantages.

Category	Open source Spring Cloud	EDAS
Version	When you call ServiceRegistryEndpoint, you must use Spring Boot Actuator and update it to the version that is compatible with the Spring Cloud version in use.	EDAS supports Spring Cloud Dalston or later. You do not need to perform extra operations.
Service registry and traffic loss	Open source Spring Cloud depends on registries that may cause traffic loss: If you use ZooKeeper registries, no traffic loss occurs. If you use Eureka registries, traffic loss lasts for three seconds. If you use Nacos registries, traffic loss lasts for up to 10 seconds due to the cache on clients.	EDAS does not depend on registries. No traffic loss occurs.
Scenario	If you want to gracefully shut down an application that is deployed in an Elastic Compute Service (ECS) cluster, you must view the change details of the application. If you want to gracefully shut down an application that is deployed in a Kubernetes cluster, you must call prestop. However, you can configure only one action for prestop.	You can gracefully shut down applications that are deployed in ECS clusters and Kubernetes clusters in the EDAS console. The operations on and the configurations of the applications are not affected.
Client cache	You must configure an appropriate time range for Ribbon to refresh the cache on clients. If the time range is too long, traffic loss occurs when you gracefully shut down an application. If the time range is too short, service performance is compromised.	When you gracefully shut down applications, EDAS provides an enhanced mechanism for Ribbon to refresh the cache on clients. EDAS automatically refreshes the cache based on a reactive response method. This eliminates the need to refresh cache.

Check whether graceful shutdown is in effect

You can check whether graceful shutdown is in effect for your applications based on your business requirements. EDAS provides the following application demos: Provider and Consumer. You can use the application demos in a Container Service for Kubernetes (ACK) cluster to check whether graceful shutdown is in effect.

Procedure

Download the Provider and Consumer application demos.
Deploy Provider and Consumer in an ACK cluster.
Provider has two instances deployed, and Consumer has one instance deployed. For more information about how to deploy the application demos, see Overview.
View the status of calls that are initiated from Consumer to Provider.
1. Log on to the pod in which Consumer is deployed and run the following commands to continuously access the services of Provider:
```
#!/usr/bin/env bash
while true
do
    echo `curl -s -XGET http://localhost:18091/user/rest`
done
```
2. View the responses of the calls.
  The preceding responses show that Consumer randomly accesses two instances of Provider. The IP addresses of the instances are 172.20.0.221 and 172.20.0.223.
  Important
  Do not close the response window.
Scale in one instance from Provider and restart the instance. For more information, see Application lifecycle management of Kubernetes clusters.
View the responses of the calls again to check whether graceful shutdown is in effect.
View the call status of Consumer to check whether graceful shutdown is in effect. View the logs of Consumer. If the logs show that no exceptions occur, the instance unavailability is imperceptible to Consumer.
The preceding responses show that Consumer accesses only the remaining instance of Provider. The IP address of the instance is 172.20.0.221. In the access process, no call exceptions occur, and Consumer is not affected.