Spring Cloud and Dubbo applications in EDAS can integrate with MSE's microservices governance capabilities without code changes. You can configure features such as service registration and discovery, empty list protection, and graceful start for your applications during creation and deployment. This topic describes how to configure microservices governance.
When you deploy an EDAS application by using an Apsara DevOps pipeline, the microservices governance parameters configured in the EDAS console take precedence. You cannot configure these parameters in the Apsara DevOps pipeline.
Background information
Service registration and discovery
Common service registries in Java microservices architectures, such as Eureka, ZooKeeper, and Nacos, implement service registration and discovery. They decouple services from each other to facilitate dynamic management of microservices.
Empty list protection
The empty list protection feature handles scenarios where a service registry returns an empty list to a consumer, typically due to a provider registration failure. When this happens, the consumer ignores the empty list and uses the last known valid address list from its cache to maintain service access. This enhances consumer reliability during service registry changes, such as scaling or version updates, or unexpected events like an availability zone outage.
A consumer subscribes to the instance list of a provider from the service registry. When the service registry undergoes changes such as scaling or version updates, or encounters unexpected events like an availability zone outage, subscriptions can fail and impact consumer availability. To handle subscription failures in unpredictable situations, you can configure empty list protection on the consumer side.
Graceful start
Operations like deployments, scaling, and restarts are unavoidable for any online application. EDAS integrates MSE's graceful start solution to protect applications during startup. This includes features such as service prefetching, delayed service registration, and graceful rolling deployment.
Service prefetching: By setting a prefetching duration and a prefetching curve, you can reduce the risk of a newly launched service failing due to a sudden traffic surge.
Delayed service registration: This feature introduces a delay during application startup. The service is registered with the service registry only after the specified delay has passed. This provides time for the application to prepare asynchronous requests and compute resources, preventing request failures caused by incomplete initialization during deployment.
For applications with complex initialization, registration can occur before the application is ready to receive traffic, causing errors. By setting a delayed service registration, you ensure the application is fully initialized before it is registered and begins to serve traffic.
Graceful rolling deployment: The
/healthendpoint allows clients outside the microservices system to perform a readiness check on the application. This synchronizes the status check between services within and outside the microservices framework. It supports checks for both service registration and service prefetching status.A rolling deployment in a Kubernetes cluster divides the deployment process into multiple batches. A new batch is deployed only after the previous one succeeds. EDAS connects the microservice lifecycle with the Kubernetes service lifecycle. By providing graceful start capabilities, such as ensuring service registration and service prefetching are complete before the readiness check passes, EDAS helps maintain available application replicas throughout the process, achieving a graceful rolling deployment.
Complete service registration before readiness check: After this feature is enabled, an agent non-intrusively provides a port for the application to check whether it has completed registration. If registration is complete, the port returns a status code of 200, which helps Kubernetes determine that the application is ready. Otherwise, it returns 500, indicating the application is not ready.
Complete service prefetching before readiness check: You can use service prefetching independently or associate it with the Kubernetes readiness check mechanism. When associated, Kubernetes considers the application ready only after service prefetching is complete.
Graceful shutdown
The graceful shutdown capability is enabled by default for Kubernetes applications deployed on EDAS. Before an instance is stopped, it is deregistered from the service registry and waits for a specified period before shutting down. For Java applications, you can also enable an active notification switch. This allows the instance being shut down to actively notify consumers to stop sending new requests, which helps prevent requests from being interrupted during the shutdown.
Limitations
The empty list protection and graceful start features are available only for Spring Cloud and Dubbo applications and require no code changes. The following table describes the supported versions.
Item
Empty list protection
Graceful start
Spring Cloud
Spring Cloud Edgware and later
Spring Cloud Edgware and later
Dubbo
Dubbo 2.5.3 to 2.7.8
NoteTo use Dubbo 3.0 or later, join the DingTalk group (ID: 31723701) to contact product and technical experts for assistance.
Dubbo 2.7.3 to 2.7.8
NoteTo use Dubbo 2.6, or Dubbo 3.0 or later, join the DingTalk group (ID: 31723701) to contact product and technical experts for assistance.
Nacos, Eureka, and Zookeeper service registries are supported.
Gateway applications are typically called via directly exposed APIs instead of a service registry, so MSE's service prefetching feature does not apply to them. Additionally, gateway applications change infrequently and have minimal business logic, so they do not typically require service prefetching.
For a canary release, service prefetching is not supported for the first canary batch. It can be enabled for subsequent batches.
Configure microservices governance on creation
-
Log on to the EDAS console. In the left-side navigation pane, choose . The Applications page appears. In the top navigation bar, select a region. In the upper part of the page, select a namespace. In the upper-left corner, click Create Application.
On the Basic Information tab, select a cluster type and application runtime, then click Next.
Parameter
Description
Cluster Type
Select Kubernetes cluster.
Application Runtime Environment
Select an application runtime based on the type of application you are hosting.
Java:
Custom: Use a custom image to deploy the application in a Kubernetes cluster.
Java: Supports deployment from standard JAR packages. This option is suitable for Dubbo and Spring Boot applications. After you select this option, you can change the Java environment.
Tomcat: Supports deployment from standard WAR packages. This option is suitable for Dubbo and Spring applications. After you select this option, you can change the Java environment and container version.
EDAS-Container (HSF): Use a WAR or FatJar package to deploy an HSF application. After you select this option, you can change the Java environment, Pandora version, and Ali-Tomcat version.
PHP: For PHP applications that run on an Apache HTTP Server.
Node.js, C++, Go...: Use a custom image to deploy the application in a Kubernetes cluster.
NoteWhen you deploy an application by selecting EDAS-Container (HSF), Microservices governance only supports configuring service registration and discovery.
If you select PHP or Node.js, C++, Go... to deploy the application, you cannot configure Microservices governance.
-
In the Configurations step, configure the environment information, basic information, and deployment method for the application, set the related resource parameters, and then click Next.
On the Advanced Settings tab, expand Microservices governance, and configure service registration and discovery, empty list protection, and graceful start based on your business requirements.
Parameter
Description
Service registration and discovery
Specifies the operations and maintenance (O&M) method for your service registry. You can use the shared service registry provided by EDAS or a service registry configured in your application. For more information, see Choose a service registry O&M method.
Empty list protection
Specifies whether to enable empty list protection.
Enable empty list protection: If a consumer subscribes to an empty list, the protection mechanism takes effect, discards the change, and ensures service availability.
Disable empty list protection: If a consumer subscribes to an empty list, the business is interrupted and an error is reported.
Graceful start
Specifies whether to enable graceful start. If you enable this feature, you must configure the following parameters:
Prefetching duration (seconds): The prefetching time for the next startup of the application instance. The default duration is 120 seconds. You can set the value to an integer from 0 to 86,400 (24 hours).
Prefetching curve: Based on the configured prefetching duration, the traffic weight for the prefetched application grows exponentially according to the specified prefetching curve. A larger prefetching curve value means that the application receives less traffic at the beginning of the prefetching period. This is ideal for complex applications that need more time to warm up.
The default value is 2, which is suitable for most prefetching scenarios and indicates that the provider's traffic receiving curve follows a quadratic shape during the prefetching period. You can set the value to an integer from 0 to 20. For the same prefetching duration, a larger value indicates less traffic at the start of prefetching and a steeper increase in traffic towards the end of the period.
Delayed registration time (seconds): You can set the value to an integer from 0 to 86,400 (24 hours).
Graceful rolling deployment: Configure graceful rolling deployment for the application.
Complete service registration before readiness check: Non-intrusively provides port 55199 for the application to check whether the microservice has completed registration. If it is registered, the port returns a status code of 200. Otherwise, it returns 500.
Complete service prefetching before readiness check: Non-intrusively provides port 55199 for the application to check whether the microservice has completed prefetching. If it is prefetched, the port returns a status code of 200. Otherwise, it returns 500.
NoteIf you enable both service registration and service prefetching to complete before the readiness check, port
55199will check if service prefetching is complete.
Graceful Shutdown
This switch configures the Proactive Notification feature for graceful shutdown. When enabled, the application actively notifies consumers that it is about to shut down after it receives a shutdown request.
NoteThe graceful shutdown capability is enabled by default for EDAS applications.
The Proactive Notification switch must be enabled for both the provider and the consumer.
Make sure that the ack-onepilot version in the cluster is 3.X or later. If the version is earlier, you must upgrade it. For more information, see Observability FAQ.
The graceful shutdown capability in EDAS relies on the application's preStop probe. If your application requires a custom preStop probe, add the following script to the probe:
wget http://127.0.0.1:54199/offline; sleep 30;
On the Application Advanced Settings tab, expand Application Lifecycle Management, select the Readiness configuration option, and click the On switch to enable the Readiness probe.
If your application does not have a readiness probe configured, enabling graceful rolling deployment adds a graceful rolling deployment mode to the readiness probe settings. Selecting this mode automatically configures a readiness check for your application with the path /health and port 55199. You can use this graceful rolling deployment mode to integrate the lifecycles of your microservices with Kubernetes (K8s), or you can combine other modes with the /health endpoint to configure more rigorous business-specific readiness checks.
-
Click Create Application.
-
On the Creation Completed page, check the information in the Basic Information, Configurations, and Advanced Settings sections. Then, click Create Application.
In the upper part of the Application Overview page, click View Details. On the Change List page, view the application change process. Wait several minutes until the application is deployed. After the application change process is complete, view the status of the instance in the Basic Information section of the Application Overview page. If the status shows that a pod is running, the application is deployed.
Configure microservices governance on update
If you did not configure service registration and discovery, empty list protection, or graceful start when you created an application, you can configure them during deployment.
-
Log on to the EDAS consoleEDAS console.
-
In the left-side navigation pane, click . In the top navigation bar, select a region. In the upper part of the page, select a namespace. Select Container Service or Serverless Kubernetes Cluster from the Cluster Type drop-down list. Then, find the application that you want to deploy and click the application name.
-
On the Overview or Basic information page, choose in the upper-right corner.
-
On the Select Deployment Mode page, select a deployment mode and click Start Deployment in the upper-right corner of the specified deployment mode section.
After you set the environment and deployment package information for the application, expand Configuration management. After you finish the configuration, click OK.
Expand Microservices governance, and configure service registration and discovery, empty list protection, and graceful start based on your business requirements.
Parameter
Description
Service registration and discovery
Specifies the operations and maintenance (O&M) method for your service registry. You can use the shared service registry provided by EDAS or a service registry configured in your application. For more information, see Choose a service registry O&M method.
Empty list protection
Specifies whether to enable empty list protection.
Enable empty list protection: If a consumer subscribes to an empty list, the protection mechanism takes effect, discards the change, and ensures service availability.
Disable empty list protection: If a consumer subscribes to an empty list, the business is interrupted and an error is reported.
Graceful start
Specifies whether to enable graceful start. If you enable this feature, you must configure the following parameters:
Prefetching duration (seconds): The prefetching time for the next startup of the application instance. The default duration is 120 seconds. You can set the value to an integer from 0 to 86,400 (24 hours).
Prefetching curve: Based on the configured prefetching duration, the traffic weight for the prefetched application grows exponentially according to the specified prefetching curve. A larger prefetching curve value means that the application receives less traffic at the beginning of the prefetching period. This is ideal for complex applications that need more time to warm up.
The default value is 2, which is suitable for most prefetching scenarios and indicates that the provider's traffic receiving curve follows a quadratic shape during the prefetching period. You can set the value to an integer from 0 to 20. For the same prefetching duration, a larger value indicates less traffic at the start of prefetching and a steeper increase in traffic towards the end of the period.
Delayed registration time (seconds): You can set the value to an integer from 0 to 86,400 (24 hours).
Graceful rolling deployment: Configure graceful rolling deployment for the application.
Complete service registration before readiness check: Non-intrusively provides port 55199 for the application to check whether the microservice has completed registration. If it is registered, the port returns a status code of 200. Otherwise, it returns 500.
Complete service prefetching before readiness check: Non-intrusively provides port 55199 for the application to check whether the microservice has completed prefetching. If it is prefetched, the port returns a status code of 200. Otherwise, it returns 500.
NoteIf you enable both service registration and service prefetching to complete before the readiness check, port
55199will check if service prefetching is complete.
Graceful Shutdown
This switch configures the Proactive Notification feature for graceful shutdown. When enabled, the application actively notifies consumers that it is about to shut down after it receives a shutdown request.
NoteThe graceful shutdown capability is enabled by default for EDAS applications.
The Proactive Notification switch must be enabled for both the provider and the consumer.
Make sure that the ack-onepilot version in the cluster is 3.X or later. If the version is earlier, you must upgrade it. For more information, see Observability FAQ.
The graceful shutdown capability in EDAS relies on the application's preStop probe. If your application requires a custom preStop probe, add the following script to the probe:
wget http://127.0.0.1:54199/offline; sleep 30;
Expand Throttling and degradation configuration and turn on the switch to enable AHAS access.
ImportantAfter you click OK, the application is restarted. We recommend that you perform this operation during off-peak hours.
Verify the results
On the change list page of the application, view the application change details. If the change is executed successfully, the deployment is successful and the configuration has taken effect.
After you enable graceful start, you can verify the prefetching effect after the application is deployed.
Log on to the AHAS console.
In the upper-left corner of the AHAS console, select the region where the application is deployed.
In the left-side navigation pane, choose .
On the Application Protection page, click the card of the target application on the Application Card tab.
In the left-side navigation pane, click Machine Monitoring.
On the Machine Monitoring page, view the prefetching effect of the application.
Service prefetching
If you deploy an application in batches, enable service prefetching for the application during deployment, and connect the application to AHAS, the prefetching effect is similar to the following example:
Under stable business traffic, you can see that the traffic ratio of the newly deployed application increases slowly along the prefetching curve.
The graceful start feature controls the traffic percentage for newly deployed applications by configuring the prefetching duration and prefetching curve. You can configure these settings based on your business requirements and application complexity to adjust the traffic weight assigned at startup. The function curve for the prefetching effect is as follows:
The following examples show the effects of different prefetching curves during application deployment:
Prefetching duration: 120 seconds, prefetching curve: 2.
Prefetching duration: 120 seconds, prefetching curve: 5.
Graceful rolling deployment
Enabling graceful rolling deployment connects the microservice lifecycle with the Kubernetes lifecycle. If you configure service prefetching and enable graceful rolling deployment for a batched release, you can observe the following effects:
The traffic received by the newly deployed application increases slowly along the prefetching curve.
The traffic to the old application slowly decreases.
During the application release process, you may see Unhealthy alert events. This is because the application's readiness probe has not yet passed. At this time, both new and old instances coexist, and traffic is gradually shifted from the old instances to the new one. After prefetching is complete, the readiness probe returns a status code of 200, and the old instance is deleted. This achieves service prefetching and connects the process with the Kubernetes lifecycle.
Delayed service registration
After you configure delayed service registration, the application waits for a specified delay after startup before it registers with the service registry. This provides sufficient startup time for the application and helps prevent traffic loss that is caused by incomplete application loading.
For example, if you configure an application for single-batch deployment with a 300-second delayed service registration, a 120-second service prefetching, and enable graceful rolling deployment, the effect is as follows:
View the application change record on the change list page of the application.
You can see that the application was changed at 11:17:59. Pods created before 11:24:44 did not receive any traffic, and service prefetching started after 11:24:44. You can find Unhealthy alert events by observing the application change events. Considering that the application startup process includes events such as Pod scheduling, image pulling, and program startup, the time from the application release to the end of the change process is roughly consistent with the time required for delayed service registration and service prefetching.
