Gray Release (Canary Deployment): Definition, Design, Strategies, and Complex Scenarios

Gray release, also known as canary deployment, is needed for internet products that require rapid iteration while maintaining quality; it allows traffic to be directed to a new system for quick feature verification and enables immediate rollback if problems arise, essentially functioning as an A/B testing system.

A simple gray release architecture consists of three essential components: a strategy configuration platform that stores gray policies, an execution program that applies those policies, and a service registry that records services with their IP, port, name, and version.

Common gray strategies include traffic splitting based on request headers, cookies, or request parameters; for example, using a user ID (uid) modulo operation to route 1% of users to the new version while the remaining 99% continue using the old version.

Gray policies can be single (e.g., based on uid, token, or IP) or composite, where multiple services are gray‑released together using a tag field to coordinate which services receive the new version.

In the execution layer, upstream services such as Nginx or gateway/business logic layers enforce the gray policies. Nginx requires a Lua extension and a locally deployed agent to receive policies from the configuration platform and reload configurations gracefully.

Gateway, business, and data access layers simply integrate the configuration platform’s client SDK, which receives policies and executes them directly within the service code.

Complex scenarios include releasing multiple services simultaneously in a call chain by tagging requests (e.g., tag T) so that downstream services route based on the tag, and data‑centric releases where the new version introduces additional database fields, requiring data duplication, double‑write, and message‑queue‑based synchronization to ensure consistency.

During gray release, data from both old and new databases should be compared to verify consistency, ensuring that whether the rollout succeeds or is rolled back, no data loss occurs.