How to Implement Full‑Link Gray Release with OpenSergo and MSE

In a microservice architecture, services often depend on each other, making simultaneous version upgrades challenging; full‑link gray release enables small‑traffic validation of new versions across the entire call chain by isolating environments from the gateway to backend services.

OpenSergo offers an open, language‑agnostic governance standard that defines services, traffic routing, and workload labeling via unified YAML/DSL/CRD configurations, allowing developers to apply consistent rules across Java, Go, Node.js, and other runtimes without handling framework‑specific differences.

Traffic Routing Rules

OpenSergo’s v1alpha1 traffic routing CRDs consist of three parts:

WorkloadLabelRule – assigns labels to a group of workloads (e.g., database instances).

TrafficLabelRule – tags incoming traffic based on attributes such as headers.

Matching – routes traffic with specific labels to matching workloads.

Labeling Traffic Example

apiVersion: traffic.opensergo.io/v1alpha1
kind: TrafficLabelRule
metadata:
  name: my-traffic-label-rule
  labels:
    app: spring-cloud-zuul
spec:
  selector:
    app: spring-cloud-zuul
  trafficLabel: gray
  match:
  - condition: "=="
    type: header
    key: 'location'
    value: cn-shenzhen

This configuration tags HTTP requests whose location header equals cn-shenzhen with the gray label.

Labeling Workloads Example

apiVersion: traffic.opensergo.io/v1alpha1
kind: WorkloadLabelRule
metadata:
  name: gray-sts-label-rule
spec:
  workloadLabels: ['gray']
  selector:
    db: mse-demo
    table: mse_demo_table_gray

For Java applications using Spring Cloud, adding the environment variable traffic.opensergo.io/label: gray to the container registers the gray label with Nacos.

Database‑Level Full‑Link Gray Release

Two common patterns are used:

Shadow Database

Maintain a separate database instance (e.g., mse-demo-gray) for gray traffic, routing requests to it based on the traffic label, thus isolating data from the baseline database.

Shadow Table

Create a shadow table (e.g., mse_demo_table_gray) in the same database; SQL statements from gray traffic are rewritten to target the shadow table, preventing data contamination.

Prerequisites

Application integrated with MSE.

Deploy demo applications A, B, C (each with base and gray versions) and a Nacos server for service discovery.

Demo SQL statements: INSERT INTO mse_demo_table(location) VALUES(?) Database schema:

CREATE TABLE `mse_demo_table` (
  `id` int NOT NULL AUTO_INCREMENT,
  `location` varchar(255) DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=utf8mb3

Shadow table schema (must be created beforehand):

CREATE TABLE `mse_demo_table_gray` (
  `id` int NOT NULL AUTO_INCREMENT,
  `location` varchar(255) DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=utf8mb3;

Step 1 – Configure Full‑Link Gray Rules

Follow the official tutorial to create lane rules in MSE (see the lane‑rule diagram).

Step 2 – Enable Database Gray Capability

Set the required environment variables on the MSE side to activate shadow‑table routing (illustrated in the following image).

Step 3 – Verify Results

Send a request with the gray header:

curl -H "location: cn-shenzhen" http://106.14.xx.xx/a

The response shows the request traversing the gray instances of A, B, and C. Query the shadow table: SELECT * FROM `mse_demo_table_gray`; All inserted rows appear in the shadow table, confirming successful data isolation.

Beyond Full‑Link Gray

MSE’s governance now supports gateways, ALB, APISIX, Dubbo, Spring Cloud, RocketMQ, and databases. Future work will extend gray capabilities to caching layers and further productize the solution.