Gracefully unpublish Spring Cloud applications

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:

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:

1. Download application demos Provider and Consumer.
2. 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).
3. View the call status of Provider.
   1. 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

   2. 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.
4. Scale in one instance from Provider and restart the instance. For more information, see Scale out and scale in an application.
5. 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.