Mastering Full-Chain Gray Release with Alibaba Cloud SAE

Microservice Chain Complexity

Typical microservice business architectures are loosely coupled, allowing independent development, deployment, and scaling. In early stages the system is small and call relationships are clear, but as business grows the call graph becomes increasingly complex, threatening overall stability.

Why Gray Release Is Critical Yet Difficult

Gray release is a key part of ensuring stability during production rollouts, but complex service call chains make it hard to guarantee that all corner cases are covered even after extensive testing.

SAE Full‑Chain Gray Solution

Alibaba Cloud Serverless Application Engine (SAE) integrates MSE microservice governance to provide seamless full‑chain gray capabilities. Implementing gray environments requires careful isolation, which can be achieved via physical or logical methods.

Isolation Methods

Physical isolation: Deploy a separate network and compute resources for gray services. Common in test environments but impractical for online gray because maintaining identical conditions across two physical environments is difficult.

Logical isolation: Use traffic coloring and distributed tracing to identify gray traffic and route it dynamically according to gray rules, enabling logical separation within the same physical environment.

Key Concepts

Baseline application: The production app in SAE that receives traffic by default when no gray version exists.

Gray application: A copy of the baseline app created in the same namespace, sharing configuration but with separate compute resources.

Gray tag: Defines a logical gray environment; services sharing the same tag are grouped together.

Lane: A traffic channel that links services with the same gray tag, allowing distinct gray rules.

Lane group: A collection of lanes, used to separate different teams or scenarios, each representing a separate gray environment.

Core Features of SAE Full‑Chain Gray

Multiple gray strategies in parallel: Create different lane groups to apply proportion‑based or content‑based gray rules (e.g., based on HTTP headers, cookies, query strings, or body content).

One‑click creation and start/stop of gray applications: Gray apps can be turned off when not needed and restarted later, reducing resource and operational costs.

Java Agent‑based non‑intrusive traffic sensing and routing: No code changes are required; the feature works with Spring Boot, Spring Cloud, and Dubbo frameworks.

Integration with observability: Real‑time traffic distribution monitoring helps users see gray traffic flow and make fine‑grained adjustments.

Operation Practice

The following steps demonstrate how to set up full‑chain gray release on SAE.

Step 1 – Create baseline applications: In the SAE console, create applications A, B, C and a gateway (using Spring Cloud Gateway).

Step 2 – Enable microservice governance: For each baseline app, go to Application Overview → Microservice Governance and click “Enable”.

Step 3 – Create gray applications: From the application list, create a gray version of each baseline app, assign a custom gray tag (e.g., g1), and replace the image with the version to be released.

Step 4 – Create a lane group: In the SAE console, navigate to Microservice Governance → Full‑Chain Gray, create a lane group, select the gateway as the entry point, and include all apps that belong to the gray environment.

Step 5 – Create lanes and define rules: Add a lane within the group, set the lane tag, and configure gray rules (e.g., path‑based, proportion‑based, or content‑based). For content‑based rules, specify conditions such as a request header gray:gray.

Step 6 – Verify gray traffic: Send a request that matches the rule and observe that it is routed to the gray environment.

# Test command
curl -H "gray:gray" 39.107.xxx.xxx:20000/A/a
# Test result
Ag1[172.16.xx.xxx][config=base] -> 40ms -> B[172.16.xx.xxx] -> 17ms -> Cg1[172.16.xx.xxx] ...

Future Outlook

SAE will continue deep integration with MSE, expanding gray‑release capabilities, traffic observability, and other governance features such as lossless up/down, rate limiting, and degradation, to provide a more complete, low‑cost, and easy‑to‑use serverless experience.