All Products
Search
Document Center

Enterprise Distributed Application Service:Gracefully shut down Dubbo applications

Last Updated:May 11, 2023

Developers must update online applications in a manner that is imperceptible to clients. This requires that the service requests of applications are processed as expected when applications are stopped. To achieve this goal, you must configure graceful shutdown when you deploy, stop, roll back, scale in, and reset your 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 clients 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 Dubbo to shut down an application, you must use shutdown hooks and Quality of Service (QoS). This solution requires extra development efforts and sets down a strict requirement on the Dubbo version. As a result, potential risks may be caused and the application cannot work as expected.

EDAS integrates graceful shutdown into the release process to automatically implement graceful shutdown when you stop, deploy, roll back, scale in, and reset applications in an Elastic Compute Service (ECS) or Kubernetes cluster. You do not need to configure graceful shutdown for applications in the EDAS console. The graceful shutdown solution provided by EDAS does not cause traffic loss.

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

  1. Download the Provider and Consumer application demos.

  2. 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.

  3. 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.

      Image - Successful call responses

      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.

  4. Scale in one instance from Provider and restart the instance. For more information, see Application lifecycle management of Kubernetes clusters.

  5. View the responses of the calls again to check whether graceful shutdown is in effect.

    Image - Call responses - Graceful shutdown

    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.