分佈式全鏈路灰度發佈的探索與實踐

點擊上方「藍字」關注咱們小程序


做者|顧欣

互聯網金融時代下,金融產品和服務模式不斷創新,金融系統容量需求急劇增加,爲進一步知足運維標準提高工做的需求,提高服務連續性水平。中國工商銀行(後簡稱工行)從 2014 年開始分佈式架構轉型的技術預研工做,經過對開源微服務框架深刻調研和技術選型後,肯定了基於開源 Dubbo 自主研發建設分佈式服務平臺,並結合金融場景,工行在 Dubbo 基礎上對服務的註冊、發現等核心能力進行了三十餘項定製,以支持單註冊中心超 70 萬提供者的超大規模業務場景。分佈式服務做爲分佈式體系的核心能力,助力工行應用架構向分佈式、服務化轉型,承載將來開放平臺核心銀行系統。

在分佈式系統中,因爲分佈式全鏈路灰度發佈因其鏈路複雜、技術門檻高、落地難度高逐漸成爲金融科技實現全鏈路灰度發佈的難點所在。工行在分佈式系統建設方面一直走在同業前列,積極探索分佈式全鏈路灰度發佈,致力於解決分佈式架構下跨應用、跨服務的全鏈路灰度發佈能力。

業界傳統灰度發佈安全


灰度發佈是業界一種規避發佈風險的有效的手段,一般能夠藍綠部署、滾動發佈、灰度發佈等幾種方式實現。

1. 藍綠髮布


藍綠部署是指同時運行兩個版本的應用,如圖1所示,藍綠部署的時候,原有版本不中止服務,直接部署一套新版本,新版本正常運行後,再將流量切換到新版本。可是藍綠部署要求在升級過程當中,同時運行兩套程序,對硬件的要求就是平常所需的兩倍。

圖 1  藍綠部署

2. 滾動發佈


滾動升級就是在升級過程當中,不是同時啓動全部新版本,是先啓動一臺新版本,再中止一臺老版本,以此類推,直到升級完成。可是滾動升級存在風險,在開始滾動升級後,流量會直接流向已經啓動起來的新版本,可是新版本是不必定可用的,好比須要進一步的測試才能確認。那麼在滾動升級期間,整個系統就處於很是不穩定的狀態,若是發現了問題,也比較難以肯定是新版本仍是老版本形成的問題。

圖 2  滾動發佈


3. 灰度發佈


灰度發佈即先啓動一個新版本應用,可是並不直接將流量切過來,而是測試人員對新版本進行線上測試。若是沒有問題,那麼能夠將少許的用戶流量導入到新版本上,而後再對新版本作運行狀態觀察,收集各類運行時數據,若是此時對新舊版本作各類數據對比,就是所謂的 A/B 測試。當確認新版本運行良好後,再逐步將更多的流量導入到新版本上,在此期間,還能夠不斷地調整新舊兩個版本的運行的服務器副本數量,以使得新版本可以承受愈來愈大的流量壓力。直到將 100% 的流量都切換到新版本上,最後關閉剩下的老版本服務,完成灰度發佈。若是在灰度發佈過程當中(灰度期)發現了新版本有問題,就應該當即將流量切回老版本上,這樣,就會將負面影響控制在最小範圍內。

圖 3  灰度發佈

工行對企業級鏈路灰度發佈能力探索服務器


工行從 2015 年開啓了 IT 架構轉型工程,分佈式體系已覆蓋百餘個關鍵應用,已有上萬分佈式服務節點,日均服務調用量超 60 億,交易峯值逾 10 萬 TPS,實現了遠程主機性能容量的集羣處理能力。截至 2019 年,工行各項目主要經過滾動升級、藍綠髮布、業務開關三種方式實施了灰度發佈。

隨着 IT 架構轉型,分佈式體系支撐的服務的底層架構和平臺系統日益複雜,生產運行不肯定因素相較於主機明顯增長,這就對生產系統穩定運行提出了更高的要求。工行於 2020 年上半年已支持分佈式全鏈路灰度發佈方式,旨在複雜分佈式場景中,針對行內重點產品線、重點應用、公共支撐平臺,造成統一的灰度發佈規範,爲重點產品線提供了全鏈路灰度發佈能力的技術支撐。

1. 面對多樣化金融業務場景,構建企業級全鏈路灰度能力


工行目前已有近 10 億帳戶,每日經過多種渠道處理近 2 億筆支付結算業務,對系統的高可用能力要求極高。面對不一樣產品線,迫切須要端到端的全鏈路灰度發佈,來下降版本發佈的風險。工行全鏈路灰度發佈能力經過對業務流量進行染色,聯合軟負載均衡、網關、服務框架等多個組件,實現染色流量按標籤進行路由,支持跨應用、跨節點的全鏈路灰度路由能力,並創建灰度發佈運維監控體系和管控機制。

圖 4  工行全鏈路灰度流程

2. 流量標籤級灰度路由能力,駕馭金融業務場景


全鏈路灰度發佈採用標籤路由的方式,經過軟負載和服務框架識別染色流量中的標籤和灰度環境節點標籤,實現對應染色流量只在對應標籤的灰度環境中流轉。

1)軟負載灰度流量分發


軟負載經過識別流量中的灰度標籤,把灰度流量路由發送至對應標籤的灰度環境,實現灰度流量的第一級分發。

圖 5  軟負載灰度路由

2)服務框架灰度路由


灰度請求流量流轉到業務層服務化節點後,後續流量就由服務框架代管,經過 RPC(Dubbo)協議流轉,服務框架的標籤路由層會自動識別本次請求是否攜帶灰度流量標識,並篩選特定的灰度環境並轉發請求。

圖 6  服務框架灰度路由

3)灰度標籤鏈路透明傳遞


在業務服務層,服務框架負責灰度標籤的傳遞。Dubbo 提供了優雅的隱式參數機制,方便地傳遞上下游的一些標記和控制消息,而實現對業務無感的能力。工行微服務框架在此機制上,將灰度標籤做爲一隱式參數,在消費方發起請求切面中自動將該參數設置在請求中,使得灰度流量在鏈路傳遞過程當中,其攜帶的灰度標識能被層層傳遞下去,實現全鏈路灰度發佈能力。

圖 7  灰度標識透明傳遞

4)灰度降級保障業務交易安全執行


當鏈路中存在環節全部服務節點灰度標識均沒法匹配灰度請求標識,則灰度請求在該環境經過正常節點處理,且保證灰度標識能繼續向下遊傳遞。保障系統高可用能力,防止流量找不到對應標識節點而出現交易失敗的狀況。

圖 8  灰度降級


3. 總結


目前工行已建設統一的全鏈路灰度發佈標準,下降了各應用實現灰度發佈的改造人力成本及灰度環境建設難度,提升了研發效率,最終實現跨應用、跨服務的一致性灰度發佈能力。已在聚合支付業務線、手機銀行業務線等二十餘個應用實現了全鏈路灰度發佈能力。

將來展望微信


隨着工行 IT 架構轉型的持續推動,工行將持續構建以主機和平臺雙核心的金融信息系統,保證金融服務的穩定運行,支撐高頻業務快速增加。以「開放性、高容量、易擴展、成本可控、安全穩定、便捷研發」爲建設理念,在分佈式全鏈路灰度發佈領域積極推進技術創新、管控升級,覆蓋銀行核心交易鏈路場景,持續完善全鏈路灰度發佈模式,減小應用接入成本,提高全鏈路灰度發佈中各組件兼容適配能力,以適應複雜的分佈式金融交易場景,爲智慧銀行建設提供有力支撐。


 


猜你喜歡  架構

大數據平臺是否更應該容器化?
三種分佈式人工智能主流框架方案對比
移動端組件化架構方案設計
建信小程序組件庫介紹

以爲不錯,點個在看

本文分享自微信公衆號 - 金科優源匯(jkyyh2020)。
若有侵權,請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」,歡迎正在閱讀的你也加入,一塊兒分享。app

相關文章
相關標籤/搜索