Routing Strategies and Gray Release Practices in Distributed Microservice Systems

In distributed systems, multiple versions of the same service may run in parallel during development, requiring routing of requests to a specific version to keep isolation and support gray deployment.

Typical scenario: services A, B, C where B and C have multiple versions; routing rules direct traffic accordingly.

Load Strategy

When services have multiple versioned clusters, standard round‑robin, weight, or random strategies are insufficient; custom routing rules are needed.

Common ways: carry routing information via Header, Cookie, Parameter, etc., and match them to select the target version.

Default master branch routing

Requests default to the master branch; if custom rules do not match, the master service acts as fallback.

Version‑specific routing

When a request carries a version identifier such as 2.0.0, the router first tries to match services of that version; otherwise the master handles the request.

Service‑specific routing

Individual services can be forced to a particular version, e.g., service B with 1.0.0 and service C with 3.0.0, while others use the master branch.

After matching, if the selected version runs in a cluster, a load‑balancing policy chooses one instance to handle the request.

Gray Deployment

With custom routing and load‑balancing, new versions can be released without affecting existing services; traffic is split according to rules, and after verification the new version replaces the old one.

Typical gray‑deployment steps:

Configure routing; requests default to the main branch.

Deploy the new version; gray layer does not receive traffic by default.

During acceptance, route selected requests to the gray layer.

Common rules: version tag, gray user group, percentage split, IP, etc.

After successful acceptance, promote gray services to the main branch.

Retire the old main services to complete the rollout.

If verification fails, rollback or adjust the gray layer.

Routing rules and weight adjustments are managed in a configuration center and can be changed dynamically during testing.

Practical Scheme

1. Process Design

Clients carry routing identifiers; when a rule cannot be matched, the request falls back to the main branch. Core switches are maintained centrally in the configuration center.

2. Routing Identifier

Identifier acquisition

Identifiers are usually placed in request headers, e.g., routeId:2.0.0 for version‑specific routing or serverC:3.0.0 for service‑specific routing.

Gateways or interceptors read these headers and pass them to the routing logic.

Identifier management

Custom routing needs to write the identifier into a context container during the write phase and read it during routing; if absent, the master branch is used.

3. Service Selection

Service selection involves querying the registry for available instances, filtering by routing rules, and then applying load balancing to pick one instance.

Embedding version tags into service metadata and combining them with service name or IP enables multi‑dimensional filtering suitable for lightweight gray strategies.