藍綠色和金絲雀發行

（部分： 體系結構和協議）

1）為什麼需要「安全推出」

在現代系統中，發布不僅是代碼交付，而且是銷售中的托管實驗：我們同時將風險降至最低（不破壞用戶），並縮短反饋時間（快速看到效果）。Blue-Green和Canary這兩個經典策略以不同的方式解決了這個問題，但其共同目標是：零下移，快速回滾，SLO可觀察性。

2）基本定義

Blue-Green

我們擁有兩個完整的prod環境副本：主動（藍色）服務於流量，被動（綠色）準備新版本。切換-平衡器/路由器級別的原子（switch/flip）。如果情況變得更糟-立即回到藍色。

Canary

我們分批推出：首先，很小比例的流量（例如1-5％），觀察指標/SLO，然後逐步增加份額（10％→ 25％→ 50％→ 100％）。退化-在上一個穩定步驟中回滾或停止。

3）哪種方法更好

• 我們需要一個沒有復雜操作的即時回滾。
• 體系結構/預算允許雙重基礎架構重復。
• 我們希望孤立地進行大規模遷移或平臺更新（OS/JDK/rantime）。
• 附錄/連接池對漸進「混合」狀態敏感。

• 您需要最小化blast radius並查看用戶份額上的行為。
• 高發行頻率，逐步交付為常態。
• 有成熟的可觀察性和自動門（error budget，latency，conversion）。
• 產品團隊希望驗證假設：對轉換，保留，LTV等的影響。

4）成功發布的一般原則

相同的廣告牌文物：相同的影像/封裝在所有階段。
確定性配置：作為代碼的config，環境的可比性。
設計可觀察性：標誌，度量，軌跡，變量；SLI/SLO提前。
快速、可自動回滾：按鈕/回滾命令是管線的一部分,不是手動魔法。
可互操作的電路更改：expand-migrate-contract策略（參見第10節）。
L7級路由（最好）：在標題/cookie/路徑/API版本上具有靈活性。

5） Blue-Green： 架構和流程

5.1個拓撲

兩個程序堆棧：Blue（主動）和Green（候選人）。
常見的外部依賴關系：CDN，外部API，隊列；DB是一種特殊情況（請參見第10條）。
切換點：平衡器/Ingress/Gateway。

5.2階梯式洪水

1.在新的人工制品（vNext）下舉起Green，進行工作服測試。
2.針對Green的自動測試運行（e2e，合同，回歸）。
3.加熱緩存/會話（如果適用）,同步背景喬巴/隊列。
4.將流量切換到Green： atomic flip （DNS TTL低,Route/Listener交換,Ingress weight=100%）。
5.在第一分鐘/小時觀察SLO（金色信號：latency, errors, saturation+業務指標）。
6.有問題時-立即返回藍色（翻轉後）。

5.3個優點/缺點

優點：即時回滾，簡單的心理模型，純粹的隔離。
缺點：基礎架構翻倍,復雜性與靜態組件和數據遷移。

6）金絲雀： 架構和過程

6.1個拓撲

單個程序集群；單線後面的多個服務版本（穩定和金絲雀）。
流量按權重（1-5-10-25-50-100％）或目標（按標題/cookie/ID）分開。

6.2階梯式洪水

1.將金絲雀版本丟入同一群集/ASG/NSG。
2.將部分流量（例如1-5%）路由到canary。
3.SLI/SLO自動檢查和業務指標；CI/CD中的網關（error rate，p95 latency，CPU/RES，轉換，故障/退款）。
4.通過門時的流量份額逐步增加。
5.完全滾動至100％，並停用舊版本；退化-自動回滾。

6.3個優點/缺點

優點：大多數用戶風險最小,數據驅動解決方案。
缺點：需要成熟的觀察力，有能力的路由，實例之間「version skew」的風險。

7）流量路由

L4級別：IP/端口平衡；很簡單，但幾乎沒有靈活性。
L7級別：HTTP/S規則-路徑，主機，標頭，cookie，用戶代理，GeoIP，SNI。

• 重量路由（重量1-100％）。
• 基於頭部/Cookie（將用戶提交到組）。
• 會話保持穩定（對於靜態/腰帶腳本很重要）。
• 影子/交通鏡頭（將查詢鏡像到新版本的「靜止」）。

8）工具和實現（示例）

Kubernetes: Ingress (NGINX, Contour), Service Mesh (Istio/Linkerd), Argo Rollouts, Flagger.

Облака: AWS ALB/ELB, Route 53 weighted records, ECS/EKS;GCP Load Balancing + NEG;Azure Front Door/App Gateway.

CD平臺：Spinnaker，Argo CD，GitHub Actions+Progressive Delivery插件，GitLab/CD。

9）可觀察性，SLI/SLO和門戶

Golden signals: Latency (p95/p99), Error rate (5xx/4xx по типам), RPS, Saturation (CPU/Memory/GC), Queue lag.

業務指標：轉換，授權，付款/成功，平均支票，漏鬥步驟拒絕。

• 錯誤閾值（例如,錯誤率金絲雀≤基線+X%）。
• P95的潛伏期不超過Δ。
• 業務閾值（例如，轉換下降
• SLO上的錯誤預算不應加速燃燒。

步驟持續時間：最低時間足以滿足統計意義（取決於流量）。

10）DB遷移和電路兼容性

主要規則：如果版本前後兼容,則發布是安全的。

1.Expand：添加新的列/索引/表格,而不破壞舊版本。

2.Deploy app vNext（閱讀/寫入新方案，但知道如何與舊方案一起工作）。

3.Migrate數據（背景/batch，偶數，帶有checkpoint）。

4.合同：穩定後刪除舊字段/fichi。

反模式：在藍綠色切換時需要獨家鎖定的遷移；該計劃的失敗是不可能的；沒有重復數據消除的「雙寫」。

11）回滾（rollback）和事故計劃

藍綠色：藍色上的即時翻轉；監視綠色背景喬布斯的「尾巴」。
金絲雀：體重回調（例如，從25%回到5%或0%）；自動變速箱。
數據：經過深思熟慮的重復/補償政策（idempotency keys, 「inbox/outbox」模式,重復消息消除）。
Ficheflagi：快速殺手開關,關閉部分推出的功能。

12）與牛排和會議合作

加那利群島的粘性會議，或外部存儲會議（Redis/Memcached），以便版本可以互換。
預先預熱緩存（綠色扭曲），並在翻轉時考慮入侵。
背景操作員：不要允許版本之間的「比賽」-根據版本劃分隊列或「領先」。

13）安全性和合規性

Green/Canary訪問-通過Zero Trust：服務帳戶,最低要求角色。
秘密和鑰匙-通過KMS/Secrets Manager；打開旋轉。
流量僅為TLS；endpoint的版本已明確標記；審核路由和發布操作。

14）成本和性能

Blue-Green將基礎架構加倍（在發布期間或永久）-提供預算。
金絲雀更經濟，但需要觀察工具和自動化工程時間。
優化：自動滑動,ephemeral環境,縮短版本並行存在的窗口。

15）支票單

發布之前

• 映像/票據是從單個來源啟動的，簽名已驗證。
• 測試計劃、Alerta和SLO門已配置。
• DB遷移-在expand模式下,可以使用downgrade計劃。
• 回滾計劃-已像插頭/生產一樣進行測試。

發布期間

• 度量指標和日誌與基線進行了比較。
• 對於金絲雀-固定步驟和閾值；對於Blue-Green-防翻轉。
• 呼叫團隊知道,有反饋窗口。

發布後

SLO沒有下降，錯誤預算正常。

• 發布後的遷移/清理已完成。
• 回顧和更新花花公子。

16）頻繁的錯誤和反模式

在沒有指標的情況下推出：沒有數據-沒有可管理的解決方案。
混合不兼容的DB方案，缺乏下行策略。
隨機混合流量：沒有粘性,用戶在版本之間「跳躍」。
隱藏的狀態依賴性（本地驅動器，內存緩存）。
長時間的DNS-TTL會幹擾快速翻轉（藍綠色）。
缺乏自動登機：手動「眼對眼」的解決方案會減慢並增加風險。

17）組合方法

Blue-Green+Canary：首先推出Green，然後在Green內部推出Canary進行單獨服務。
影子/遷移流量：在金絲雀之前,將鏡像流量趕到新版本。
Feature flags（漸進式交付）：該功能在穩定版本的上方包含每個段的「深色」標誌。

18）腳本示例（草圖）

Blue-Green (web+api):

1.在新的Listener/Ingress後面部署綠色（v2）。
2.我們熱緩存，我們執行readonly檢查，煙霧。
3.將重量切換為Green=100％。
4.觀看SLO 30-60分鐘；如果所有-關閉Blue。

1.Deploy canary vNext （5%復制副本）。

2.包括內部帳戶/測試段的5％流量。

3.自動門：error rate ≤ baseline+0。3%, p95 ≤ +20ms.

4.通過門時，我們將10％ → 25％ →每N分鐘提高 50％。

5.100％跨所有細分市場翻譯ficheflag；刪除舊版本。

19）不同體系結構的變體

巨石：藍綠色更簡單，金絲雀更復雜，因為仙女不可分割。使用ficheflagi。
微服務：金絲雀是自然的；留意服務間合同（消費者驅動合同）。
Stateful服務：更喜歡Blue-Green和精心設計的遷移和穩定性。

20）簡短比較（摘要）

回滾速度：Blue-Green=瞬間；金絲雀=速度快，但重量減輕。

基礎設施成本： 藍綠色↑；Canary ↔︎/↓.

用戶風險：金絲雀較低（控制份額）。
實施難度：藍綠色更容易啟動；金絲雀需要強大的可觀察性和自動化性。
數據/方案兼容性：兩者都至關重要；計劃expand-migrate-countract。

21）結果

藍綠色和金絲雀不是相互排斥的策略，而是漸進式交付的元素。選擇取決於成本限制，可觀察性的成熟度以及變化的性質。無論采用哪種方法，可持續發布都取決於四個支柱：自動化，可觀察性，向後兼容性和快速回滾。