Design and Implementation of a Gray Release System
This article explains the concept of gray release, outlines a simple architecture with essential components, describes common strategies such as header, cookie, and parameter based routing, and provides detailed implementation guidance for Nginx, gateway, and complex multi‑service scenarios.
Definition of Gray Release
Internet products need rapid iterative development while ensuring quality, and a gray release system allows traffic to be directed to newly deployed services for quick validation, functioning as an A/B testing mechanism that can roll back or fix bugs promptly.
Simple Gray Release System Design
The basic architecture includes three essential components:
Strategy configuration platform that stores gray release policies.
Execution program for gray release functionality.
Service registry where registered services carry ip/Port/name/version .
These three components constitute a complete gray release platform.
Gray Release Strategies
Common strategies include:
Traffic splitting based on request headers.
Traffic splitting based on cookies.
Traffic splitting based on request parameters.
Example: using the user UID modulo operation to route 1% of users to the new version and the remaining 99% to the old version.
Single vs. Composite Strategies
Single strategy: e.g., modulo on UID, token, or IP.
Composite strategy: multiple services are gray‑released together, using a tag field to indicate which services participate.
Execution Control of Gray Release
Gray release services are divided into upstream (strategy execution) and downstream (business) services. Upstream can be Nginx or gateway/business logic layers.
Nginx
When Nginx is the upstream, Lua extensions are used to implement gray strategies because Nginx lacks native support. An agent is deployed locally to receive policies from the configuration platform, update Nginx configuration, and gracefully restart Nginx.
Gateway/Business Logic/Data Access Layers
These layers integrate a client SDK from the configuration platform to receive and execute gray policies directly.
Complex Gray Release Scenarios
Scenario 1: Simultaneous gray release of multiple services in a call chain. The new gateway tags requests with tag T; downstream services forward requests with tag T to the new data access service, while others go to the old version.
Scenario 2: Gray release involving data changes. Since database schemas differ between versions, data must be duplicated and written in a dual‑write fashion, with MQ used to ensure consistency and avoid data loss during full‑copy operations.
During gray release, data from both databases is compared to ensure consistency, allowing safe rollback or full migration without loss.
Signed-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
Architecture Digest
Focusing on Java backend development, covering application architecture from top-tier internet companies (high availability, high performance, high stability), big data, machine learning, Java architecture, and other popular fields.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.