文｜張化仁（花名：花倫 )
網商銀行基礎技術架構部架構師
校對｜闞廣穩(花名：空門)
本文 4832 字 閱讀 10 分鐘
｜引言｜
微服務架構下，服務之間的呼叫錯綜複雜，一個應用可能會承載著多種不同的業務流量。由於執行在同一個應用程式內，多種業務流量之間勢必會存在相互影響的情況。
如果某種業務流量陡增，導致應用程式負載激增，進而請求排隊，其它業務流量也勢必會受影響。多數時候這種相互影響的情況都是在容忍範圍以內或者可以規避的，特定場景下我們可能就需要考慮通過隔離某些業務流量的方式，來消除業務之間相互影響的風險：
- 例如，當後臺排程型的流量影響了線上使用者請求；
- 再如，當低敏的甚至可失敗的業務影響了高敏的需要重保的業務。
業務鏈路隔離的訴求是業內普遍存在的。通常的方案是新建立一個應用，然後將需要隔離的業務遷移到這個新應用上。
新建應用的方式，研發運維等都需要付出成倍的成本，相關應用還需要配合改造和遷移。對於只有單個應用需要建立的情況或許還能勉強接受，網商銀行部分應用例如高保極簡閘道器、高保客戶檢視等當前就是採用的這種方案。這種方式是非常笨重的，而且當我們期望特定業務關聯的整條鏈路上的多個應用都進行業務隔離的話，這種方案的成本將非線性上升進而變得難以接受。
雲原生架構下，對容器和流量可以進行更精細化的管控，對於上述業務流量隔離的場景，我們有了更簡潔、更靈活、更通用的替代方案--我們稱之為「業務單元隔離」，可以在不建立新應用的情況下實現上述訴求。此方案當前已在包括核心鏈路在內的網商多個業務場景得到應用，也順利通過了今年雙十一大促的考驗。
那麼「業務單元隔離」具體是什麼？我們是如何藉助「業務單元隔離」實現業務鏈路的隔離呢？本文將和大家細述。
PART. 1 概念及基本原理
概念及運維模型
「業務單元隔離」是一套流量染色和資源隔離的方案，可以幫助業務相對簡單地實現業務鏈路隔離。在調研和驗證的過程我們也提出了優化改進方案並推進落地，最終進一步減輕了業務接入的成本。
「業務單元隔離」需要結合兩個新的概念來闡述：「AIG」和「業務單元」。
AIG 是某個應用為了支撐某些業務而隔離出來的一組資源。由一個或多個應用的 AIG 組成的、服務與某個或某類特定業務的業務鏈路我們稱為一個業務單元。保證有且只有符合特徵的流量引流到某個業務單元，我們稱之為「業務單元的隔離部署」。
主要任務及配套設施
從「業務單元隔離」的概念中我們不難看出：要實現某個業務鏈路的流量隔離，至少需要做有以下幾件事情：
1.業務單元構建：給鏈路上的應用分別建立 AIG 組成一個業務單元，且須保證不能有流量流入新建的業務單元。
2.業務流量識別：需要通過某種方式識別出上遊應用流入的特定業務的流量。
3.特定業務引流：對於識別到的特定業務的流量，需要有機制讓這些流量流向新建立的業務單元。
很顯然，上述的這些事情，必然需要基礎設施側和應用側相互配合才可實現。如下圖所示，相關的基礎設施及作用如下：
1.業務單元構建：需要為 AIG 提供完整的研發/運維/監控支援；
2.流量識別（RPC）：鏈路中業務單元上游的應用（A）需要接入打標染色 SDK，以便通過染色管控平臺下發打標染色規則；
3.流量識別（排程）：複雜排程（訊息觸發，應用單 LDC 內自主分發批任務）通過轉換成基於 SOFARPC 的流式任務，從而實現染色和隔離。
4.特定業務引流：MOSN 側的精細化路由需要支援 AIG，讓流量可以流入到新特定的業務單元。
業務單元構建
業務單元實際是一個相對抽象的概念，對應一條業務鏈路。
網商的實踐中，為了讓業務單元更加具象化，我們規定一個業務單元內的多個應用，其 AIG 名稱（appname-aigcode）中的 aigcode 部分必須儘可能一致。
因此，構建一個特定的業務單元，本質上是要給鏈路上相關的應用，都建立出服務於特定業務隔離的資源組（AIG）。
對於單個應用，構建 AIG 包含兩部分：
一是初始化 AIG 後設資料；
其次是圍繞此 AIG 的各種運維操作（擴縮容、上下線、重啟、sidecar 注入升級等）。
可以看到要支援 AIG，PaaS 側幾乎所有運維操作都需要適配，工作量非常很大。所以 PaaS 側在支援 AIG 這件事情上也必須權衡取捨，決定只在終態的 workload 運維模式下支援了 AIG，這也導致 AIG 強依賴應用從現有的 image 的模式遷移到 workload 的模式。
workload 運維模式下，PaaS 將釋出和運維的內容都編排成 CRD 資源，交給底層 sigma（K8s）做運維。切換到 workload 運維模式有利於集團統一發布運維體系，也可以更好的支援彈性擴縮容、自愈等場景。
但相比 image 模式，workload 模式對使用者使用習慣和體驗上衝擊很大，初期相關的問題也非常多。因此儘管網商 workload 一直在有序推進，在後續核心業務接入 AIG 的專案中，為了避免強制切換到 workload 運維模式影響核心業務運維應急，我們也給 PaaS 提了支援僅對 AIG 機器開啟了 workload 的訴求，並且針對這種情況做了完備的混合運維驗證。
RPC 流量隔離
業務單元建立好之後，如何確保新的業務單元在不引流的情況下預設沒有 RPC 流量流入呢？
應用的機器之所以有 RPC 流量流入，是因為註冊中心（SOFARegistry）和跨機房負載均衡（AntVip）中掛載了機器 IP：應用程式啟動成功 MOSN 感知到後，MOSN 會將服務資訊註冊到 SOFARegistry，釋出運維過程機器健康檢查通過後 PaaS 側會呼叫介面往 AntVip 上掛載機器的 IP。
所以，要確保新的 AIG 機器預設沒有流量流入，就需要 MOSN 和 PaaS 側做出調整。
整體調整方案如下圖所示：
如何識別特定業務的 RPC 流量呢？
上游應用接入打標染色 SDK 之後，其在作為服務端被其它應用呼叫、作為客戶端呼叫其它應用的時候，都可以被 SDK 中的 RPC 攔截器攔截，攔截器對比 RPC 請求和下發的打標染色規則，一旦 match 就會在 RPC Header 中增加業務請求標識。
最後，就是將流量引流到特定業務單元。
藉助 MOSN 強大的精細化路由能力，我們可以讓流量路由到指定的業務單元,並在業務單元內部收斂。業務單元隔離主要用到了 MOSN 的客戶端路由能力，在客戶端應用發起呼叫、請求流經當前 Pod 的 MOSN 時，可以按我們下發的路由規則控制流量的走向。
排程流量隔離
排程本質是訊息，簡單的排程場景通常也不會有隔離的訴求。很多有隔離訴求的場景當前都是“訊息任務+三層分發”的模式，利用排程觸發批處理邏輯。
三層分發協議是基於 tb-remoting 協議分發請求的，不是標準的 SOFARPC 協議，不經過 MOSN，因此 MOSN 也無法控制這種請求的走向。
為了解決這個問題，AntScheduler 推出了全新的流式排程模式，通過將三層分發模式轉變成多次標準 SOFARPC 呼叫，從而和 MOSN 無縫配合，滿足流量隔離的訴求。
對於希望排程流量直接路由到 AIG 的場景，AntScheduler 介面上可以直接配置，配置後平臺會下發服務級別的 MOSN 客戶端路由規則。
對於整條鏈路隔離的場景，排程平臺對接了打標染色平臺，發起的 RPC 流量會自動打標，下游應用可以選擇基於此標定做進一步的染色和引流。
PART. 2 非同步補賬鏈路隔離
「業務單元隔離」基礎設施落地後，先後有幾個業務場景逐步接入。非同步補賬鏈路隔離是「業務單元隔離」首次應用在核心鏈路，實現了實時交易流量和非同步補賬流量的隔離，避免相互之間的影響。今年雙十一大促非同步補賬業務單元承載了 10% 的非同步補賬流量，表現絲滑。
接下來我將以這個專案為載體，詳述我們如何藉助「業務單元隔離」實現業務鏈路的隔離。
專案背景
專案相關的應用處於網商核心鏈路上，本就屬於重保物件，而後續預期業務將急速發展，因此鏈路的高可用保障面臨巨大挑戰。
當前鏈路主要有兩種流量，一種是實時類交易的流量，另一種是上游非同步發起的補賬流量。
對於補賬類的流量，由於已經落庫，對失敗是容忍的。而實時交易的流量，是必須重保的物件。
後續業務發展非同步補賬流量將急劇增加，實時交易類的流量面臨受影響的風險，因此業務側期望能有一種方式，讓非同步補賬流量和實時交易類的流量實現資源隔離，保障實時類交易的高可用性。
總體方案
由於鏈路涉及到多個核心應用，如果採用傳統的新建應用的方案，初期改造及後續維護的成本都極高，故而業務希望採用「業務單元隔離」的方案。經過和業務方深入溝通，確認要新建立非同步補賬業務單元，並承載下述流量：
1.來自上游應用 U 的非同步補賬流量（RPC）；
2.來自上游應用 U 的補賬排程的後續流量（排程->RPC）；
非同步補賬 RPC 隔離
上述非同步補賬單元上游應用 U 需要進行少許改造，接入流量打標染色 SDK，以便我們可以識別到非同步補賬的流量。
應用 U 接入 SDK 後，作為服務端被其它應用呼叫或者作為客戶端呼叫其它應用的時候，都會被 SDK 中的 RPC 攔截器攔截，可以進行打標和染色處理。已染色的流量的 RPC 請求或響應 Header 中會帶上流量標識，MOSN 路由時識別此標識即可實現將流量引到非同步補賬業務單元。
下圖是非同步補賬的 RPC 流量的打標染色和引流邏輯示意：
非同步補賬排程隔離
排程流量的識別需要應用從“訊息任務+三層分發”模式切換到流式任務模式，轉變成多次 SOFARPC 呼叫，進而可以藉助 MOSN 精細化路由到指定的 AIG。
本專案中，補賬排程 RPC 請求已經打好標識，因此僅需在上游應用 U 側進行染色和 MOSN 引流規則的下發即可。
整個邏輯示意如下圖：
壓測及灰度機制
打標染色 SDK 在對流量進行打標染色時是可以識別壓測流量的，但本專案中我們沒有使用這種方式，而是在 MOSN 路由規則中增加了限定條件。
一方面是由於 SDK 尚不支援網商壓測流量識別；
另一方面 MOSN 規則下發流程上更加簡單。
MOSN 路由規則支援配置多個規則，每個規則由生效範圍 scope、限定條件 condition、路由目標 destination 組成，支援任何比例的灰度，也支援限定壓測流量，可確保整個引流過程的安全。下圖上游應用 U 灰度引流 1/1000 的壓測流量（shadowTest=T）到應用 A 的非同步補賬 AIG（A-vostro）的 MOSN 路由規則示意：
單元內流量自收斂
流量流入到業務單元內後，後續還會繼續呼叫其它應用，需要下發 MOSN 路由規則來保證流量收斂在業務單元內部，否則預設還是會流回預設的業務單元。
起初的方案是繼續借助打標染色 SDK 寫入的流量標識來路由，規則如：scope: app=U；condition: sl_biz_unit=xxx；destination: mosn_aig=A-vostro。
但是這種規則是和客戶端應用、服務端應用強繫結的，對於複雜的場景如本專案來說，每一條呼叫關係都需要下發一條規則，整體的梳理及維護的工作量是非常大的。
調研和驗證的時候我們識別到這個問題，和相關同學討論後，最終提出了更簡潔可行的方案（AIG 自收斂）。在 MOSN 側支援識別自身的 aigcode，下發給所有呼叫此應用的應用，規則可以簡化為只和當前應用以及 aigcode 相關，如：scope: aigcode=vostro；destination: mosn_aig=A-vostro。簡化後，規則數量和單元內的應用數量一致。
本專案自收斂規則如下圖：
｜總結及展望｜
本文主要介紹了網商在應對業務流量隔離場景的一種全新的解決方案以及業務實踐過程。
相比傳統的新增應用的笨重的方案，基於容器、ServiceMesh 等雲原生技術的「業務單元隔離」的方案更加輕量和靈活。當前我們已經實現了 RPC、排程以及 HTTP 流量的隔離，後續還將進一步完善支援訊息等流量的隔離。
歡迎有類似訴或對相關技術方案有興趣的同學隨時來交流探討。
