Graceful unpublishing is 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 the graceful unpublishing of Spring Cloud applications. You do not need to configure applications or perform operations in the EDAS console.

Reasons for graceful unpublishing

Graceful unpublishing ensures 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 release 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 advantages that are described in the following table.

Item Open source Spring Cloud EDAS
Version When you call ServiceRegistryEndpoint, you must use Spring Boot Actuator and update 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.
  • If ZooKeeper is used, no traffic loss occurs.
  • If Eureka is used, traffic loss may occur for 3 seconds.
  • If Nacos is used, traffic loss may occur for up to 10 seconds because of the cache on clients.
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 a 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:

  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 Overview.
  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 the 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.
      Normal call results

      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.
    Call response - Graceful unpublishing

    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 the instance unavailability is imperceptible to Consumer.

    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.