Graceful unpublishing makes it imperceptible to the consumers of your online application when you restart or unpublish the application. Graceful unpublishing ensures business performance and continuity. By default, Enterprise Distributed Application Service (EDAS) supports graceful unpublishing of Spring Cloud applications. You do not need to configure applications or perform operations in the EDAS console.
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 unpublishing provided by EDAS
For open source Spring Cloud, graceful unpublishing can be implemented by using ShutDownHook, Spring Boot Actuator, or Ribbon. However, this requires further development efforts, and some service registries may cause temporary traffic loss.
EDAS integrates graceful unpublishing into the publishing process so that graceful unpublishing is automatically implemented when you stop, deploy, roll back, scale in, and reset applications. Compared with solutions that are provided by open source Spring Cloud, graceful unpublishing provided by EDAS has the following advantages:
|Item||Open source Spring Cloud||EDAS|
|Version||When you call ServiceRegistryEndpoint, you must use Spring Boot Actuator and upgrade it to the version that can be adapted to the version of Spring Cloud.||EDAS supports Spring Cloud Dalston or later. You do not need to perform extra operations.|
|Service registries and traffic loss||Open source Spring Cloud depends on registries for service discovery. Some service
registries may cause traffic loss.
||EDAS does not depend on registries for service discovery. No traffic loss occurs.|
|Scenario||If you want to unpublish an application that is deployed in an Elastic Compute Service (ECS) cluster, you must view the change details of the application in the EDAS console. If you want to unpublish an application that is deployed in an Kubernetes cluster, you can use the preStop interface. However, you can configure only one action for the interface.||You can gracefully unpublish applications that are deployed in ECS clusters and Kubernetes clusters. The operations on and the configurations of the applications are not affected.|
|Cache on clients||You must configure an appropriate time range for Ribbon to refresh cache on clients. If the time range is too long, traffic loss occurs. If the time range is too short, service performance is affected.||When you unpublish applications, EDAS provides an enhanced mechanism for Ribbon to refresh cache. EDAS automatically refreshes the cache based on a reactive response method. You do not need to manually refresh the cache.|
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.