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

2021-10-14 11:31:25 字數 3139 閱讀 5221

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

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

灰度發布是業界一種規避發布風險的有效的手段,通常可以藍綠部署、滾動發布、灰度發布等幾種方式實現。

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

圖 1  藍綠部署

滾動公升級就是在公升級過程中,不是同時啟動所有新版本,是先啟動一台新版本,再停止一台老版本,以此類推,直到公升級完成。但是滾動公升級存在風險,在開始滾動公升級後,流量會直接流向已經啟動起來的新版本,但是新版本是不一定可用的,比如需要進一步的測試才能確認。那麼在滾動公升級期間,整個系統就處於非常不穩定的狀態,如果發現了問題,也比較難以確定是新版本還是老版本造成的問題。

圖 2  滾動發布

灰度發布即先啟動乙個新版本應用,但是並不直接將流量切過來,而是測試人員對新版本進行線上測試。如果沒有問題,那麼可以將少量的使用者流量匯入到新版本上,然後再對新版本做執行狀態觀察,收集各種執行時資料,如果此時對新舊版本做各種資料對比,就是所謂的 a/b 測試。當確認新版本執行良好後,再逐步將更多的流量匯入到新版本上,在此期間,還可以不斷地調整新舊兩個版本的執行的伺服器副本數量,以使得新版本能夠承受越來越大的流量壓力。直到將 100% 的流量都切換到新版本上,最後關閉剩下的老版本服務,完成灰度發布。如果在灰度發布過程中(灰度期)發現了新版本有問題,就應該立即將流量切回老版本上,這樣,就會將負面影響控制在最小範圍內。

圖 3  灰度發布

工行從 2015 年開啟了 it 架構轉型工程,分布式體系已覆蓋百餘個關鍵應用,已有上萬分布式服務節點,日均服務呼叫量超 60 億,交易峰值逾 10 萬 tps,實現了遠端主機效能容量的集群處理能力。截至 2019 年,工行各專案主要通過滾動公升級、藍綠發布、業務開關三種方式實施了灰度發布。

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

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

圖 4  工行全鏈路灰度流程

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

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

圖 5  軟負載灰度路由

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

圖 6  服務框架灰度路由

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

圖 7  灰度標識透明傳遞

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

圖 8  灰度降級

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

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

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

網際網路金融時代下,金融產品和服務模式不斷創新,金融系統容量需求急劇增長,為進一步滿足運維標準提公升工作的需求,提公升服務連續性水平。中國工商銀行 後簡稱工行 從 2014 年開始分布式架構轉型的技術預研工作,通過對開源微服務框架深入調研和技術選型後,確定了基於開源 dubbo 自主研發建設分布式服...

docker zipkin(分布式鏈路追蹤)實踐

參考 dependenciesspring name test 在zipkin上顯示的服務名,不寫則是 default zipkin base url zipkin服務的位址 sender type web 網上有人在zipkin上查不到記錄,說加上這個即可,但本人親測不加也是可以查到記錄 sleu...

分布式系統全鏈路應用監控系統解決方案

分布式系統越做越大,服服務化規模也越來越複雜,為了減輕運維壓力 提高排錯能力,分布式系統的全鏈路監控系統就顯得尤為重要了。監控系統通常會包括幾個部分 第一,資料埋點和採集 這個相當重要,其實說白了,資料是整個監控系統最核心的部分,必須有能力快速和正確和方便地採集日誌,所以我們在資料埋點和採集上做了很...