文｜張化仁（花名：花倫 )
網商銀行基礎技術架構部架構師
校對｜阚廣穩(花名：空門)
本文 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 流量的隔離，後續還将進一步完善支援消息等流量的隔離。
歡迎有類似訴或對相關技術方案有興趣的同學随時來交流探讨。
本周推薦閱讀
雲原生運作時的下一個五年 螞蟻集團技術風險代碼化平台實踐（MaaS） 還在為多叢集管理煩惱嗎？OCM來啦！ Service Mesh 在中國工商銀行的探索與實踐