藍綠發布 (Blue Green Deployment) 是一種平滑過渡的發布模式。藍綠發布的操作模式上，首先依賴於能夠將全站應用劃分為對等的 A、B 兩個單元，A 先發布新產品代碼並引入少許用戶流量，B 繼續運行老產品代碼；如果新代碼 A 經線上運行觀察沒有跡象表明有問題，或者用戶行為對 A 中的變化沒有特別的反饋，那麽逐步引入更多用戶流量，直至所有用戶都訪問新產品。因此，藍綠發布可以保證整體系統的穩定，在產品開放前期就可以發現、調整問題，以保證其影響面可控，這種能力為進行頻繁的線上變更編織了一道強大的安全網，使得代碼變更更加安全可靠。

在向大家介紹藍綠發布實踐之前，先簡單回顧下支付寶系統的發布演化之路。

發布演化之路

單臺發布

在支付寶發展初期，全站只有一個應用叫 pay，幾臺服務器通過負載均衡策略組成一個服務集群。這個時期的發布非常簡單，單臺順序發布，首先關閉 1 臺服務器的流量，更新該臺服務器上的產品代碼，再打開該臺流量，即完成了 1 臺發布，重復以上步驟依次完成所有服務器的發布。

分組發布

隨著業務量的上漲和 SOA 架構的演化，應用的服務器數慢慢增加，單應用的職責也被分解為由多個應用協作承擔，一次發布包含的應用和服務器數越來越多，耗時也越來越長。為了提高發布速度，將一個應用的服務器劃分為幾組，以組為單位批量發布；另一方面，多個應用盡量並行，根據應用依賴關系排定發布的順序，被依賴的應用先發布，再發布對它有依賴的應用，沒有依賴關系的應用則可以並行發布。這個模式下的發布，新增了一個需要註意考量的復雜度，即應用發布的依賴次序。在發布前，需要事先評估好應用的發布順序，如果評估有誤，則可能造成發布期間業務出錯。

隨著支付寶業務的迅速發展以及第三代架構的全面落地，整體發布規模已發展為幾百個應用、單應用服務器數千臺、每周兩次日常發布的龐大體系。應用間依賴關系錯綜復雜，發布順序越來越難以協調，甚至可能出現循環依賴；另一方面，發布並行度無法上去也使得發布速度難以提升，一次日常發布幾百個系統依次下來，往往需要耗時十幾個小時，這在以敏捷為勝的互聯網金融時代感覺簡直令人難以接受。

beta發布

beta 發布是分組發布的一種特例形式，旨在控制項目上線的風險。對於某些風險高的項目，往往先發布少量服務器，觀察較長一段時間，確認業務 OK 後，再發布剩下的服務器。與普通分組發布相比，beta 發布可以提前發現部分問題，如有問題只需要回滾少量服務器，對現有業務運轉的影響小，但 beta 發布也有它的局限性：

1. beta 發布靠發布的服務器數量來控制新產品代碼流量，無法自由調控流量。

2. beta 發布只有非常少量的流量，暴露問題的能力有限。

3. 如果涉及多個系統間交互，A 和 B 同時 beta 少量服務器，A 需要調用 B，無法控制 A 的新代碼服務器一定會調到 B 的新代碼服務器，存在新老代碼交叉調用；一是增加了觀察人員對業務驗證的困難，二是需要考慮各種兼容性問題。

所以，我們一直在積極探索如何讓越趨龐大和復雜的系統代碼變更能夠又快又好的敏捷研發運維之路。在單元化架構能力達成之後，為這種探索帶來了新的巨大的可能。單元化架構帶來的這種新的發布能力，便是藍綠發布模式。

藍綠發布

單元化架構（下稱 LDC）的演進帶來了 2 項重要的能力，應用的單元化部署和靈活的流量調配能力。這使得我們可以將應用劃分為能夠獨立支撐全站業務的閉合單元，用戶流量能夠在單元入口靈活地調配。借助 LDC 邏輯 ZONE 結構，按 ZONE 發布的藍綠發布模式隨之誕生，以突破先前發布所面臨的困境。

藍綠發布的原理

LDC 部署架構中，應用按 ZONE 劃分為對等的藍、綠兩個單元，每個單元包含若幹個 RZONE 和 1 個 GZONE，單元與單元之間隔離，業務引發的調用鏈路只存在單元內部。日常運行狀態下，藍、綠各承擔線上 50% 的業務流量。

Step1. 發布前，將“藍”流量調至 0%，對“藍”的所有應用整體無序分 2 組發布。

Step2. “藍”引流 1% 觀察，如無異常，逐步上調分流比例至 100%。

Step3. “綠”流量為 0%，對“綠”所有應用整體無序分 2 組發布

Step4. 恢復日常運行狀態，藍、綠單元各承擔線上 50% 的業務流量

藍綠發布的價值

新產品平滑上線

藍綠發布能夠有效降低新產品上線的風險，我們可以自由控制新產品的訪問用戶量，由零開始逐步放開訪問量，在新產品開放前期就可以發現、調整問題，控制問題影響面。

對異常的快速回滾

普通發布模式下，對異常的處理速度往往依賴代碼的回滾進度，少則需要數十分鐘，多則數小時。而在藍綠發布模式下，如果遇到重大異常，只需要關閉新產品的訪問流量即可，這個過程可能僅需耗時數秒。隔離新產品的訪問流量後，有充分的時間來討論決策如何解決異常。

新老調用隔離

藍綠發布模式下，應用調用控制在單元內部，隔離了單元間的調用。一個單元要麽全部是新產品代碼，要麽全部是老產品代碼，不存在新老代碼交叉調用的情況，避免了發布期間的新老兼容性問題。

提高發布效率

藍綠發布解決了發布順序問題，由於發布期間完全沒有流量，並且沒有新老代碼交叉調用問題，可以並行同時發布一個單元內所有系統，發布速度有質的提升。

藍綠發布模式的配套能力

業務正確性的監控與驗證能力

如何在引入流量期間能夠快速全面的發現問題，精細化的藍綠分組監控會變得非常重要，包括更細顆粒度的業務健康度監控、DB 層面的監控等；另外，線上自動化測試驗證，也能幫助我們在引流階段發現由於線上線下環境差異而帶來的問題。

大規模快速自動化應用部署能力

全站應用並行發布，顛覆了以住順序發布的模式，對發布平臺的資源分發等方面的性能也提出較大挑戰。

自動精確的流量調度能力

通過強大的流量調度調控 PaaS 平臺，能夠根據不同的產品發布特性需求，進行多種模式的細粒度流量調度能力。

隨著單元化架構的落地以及後續不斷的演化和完善，隨著運維 PaaS 平臺的不斷建設和增強，藍綠發布模式在實現敏捷、高效、可靠完成生產環境代碼變更和保障持續可用的戰線上發揮了巨大的作用，是螞蟻金服強健研發運維體系中的關鍵能力模塊之一。

什麽是藍綠發布