螞蟻金服藍綠髮布實踐

原創聲明：本文系作者原創，謝絕個人、媒體、公眾號或網站未經授權轉載，違者追究其法律責任。

在前篇《素描單元化》中已經對單元化架構進行了總體介紹，單元化架構帶來了很多好處，無論是伸縮性、高可用容災還是日常運維方面，都能帶來巨大的架構能力提升。本篇將聚集介紹螞蟻金服在單元化架構下進行藍綠髮布的運維實踐。

什麼是藍綠髮布

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

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

發布演化之路

單台發布

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

分組發布

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

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

beta發布

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

beta 發布靠發布的伺服器數量來控制新產品代碼流量，無法自由調控流量。
beta 發布只有非常少量的流量，暴露問題的能力有限。
如果涉及多個系統間交互，A 和 B 同時 beta 少量伺服器，A 需要調用 B，無法控制 A 的新代碼伺服器一定會調到 B 的新代碼伺服器，存在新老代碼交叉調用；一是增加了觀察人員對業務驗證的困難，二是需要考慮各種兼容性問題。

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

藍綠髮布

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

藍綠髮布的原理

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