How Solar Enables Seamless Blue‑Green Deployments in Cloud‑Native Microservices
This article explains how the Solar microservice framework, built on Spring Cloud, provides a fully automated, safe, and loss‑less blue‑green release system with intelligent monitoring, weight‑based traffic shifting, and namespace isolation, empowering large‑scale online education platforms to achieve rapid, reliable deployments without manual intervention.
Introduction
"When a company grows rapidly, it cannot staff too many people for operations and service; technology must drive efficiency. Mastering Education transformed into a technology‑driven company to survive in a capital‑driven market." — Zhang Yi, Founder & CEO of Master 1‑to‑1
Since its 2014 shift to online education, Master 1‑to‑1 has embraced cloud computing, big data, AI, AR/VR/MR, and now 5G, using technology to empower learning. Rapid business growth and pandemic‑driven demand have increased traffic, accelerating microservice iteration and raising operational costs.
To address this, the infrastructure team launched a daytime‑safe, loss‑less microservice gray‑green release system with strong monitoring to precisely steer traffic and boost technical capability.
About Solar
Solar is the next‑generation microservice foundation for Master 1‑to‑1, planned in November 2019 and first released on 2020‑01‑04. Version 1.2.0 & 2.2.0 (April 2020) stabilized compatibility with Spring Cloud Edgware, Finchley, Greenwich, and Hoxton. It follows a three‑layer architecture.
Base Public Components : Atomic, independently deployable components that can be loosely coupled; removing one does not affect others.
Base Public Framework : Built on Spring Cloud, exposing components as a framework and aggregating them like building blocks.
Base Public Services : Public services that use the base components, forming the satellite‑style composition of the Solar framework.
Solar leverages Spring Cloud technologies such as Eureka, Apollo, Zuul, Sentinel, Hystrix, SkyWalking + OpenTracing, CAT, Prometheus + Grafana, Kibana, and provides enterprise‑grade plug‑in, out‑of‑the‑box features. Core modules include:
Full‑link gray‑green release intelligence & DevOps platform integration
Zuul dynamic filtering for gray‑green routing & Furion unified console
Sentinel full‑link circuit breaking, rate limiting, and custom features
Middleware: Apollo, Eureka, VI, Sensitive, EventBus, Agent, XXL‑Job, etc.
Docker CI & automated testing
One‑click scaffolding for services and gateways
Monitoring trio: Tracer (SkyWalking & CAT), Metrics (multi‑dimensional business metrics), Logger (MDC, Kibana, ES, GOHANGOUT)
Data middleware integration: MySQL (ShardingSphere), RocketMQ, MongoDB, Redis
Big‑data platform support: Kafka, ElasticSearch, InfluxDB
GPM monitoring platform integration: Prometheus, Grafana, InfluxDB, AlarmCenter (email, DingTalk bot, app alerts)
Alibaba Cloud OSS support
Terminology
Full‑Link
Full‑link refers to the end‑to‑end call chain from gateway to downstream services, e.g., gateway → A → B → …
Gray Release
Also known as canary release, it deploys a new version without downtime, initially routing a small percentage of traffic (e.g., 5%) to the new version while the majority (95%) stays on the old version. After monitoring confirms stability, traffic is gradually shifted.
Purpose: enable daytime, safe, loss‑less traffic migration.
Full‑Link Gray Release
Traffic is allocated to either "Link 1" or "Link 2" across the entire call chain, preventing cross‑version calls (e.g., A 1.0 cannot call B 2.0), thus avoiding incompatibility.
<code>Link 1: gateway->A (1.0)>B (1.0)
Link 2: gateway->A (2.0)>B (2.0)</code>Operators assign 95% weight to Link 1 and 5% to Link 2; if any service in Link 2 fails, its 5% traffic is cut off, achieving rapid rollback.
Blue‑Green Release
Deploy a new version alongside the old one, switch traffic to the new version for fast rollback, and eventually retire the old version after traffic reaches zero.
Purpose: enable daytime, condition‑driven switching between two environments with minimal impact.
Full‑Link Blue‑Green Release
Same concept as full‑link gray release but applied to blue‑green scenarios.
<code>Link 1: gateway->A (1.0)>B (1.0)
Link 2: gateway->A (2.0)>B (2.0)</code>Headers (e.g.,
domain=greenor
domain=blue) determine which link is used.
Applicable Conditions
All full‑link services must route through the Solar gateway.
All full‑link services must be integrated into the Solar framework.
Services not yet integrated must undergo a final rolling release to adopt Solar’s gray‑green capabilities.
Static IP load‑balancing is compatible but does not support Solar’s gray‑green features.
Blue‑Green Release Process
Note: The described “blue‑green release” combines both blue‑green and gray‑release concepts.
Successful Flow
<code>Create Plan → Deploy Blue Environment → Execute Blue‑Green → Verify → Offline Green Environment → Finish Plan</code>Failure Flow
<code>Create Plan → Deploy Blue Environment → Execute Blue‑Green → Verify → Rollback Blue Environment</code>Pre‑Release: Plan Creation
Users create a release plan on the CD platform, listing services to be released (e.g., Service A and Service B) and defining version‑driven or weight‑based conditions.
The system automatically generates baseline version‑matching rules for the green environment and pushes them to all gateways.
<code><rule>
<strategy>
<version>{"solar-service-a":"1.0", "solar-service-b":"1.0"}</version>
</strategy>
</rule></code>During Release
Deploy Blue Environment
After services register with the discovery center, they enter the blue‑green stage.
Execute Blue‑Green
Based on the plan, the CD platform creates a blue‑green strategy. Two modes are supported:
Condition‑Driven Mode : Define HTTP header conditions (e.g.,
#H['domain'] == 'green') that map to specific version routes.
<code><rule>
<strategy-customization>
<conditions type="blue-green">
<condition id="c1" header="#H['domain'] == 'green'" version-id="route1"/>
<condition id="c2" header="#H['domain'] == 'blue'" version-id="route2"/>
</conditions>
<routes>
<route id="route1" type="version">{"solar-service-a":"1.0","solar-service-b":"1.0"}</route>
<route id="route2" type="version">{"solar-service-a":"2.0","solar-service-b":"2.0"}</route>
</routes>
</strategy-customization>
</rule></code>Weight‑Based Mode : Allocate traffic percentages to routes (e.g., 5% to green, 95% to blue) and gradually increase the new version’s weight after each observation.
<code><rule>
<strategy-customization>
<conditions type="gray">
<condition id="c1" version-id="route1=95;route2=5"/>
</conditions>
<routes>
<route id="route1" type="version">{"solar-service-a":"1.0","solar-service-b":"1.0"}</route>
<route id="route2" type="version">{"solar-service-a":"2.0","solar-service-b":"2.0"}</route>
</routes>
</strategy-customization>
</rule></code>Verification
After the blue‑green rules take effect, validation tools (e.g., SkyWalking full‑link tracing) confirm that new traffic reaches the intended services without errors. Pre‑checks include routing policy validation, path validation, and real‑time trace observation.
<code>1. TraceId and SpanId output
2. AppId and service name output
3. Service IP address output
4. Gray version, region, and sub‑environment output
5. Routing rule output
6. RestController class, method, input, output
7. Uncaught exception output
8. Custom business data output</code>Post‑Release
If verification succeeds, the plan proceeds to full release, decommissioning the green environment and cleaning up strategies.
If verification fails, the blue environment rolls back to the baseline strategy, after which the problematic service is investigated and the plan can be retried.
Intelligent Practices
Automation reduces manual cloud operations:
Deployment Automation : Business users deploy services via a few UI clicks without touching cloud consoles.
Blue‑Green Automation : Users follow predefined version iteration rules; the system handles routing and weight adjustments automatically.
Future Outlook
Beyond Spring Cloud microservices, the goal is to extend blue‑green capabilities to front‑end, gateways, Nginx, and other technology stacks, achieving true end‑to‑end full‑link releases and freeing teams from overnight deployments.
Efficient Ops
This public account is maintained by Xiaotianguo and friends, regularly publishing widely-read original technical articles. We focus on operations transformation and accompany you throughout your operations career, growing together happily.
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.