How to Implement Full‑Link Gray Release and Runtime White‑Screening in Cloud‑Native Microservices

Background

In microservice architectures, a feature release may require multiple services to be upgraded simultaneously. Full‑link gray release isolates the entire call chain—from gateway to backend services—allowing several service versions to be tested with a small traffic slice.

Full‑Link Gray Architecture

Only the gray version of a service is deployed. As traffic passes through the gateway, middleware and each microservice, the system identifies gray traffic and routes it dynamically to the corresponding gray instance, reducing resource consumption while providing fine‑grained traffic control.

Runtime White‑Screening

The runtime white‑screening capability observes traffic matching and behavior during full‑link gray testing. A rule is defined as WhiteScreenRule = Target + Action.

Target

ResourceTarget : specifies the interface (Web, RPC, or custom method).

WorkloadTarget : selects the target instance(s), either all machines or specific IPs.

TrafficCondition : filters traffic by exception, slow call, or specific gray tag.

Action

Collect contextual diagnostic information.

Apply traffic coloring downstream.

Enable or disable logging downstream.

These rules let developers verify that traffic routing matches expectations and quickly locate mismatches.

Applying White‑Screening to Gray Traffic

Configure a white‑screen rule on the Zuul gateway entry point to capture request parameters, response values, and headers of gray traffic, confirming that full‑link behavior aligns with the intended configuration.

Configuration Gray

Traditional configuration centers cannot distinguish requests from production or gray instances, leading developers to write conditional code such as:

if (env == "gray") {
    cfg = getConfig("cfg-1");
} else if (env == "gray2") {
    cfg = getConfig("cfg-2");
} else {
    cfg = getConfig("cfg-base");
}

MSE’s configuration tag push moves environment awareness to the platform side via an Agent, eliminating the need for such conditionals.

Step‑by‑Step Demonstration

Step 1 – Reproduce the Scenario

Deploy four Spring Cloud applications (spring‑cloud‑zuul, spring‑cloud‑a, spring‑cloud‑b, spring‑cloud‑c) and a Nacos registry. The source code is available at:

https://github.com/aliyun/alibabacloud-microservice-demo/tree/master/mse-simple-demo

Step 2 – Configure Gray Rule for spring‑cloud‑a

In the MSE governance console, navigate to Application Governance → Traffic Governance → Tag Routing and add a gray rule with the tag gray.

Step 3 – Verify Configuration Gray

Push the gray tag to the instance via Application Configuration → Config List → Push by Tag, selecting the gray tag and setting the desired configuration value.

Access the service endpoint (e.g., /A/a?name=xiaoming) and confirm that the configuration value reflects the gray setting.

Restart the gray instance; the Agent re‑retrieves the pushed value, demonstrating persistence.

Conclusion

Runtime white‑screening and configuration‑gray capabilities extend full‑link gray release, improving observability and reducing code intrusion in microservice governance.