Online applications must be developed in a way to ensure normal service requests even during the period from when applications are stopped for service upgrade and deployment to when services are restarted and recovered. This means that the entire process must be imperceptible to clients. You must configure graceful disconnection to properly shut down applications for deployment, stop, rollback, scale-in, and reset.
Reasons for graceful unpublishing
How do we ensure the normal processing of consumer service requests during the period from when applications are stopped to when services are recovered? The most secure and reliable solution is to update your application when no service requests exist. However, service requests exist even when the application is unpublished.
A traditional solution is to manually perform the following steps: 1 Manually remove traffic. 2 Stop your application. 3 Update your application and then restart the application. In this case, users are not notified about changes to the system. This applies to the update process and related manual operations.
An innovative solution is to use an automated mechanism at the container or framework level. This mechanism can be used to automatically remove traffic and process received requests. This makes the update process imperceptible to your business and improves the O&M efficiency. This mechanism is called graceful unpublishing.
Advantages of graceful disconnection
For open source Dubbo, graceful disconnection can be implemented by using ShutDownHook and quality of service (QoS). However, this method has high development workloads and the version of Dubbo must meet requirements. In addition, some legacy issues affect the normal use of this feature.
EDAS integrates graceful disconnection into the publishing process so that graceful disconnection is automatically implemented when you stop, deploy, roll back, scale in, and reset the applications in Elastic Compute Service (ECS) or Kubernetes clusters. You do not need to perform graceful disconnection operations on applications or in the EDAS console, and traffic is not affected.
Check whether graceful unpublishing takes effect
You can check whether graceful unpublishing takes effect for applications based on your actual business. EDAS also provides two application demos. You can use these demos to check whether graceful unpublishing takes effect in a Kubernetes cluster.
You can perform the following steps to check whether graceful unpublishing takes effect:
- Download application demos Provider and Consumer.
- Deploy Provider and Consumer to a Kubernetes cluster.Provider has two instances deployed, and Consumer has one instance deployed. For more information, see Create and deploy applications (Kubernetes).
- View the call status of Provider.
- Log on to the pod where Consumer is deployed and run the following commands to continuously
access services of Provider.
#! /usr/bin/env bash while true do echo `curl -s -XGET http://localhost:18091/user/rest` done
- View the response of the calls.
The response shows that Consumer randomly accesses two instances of Provider. The IP addresses of the instances are 172.20.0.221 and 172.20.0.223.Notice Do not close the response window.
- Log on to the pod where Consumer is deployed and run the following commands to continuously access services of Provider.
- Scale in one instance from Provider and restart the instance. For more information, see Scale out and scale in an application.
- View the response again to check whether graceful unpublishing takes effect.
View the call status of Consumer to check whether graceful unpublishing takes effect. View the logs of Consumer. The logs show that no exceptions occur, and Consumer is imperceptible to the instance unavailability.
The response shows that Consumer accesses the remaining instance of Provider. The IP address of the instance is 172.20.0.221. When Consumer accesses the remaining instance, no exceptions occur, and Consumer is not affected.