作業幫多雲架構設計與實踐

  1     業務背景

作業幫的業務場景，大體有這幾種，工具場景、電商場景，還有線上直播場景、智慧硬體場景等。業務背後，技術複雜度突顯。

  2     技術現狀

服務數量已達到數千級別，服務例項數量達到數萬級別，計算核數已達到數十萬級別，技術棧遍地開花，將近 10 個，但主要還是Go和 PHP。業界看，這個量級已初具規模。

  3     多雲轉型

慶幸的是，作業幫一開始就建立在公有云底座之上，享受著早期雲端計算釋放的成本紅利。當然反過來，也面臨雲端計算帶來的新挑戰。單雲故障時，我們很無奈；單雲鎖定，成本最佳化方向，我們也很無助。

另外隨著雲端計算的普及， 別把所有雞蛋都放同一個籃子裡，這一放之四海皆準的思想，逐漸催生整個行業多雲轉型，作業幫也不例外。

  1     多雲選型

業界多雲選型有很多種，怎麼選擇適合業務發展的方案呢？從多雲核心價值思考，我們重點關注的能力指標，無外乎就這幾個：災難恢復、故障轉移、成本最佳化、避免鎖定、資料主權、特定訪問。針對這些指標，給它做個加權打分，得出以下結論，如圖所示。

顯然，多雲多活策略，是對以上6個能力指標極致要求的產物，作業幫就是在該選型下進行架構建設和運營管理的。

  2     架構設計

選型確定後，架構設計目標關鍵點如下：

優先從南北向入口進行流量排程，避免專線故障時，排程無能為力； 流量進到本雲後，其內部服務註冊發現要完全閉環於本雲內；  同城多雲叢集，基礎和業務服務及其依賴，都要同構部署；  從雲上RDS遷移到自建儲存服務，避免雲廠商深度鎖定； 打通多雲網路低延時互通。

  3     架構挑戰

第一，如何保障總體服務穩定性？

多雲故障率顯然加大，是相加還是相乘，取決於錯綜複雜的服務鏈路及其依賴，是否都閉環在同一朵雲內。 若出現跨雲，那麼某一服務出問題便會影響到全域性，故障率即為相乘，反過來則相加。另外，資料跨雲部署，腦裂機率也隨之加劇。這種情況下，如何保住穩定性？

第二，如何解決多雲異構帶來的效率問題？

為保以上穩定性，通常需更多混沌工程攻防演練，以防熵增，但人力消耗大。同時，基礎設施和服務例項數量較單雲成倍增加，再加上多雲異構，若不加以技術管理，運維和研發效率將被大受影響，進而反作用於穩定性。

最後，如何控住多雲財務成本只減不增？

如果服務冗餘多雲部署，比如極端情況下，每個雲部署 100% 容量所需資源，那成本將成倍增加，並且極其浪費，怎樣做才能有更好的收益？

  1     架構建設

自底向上，逐項建設如下。

• 多雲互通

要玩多雲，首要做的，就是把不同雲的網路打通。

現階段，國內網路四通八達，得益於國家基礎設施的紅利 。作業幫在實踐中逐步摸索出一套雙供應商組網和CPE管控的網路方案，實現在多雲拓撲下網路低延時互通，並且具備頻寬靈活擴縮、跨雲異常流量分析、單節點單線路故障自動切換、新增雲供應商快速低成本接入等特性。

星型網路拓撲，平鋪抽象後，網路架構如圖所示，新雲加入，只需在新雲上拉兩條專線掛到兩個環網接入點即可。

• 網路規劃

網路得有前瞻性規劃，開弓便無回頭箭，一旦規劃出錯，後面基本上很難扳回正道。

為了讓多雲能夠具備靈活網路安全和斷網管控能力，便結合安全域和部署環境進行網路規劃。服務部署在哪個 IDC ，生產域還是辦公域，亦或是其他域，其網路應是不同的。作業幫甚至細化網段到服務型別，是資料儲存服務，還是其他PaaS服務。

• 計算管理

任何一個具備企業級應用的雲廠商，都至少會有這樣的機型，裸金屬、GPU、AMD、虛擬機器，計算密集型、記憶體密集型、網路密集型、磁碟密集型等，多如牛毛 。

若再加上多雲的機型組合，很容易就帶來運維災難。 我們把規模場景特化，得出有限應用場景，最後產出可簡單列舉的有限機型。

確定機型後，接著把機型、網路和儲存的組合抽象為套餐。三者笛卡爾積之下，套餐數量仍不可控，這就需要套餐管理。採購的時候，從套餐直接下單，例項化後就成為能看得見摸得著的機器。這時候，機器數量太多，超過人肉管理能力，這就需要 CMDB進行全生命週期的管理，直到它被銷燬。

• 資料儲存

為避免雲廠商深度鎖定，我們率先從雲上RDS遷移到自建儲存服務。

在多雲場景下，自建資料儲存面臨的主要問題，還是分散式經典的CAP問題。在出現跨雲資料分割槽P的情況下，A可用性和C一致性無法兼得。要麼保AP，要麼保CP。

解法是根據業務場景做取捨，靈活選擇 CP 或者 AP ，並適當犧牲第三維度能力，換來其他兩個維度的最優解。場景應用和對策如下。

資料儲存 - 雲間主從，弱A 保CP

在交易場景中，資料強一致性是首要剛性要求。 在多雲主從方案設計時，根據CAP理論，適當弱化A 來保 CP。如下圖所示，在正常狀態下，右邊分割槽讀流量訪問本雲DB從服務，寫流量會跨雲寫入主庫，主從之間透過專線低延時同步資料。

故障時刻，右邊資料分割槽DB Proxy 讀寫均返回失敗，確保交易讀寫資料強一致性。

資料儲存 - 雲間主從，弱C 保AP

搜尋批改等場景，讀多寫少，需優先保證資料讀能力的可用性，極端情況下可接受小機率資料不一致。 主從方案設計時，適當弱化C 來保 AP。正常狀態下，右邊資料分割槽讀流量訪問本雲DB從服務，寫流量會跨雲寫入主庫。故障時刻，DB Proxy 優先可讀，但不能寫。 

資料儲存 -  雲內單元化，進一步弱C 強保AP

運維預案等強控制面場景，其穩定性要比普通業務還高，最優先保證資料讀寫的可用性。主從方案設計時，進一步弱化C來更強一步保AP。

雲內資料單元化部署，每朵雲各自有主從服務，多雲間透過DTS進行資料雙向複製，並加上資料同步衝突解決策略。其特點是資料不一致機率大，但在運維場景中可以接受。

• 註冊發現

容器內服務註冊發現，直接使用 K8S 原生Service 基於IPVS的能力。

容器內訪問虛機的服務註冊發現，透過自建 Sync服務，把虛擬化架構 ZNS 節點例項資訊，實時註冊到 Service ，其Endpoint指向就是ZNS例項資訊，這樣就可以把它當做統一的Service 看待，並且被容器其他服務所訪問。

• 服務通訊

容器和虛機通訊方式，虛擬化架構下，虛機使用水平域名，透過容器閘道器Ingress請求容器服務，容器閘道器Ingress和容器內部天然網路打通。容器內部服務間通訊使用原生 Service 發現下游服務。

容器訪問虛機服務，依託容器外註冊發現，其Endpoint指向就是虛機服務例項，對容器呼叫透明。虛擬化服務間互訪，透過中心式名字服務ZNS來發現下游例項。

• 流量排程

流量從南北向入口進來，若直接使用傳統 DNS 排程，則面臨問題如下：

第一，DNS 解析生效時間太長，且長尾不可控。經實踐測試，約 90%+的流量，通常可以在十分鐘內解析完畢，剩下長尾就不確定了。

第二，傳統DNS應答資料易被劫持篡改，有些使用者訪問會被路由到一些釣魚網站。

第三，使用者所在區域的LocalDNS 快取歷史或問題資料，導致網路傳輸不符合預期。

解法就是自建DoH服務，並遵守DoH和DoT標準協議，支援DNS over HTTP(s)等三種安全傳輸模式。App端上所有網路請求，經過統一SDK，該SDK 事先會埋入定製的DoH Server IP，透過該IP並帶上域名引數去請求DoH服務，DoH透過權威解析後返回目標IP地址，客戶端再使用這個IP透過HTTPs 協議訪問後端服務。

從DNS升級到DoH排程，收益明顯。DNS劫持問題不復存在，後端應用服務網路成功率提升一個數量級以上，另外多雲間流量可按精準比例排程。

• 容器遷移

業務關鍵改造之一是服務容器化， 其背後的思考在於透過雲原生的規範和能力，實現運維物件同構，方便後續多雲部署，靈活控制成本和規模化運維。

作為擁有數年積澱的科技公司，作業幫同樣也有此歷史包袱：服務規模大，機器規模大；前期為了最大化資源利用率，大量模組，大量服務混部在同一個物理機或者虛機上，耦合關係大。同時，服務間依賴關係又複雜，怎麼解？

首先，劃分業務遷移節奏。通常，規模化服務遷移可分為三部曲，一般業務第一個吃螃蟹，先試先行；核心業務往往需要觀望半年後再躍躍欲試，長尾的邊緣服務最後迫於壓力跟進上車。

針對一般業務，首要做的便是解除混部，服務化改造，接著把這些業務域名從www公共域名拆分出來，如此便做域名流量排程及容器化遷移。

再者，變更服務發現方式，從中心式名字服務，改為叢集內自治的服務發現。

最後，服務遷移到容器環境期間，流量放量比例要可控，操作要具備回滾能力。放量初期，透過東西向按比例逐漸放量，放量比例超50%後，再從南北向入口，把所有流量排程過來，最後達到整體服務平滑遷移到容器。

• 多雲遷移

嚴格按照多雲規範落地，只要業務遷移到容器環境，它天然就具備多雲部署的關鍵能力。多雲遷移，其實就是把等量的服務，在IDC-2部署一遍，然後南北向放量便可。 主要挑戰是：業務多雲部署節奏不一致，以訊息佇列為代表的非同步流量問題異常突顯。

比如，一般業務優先雙雲部署到IDC-2，它生產的訊息自然就寫入IDC-2的MQ，這時未完成多雲部署的核心及邊緣業務，就需要同時跨雲消費一般業務生產的訊息，才能保證訊息消費的完整性。

這種情況，不符合單雲閉環的架構預期，而且會持續存在，直到所有服務雙雲部署完備。實際上，需要Proxy服務發現能力，而原生RocketMQ 4.X版本沒有此能力，怎麼解呢？

短期，人工修改業務跨雲服務發現，過渡期跨雲無法避免，這時作業幫就透過多雲運營系列技術手段，防架構裂變。 

中長期，自建MQ Proxy，負責非同步服務註冊發現。對生產和消費方來說，它只需知道本雲Proxy地址，至於Proxy發現到哪朵雲的Broker ，那是Proxy內部實現邏輯的事情，生產和消費使用方無需關注。這樣經架構和平臺進行管控，做到對業務透明。

  2     運營管理

架構建設就緒後，不能生而不養，更少不了運營管理。

• 多雲運營

多雲運營，可以按此思路展開：

上邊，優先健全多雲架構規範，防止架構裂變。左邊，結合需求場景和架構規範，DevOps加持，落地平臺能力，按規範進行需求交付，控住新增非標問題。右邊，結合架構規範和架構現狀，進行技術度量，暴露問題，驅動架構治理，修復存量問題。

總地來說，左右開弓，形成閉環，讓價值快速流動，透過防裂變、控增量、修存量，達到運維物件同構維持，再透過運維服務化能力，低成本實現規模化運維。

• 常態斷網

常態斷網即典型技術運營場景。背景是初期多雲建設一錘子驗收透過後，業務變更引入非標問題，導致多活能力功虧一簣。有待解決的是：控住增量，不因業務變更，破壞基礎架構能力，所以需要在雲間常態斷開業務應用的跨雲訪問。

斷網模型是隻有資料儲存和有限的中介軟體可以跨雲互相訪問，有限中介軟體可以被其他服務互訪，但其他服務跨雲之間不能直接互訪。

斷網方案主要有兩種：

1)從網路層進行專線域控和虛機例控；

2)從應用層進行ACL控制。

前期Mesh覆蓋度不高，主要藉助網路能力進行常態斷網。前面提到網路規劃，此處正好應用起來。具備斷網能力之後，進一步藉助混沌工程攻防演練，在半夜低峰期間，模擬雲間專線故障，有時直接拔斷專線，並引入 QA 視角，從真實使用者角度進行單雲閉環能力驗收。驗收透過後，持續維持雲間常態斷網。後續業務變更，但凡它不符合單雲閉環規範，首次上線就會有問題，便不會因它變更破壞基礎架構能力。 

• 服務管理

變更類管理，主要是服務上線和運維需求交付。

服務上線無非就是對程式碼、配置、路由、資料的釋出，既要落地運維軍規，也要保證部署的一致性，即程式碼同構、配置同構、路由同構。

作業幫把這些釋出抽象為CD流程，中間還加個統一封線管控。 

多雲場景下業務怎麼上線呢？ 橫向依次按照預發、灰度、全流量環境進行釋出。縱向各環境按比例釋出，比如先發單臺，再20%，最後全量釋出。同時，把釋出工單事務化，在釋出生命週期內，但凡哪個環節出問題，就需把工單回滾，其他變更才能繼續上線。透過此設計保證多雲環境同構，否則會反作用到穩定性。

運維需求交付，也是引發多雲架構裂變的變數，在變更方式上，也需要平臺進行標準交付。底層，我們抽象出統一工單引擎。上層，把運維場景具象化，比如服務准入、路由變更、容量變更等，接入統一工單引擎，它就變成具體的工單平臺。透過平臺進行需求交付，不僅符合標準流程，更多的是透過平臺把運維軍規優雅落地。 

• 服務觀察

主要依託服務日誌Metrics & Logging & Trace三大黃金能力，建立可觀測多維視角。

首先建立服務觀察能力，讓多雲觀察看起來跟單雲一樣。在此基礎上建立多維度觀察視角，注重快速圈定故障範圍能力，結合故障時間點，觀察附近時間範圍可疑異常場景、變更事件、異常容量問題等。宏觀定位圈定異常範圍後，此時就可以決策預案止損。

若問題複雜到不能果斷做決策時，還可以藉助微觀排查，快速下鑽觸達異常資源、異常服務和異常鏈路。

• 多雲預案

多雲建設就緒後，怎樣最大化其價值？預案即最好切入點之一。

先把預案做全新定義與重構，我們覺得預案就是高度固化的複雜操作集合體，其背後有複雜技術體系支撐，最終需要抽象為一鍵無腦操作的能力。

實際上，運維背後有各種各樣的作業，依託作業平臺實現。

把一部分運維作業操作固化之後，它就可以抽象為原子預案。原子預案不直接對外提供服務，僅向上提供編排支援。把原子預案做一次編排，讓它變成場景預案，此時，場景預案可應用於區域性業務容災。再把場景預案做二次編排，變成全域性預案。這時，全域性預案已經抹平所有差異，可應用於單雲故障容災。整體看，就是金字塔模型。

• 多雲度量

多雲度量 首要解決的是發現非標架構問題，然後資料驅動架構標準化改造。

另外，透過架構治理改造，也能輔助提高多雲度量的資料質量。透過多雲度量資料分析，作業幫也發現架構規範短板，反過來完善規範或者生成新規範。如此迴圈往復，驅動多雲架構能力成熟演進。

第一，最明顯的即成本收益。多雲架構轉型後，便具備多雲廠商選擇權利，貨比三家，遵守市場規律辦事情，議價能力增強。

容量靈活擴縮。業務週期性大促，往往需要準備很多機器資源，多雲多活後，大促結束即可退還冗餘機器。同時，多雲廠商的備貨能力之和很強，再利用其競爭關係，無需業務囤積空閒機器。

近期作業幫從某雲廠商市中心AZ遷移到冷啟動的京郊AZ。此事加之疫情管控干擾，耗時兩個多月，將所有服務遷到京郊。因為京郊土地、電力、人力等綜合成本便宜，最終作業幫享受到多雲多活釋放的巨大成本紅利。試想，若無多雲多活能力，哪怕再大的紅利擺在面前，也只能望而興嘆。

第二，穩定性收益。多雲故障率會增加，但具備同構部署的多雲多活架構後，便可以藉助服務觀察能力、預案能力，快速逃逸止損，最終服務穩定性有明顯提升。

最後，效率收益。單雲過渡到多雲多活，基礎設施和服務例項成倍增加，作業幫透過容器化部署，以及 DevOps 加持，除了商務溝通外，穩住多雲管理的綜合效率。