螞蟻金服一站式、高可用架構實踐與輸出應用

做者：梁耀斌，花名追源，來自「追本溯源」，目前主要負責螞蟻金融科技輸出產品架構，關注 ToB 的數字化轉型領域；2013 年加入到阿里技術保障部架構工具團隊，從淘寶的異地多活架構的實施，到阿里集團的高可用架構和容災體系建設，也曾經管理大規模的物理機集羣和統一調度，對系統高可用和資源調度有比較深刻的瞭解，但願可以把基礎技術普適到更多須要的企業。

背景

本文采編於螞蟻金服高級技術專家梁耀斌（追源）在 InfoQ 主辦的 QCon 2019 全球軟件開發大會廣州站的現場分享《螞蟻金服一站式、高可用架構實踐與輸出應用》，具體內容參考以下：

今天，我主要來介紹螞蟻金融智能科技對外輸出時，在高可用領域面臨了怎樣的架構挑戰與解決方案。在具體內容展開以前，咱們先認識下螞蟻金服智能科技團隊目前對外輸出的技術產品體系，經過「BASIC」即可基本歸納五大產品方向：Blockchain (區塊鏈)、Artificial-Intelligence（人工智能）、Security（安全）、 IoT（物聯網）和 Cloud Computing（雲計算）。有了對產品發展方向的理解，對於咱們理解後續的內容有較大的幫助。

mPaaS 是什麼？

其中，mPaaS（Mobile PaaS）是源自於支付寶客戶端的移動開發平臺，爲企業提供了移動開發、測試、運營及運維提供雲到端的一站式解決方案，能有效下降技術門檻、減小研發成本、提高開發效率，協助企業快速搭建穩定高質量的移動客戶端 App。

mPaaS 可以提供 Native、H五、支付寶小程序三大開發框架；100+ 的 UI 控件；以及包括掃碼，本地緩存，客戶端埋點等 20+ 功能性 SDK，可讓開發者快速接入搭建 App 所須要的基礎能力。

客戶端開發和移動中臺能力都是針對 App 自己，一個完整的 App 須要經過服務端來獲取更高階的能力。除了客戶端框架和基礎組件以外，雲端基礎服務（如 API 網關、SYNC 數據同步、PUSH 通知等）提供了接口管理、流量管控、用戶鑑權、H5 離線包、熱修復包、性能分析等運營運維能力，構建了一個高穩定、高可靠以及高效率的後臺鏈接服務。

ToB 和 ToC 的區別

每當咱們向外部的客戶介紹螞蟻輸出的技術能力時，每每會總結出三大優點：

1. 超 10 億用戶的超級 App 技術架構體系
2. 成功應對「雙十一」及「新春紅包」交易峯值的衝擊
3. 源於螞蟻金服 10 多年的技術發展與沉澱

很顯然，經過一次次的「戰役」，螞蟻金服目前的技術架構體系逐步從衆多高併發業務場景中得到錘鍊，完成了對高可用、高性能的架構特性打磨。系統的高可用性已成爲互聯網企業系統架構的基礎要求之一，以支付寶爲例，在每一年的雙十一期間，其每秒可支撐的交易量可達數十萬筆，能夠見得系統可用性的重要性。但系統可用，並不表明足夠兼容。當咱們逐步將技術能力打包對外輸出，嘗試在不一樣的業務場景中落地時，常常會聽到這樣的聲音：

1. 這個解決方案須要多少臺物理機？容器？規模有多大？成本可否再降下去？
2. 咱們有 OpenStack，產品能夠部署到咱們的虛擬機平臺上？
3. 大家的產品有 hdfs，是否可使用咱們已有的 hdfs 產品？
4. 咱們有本身的運維平臺，能夠經過咱們的運維平臺管理大家的產品？

在 ToB 的業務場景中，除了強調「高可用」特性之外，「成本」和「兼容性」同時也是重中之重。隨之而來的，這對咱們在進行高可用架構的設計和複用方面提出了三大挑戰：

1. 高可用和成本的折中

客戶的業務和自身環境的數字化有着不一樣的成熟度，對產品的高可用要求也有不一樣的見解，高可用不是客戶考慮的惟一要素，須要結合成本看投資回報率。

2. 兼容不一樣的基礎設施 不一樣客戶有不一樣的基礎設施，在系統架構設計時須要兼容不一樣的基礎環境。

3. 不一樣主體之間的協同

客戶的需求多樣化，咱們不能把全部的需求都知足和實現，須要和合做夥伴以及企業客戶一塊兒協同。在這個背景下，高可用的設計有着很大不一樣的視角。

挑戰一 ：高可用和成本

在介紹高可用和成本以前，首先要看看 ToB 的研發流程，咱們會把整個生命週期分紅兩個部分：

1. Global 層包括傳統的開發，測試和版本發佈流程。這裏的發佈不是互聯網產品的 Deploy，而是產品的 Release。
2. 其次，ToB 的 Deploy 和原有的模式有很大區別，體如今咱們要管理客戶很是多的環境，有不少 Local 的環境，如圖所示。

Global 作厚作實

在 ToB 的研發流程體系中，要保證產品高可用能力，客戶的現場不會出問題，咱們須要在 Global 作更多更厚實的工做：

1. 產品的變動准入強管控

• 全部產品的變化都須要架構評審，包括新產品的入駐和後續依賴變動，確保架構合理性；

• 代碼質量，自動化迴歸策略複用已有的能力，按照高要求嚴格執行。

2. 依賴管理

在對外輸出的場景下，內部產品研發流程有個很是關鍵的不一樣點，即在「交付環節」，咱們須要在客戶現場從 0 到 1 創建起來整套系統，而內部產品更可能是在已有系統上升級；要保證交付時系統拉起正常，咱們必須對系統各個組件的啓動依賴和運行依賴進行管理，按照依賴順序進行系統拉起；系統的依賴關係必須保證合理，不能有循環依賴。

3. 完備的驗證流程

除了自動化迴歸外，咱們須要在 Global 層進行交付驗證，高可用故障模擬驗證，容量規劃驗證等等，讓絕大部分的問題都在 Global 層暴露，簡化客戶環境執行的步驟，只須要部署並完成自動化迴歸驗證。

Local 快速反應

雖然在 Global 層作了不少工做，但不能保證客戶環境不出問題；對於客戶的環境，咱們把高可用能力建設從這幾個角度來建設：

1. 規避關鍵風險

雖然極端狀況出現機率不大，可是出現一次對咱們的信任影響很大；要保證極端狀況下的系統和數據恢復能力，機房級容災和數據備份管理是兩個最爲重要的產品能力，須要重點建設。

2. 快速識別風險

巡檢系統按期掃描可以提早識別風險；監控的覆蓋率須要持續建設，保證問題可以迅速暴露；出現異常後，故障定位模塊可以幫助快速定位問題；在 ToB 輸出領域，系統的架構和依賴相對穩定，故障定位比域內更加容易達到效果。

3. 快速恢復

變動的強管控把全部變動收斂，預案系統和故障場景結合，出現問題後，可以快速找到恢復方案，一鍵恢復。

4. 常態化的紅藍軍對抗演練

Local 的高可用能力要有機制驗證和保持：持續進行紅藍軍演練，保證工具和系統的能力。

高可用和成本

要考慮高可用的成本，首先咱們要對高可用能力進行量化，咱們從兩個不一樣維度來看：

• Local 站點的高可用能力（圖的右側）
• 產品的高可用能力（圖的左側）。

Local 站點高可用能力

Local 站點的能力經過變動管理，監控發現，容災能力，自愈能力，故障數據分析等多個因素來肯定高可用能力，給客戶設定不一樣的等級，從低層級到高等級之間演進的路徑是什麼，付出的成本有多少。

產品維度高可用能力

產品維度的高可用能力評估主要從 Global 研發流程出發進行不一樣維度的量化分析，目的是提供讓產品能力持續提高的量化指標。

以容災能力爲例，不一樣的容災架構能夠規避不一樣範圍的災難，但也須要付出不一樣的成本，咱們的客戶更可能是選擇同城雙活的架構，這個架構有比較好的性價比；

挑戰二 ： 兼容不一樣的基礎設施

開篇的時候咱們已提到，面對客戶不一樣的基礎設施，螞蟻在輸出金融科技能力的過程當中必需要認可的是，咱們很難充分知足不一樣的業務需求和場景挑戰。在這個背景下，咱們須要逐步建設開放的能力，把已有的技術能力向合做夥伴和客戶開放。

下圖以底座支撐移動開發平臺 mPaaS 輸出爲例，箭頭右側是客戶對整個技術棧的每一層的開放需求：

開放的路還須要繼續探索，咱們會按這幾個方面來推動：

1. 內部建設支撐核心功能的工程能力

好比咱們的產品核心功能支持 OpenStack 和 VMware，從研發，測試，交付，高可用，安全驗證全流程都須要有環境來保障，不一樣技術層的組合會有不少，這對工程能力是巨大的挑戰。

2. 統一標準

• 技術棧儘可能貼合開源，特別在各個產品的 API 方面。
• 擁抱雲原生，雲原生這個事實標準幫助技術快速傳播，同時也讓生態有了統一的概念和語言，加速了技術的應用和普及。

3. 賦能

• 系統和工具走開源路線
• 把咱們的核心能力和邊界定義清楚
• 提供核心能力的迴歸驗證工具
• 給合做方提供方便接入的驗證環境
• 經過賦能外部的合做夥伴或者客戶來共同建設，逐漸加強咱們內部的核心能力，造成正向的反饋。

挑戰三 ： 不一樣主體之間的協同

當咱們面向不一樣的合做夥伴，面向不一樣的客戶時，隨之而來的問題就是怎麼作協同？

不一樣企業的數字化成熟度不一樣，有些沒有 SRE 團隊，沒有應急響應機制，即便有，職能和保障機制不盡相同；面對這樣的環境，咱們必須創建成熟簡明的流程和機制，而且造成產品，讓合做夥伴或者客戶儘可能閉環，減小和咱們之間的「RPC通訊」，這須要對咱們的產品化能力有很高的要求。

1. 定義服務流程

對有不一樣需求的服務對象提供不一樣服務能力，明確不一樣服務能力的流程和實施路徑。

2. 服務中臺建設服務中臺主要從 4 個方面來提高服務能力，賦能合做夥伴和客戶有自主管理的能力：

• Local 的高可用能力產品
• 提高服務效率提高的工具
• 服務渠道的管理
• 服務流程的透明化

最後

總結一下，螞蟻在 ToB 的科技輸出時，高可用領域面臨有幾個挑戰：

1. 高可用能力的成本

咱們須要自身建設厚實的高可用能力，給客戶提供不一樣階段不一樣成本的高可用能力選項

2. 兼容不一樣的基礎設施

建設支撐核心能力的強大研發中臺，經過開放協同更多的資源來知足客戶的需求，再不斷反饋提高咱們的中臺能力

3. 如何處理好協同

定義好不一樣角色的協同流程，並造成系統和產品，賦能合做夥伴和客戶，提高自主管理能力

在「互聯網技術應用的 30年」，「產業互聯網」的大潮下，幫助企業作數字化轉型面臨很是不同的挑戰。很顯然，一套設計優異的系統架構每每不是一味追求前沿技術，而須要貼合實際業務場景和具體發展狀態，打造清晰、合理的架構，確保業務高可用的同時，又具有持續擴容、發展的彈性。因爲篇幅有限，今天咱們提出了部分問題並結合已有的實踐經驗進行總結，歡迎你們指正和交流，也歡迎你們一同來分享高可用架構演進的實戰經驗。

往期閱讀

《開篇 | 螞蟻金服 mPaaS 服務端核心組件體系概述》

《螞蟻金服 mPaaS 服務端核心組件：億級併發下的移動端到端網絡接入架構解析》

《mPaaS 核心組件：支付寶如何爲移動端產品構建輿情分析體系？》

《mPaaS 服務端核心組件：移動分析服務 MAS 架構解析》

《螞蟻金服面對億級併發場景的組件體系設計》

《自動化日誌收集及分析在支付寶 App 內的演進》

關注咱們公衆號，得到第一手 mPaaS 技術實踐乾貨

釘釘羣：經過釘釘搜索羣號「23124039」

期待你的加入～