MSHA x Chaos 容災高可用實踐

做者 | 遠跖、瀚闌
來源|阿里巴巴雲原生公衆號

前言

因爲外部環境的複雜以及硬件的不可靠，互聯網服務的高可用面臨着巨大的挑戰，因爲斷網、斷電等事故致使的各大互聯網公司服務不可用的案例也不在少數。業務不可用，小到帶來經濟損失影響企業口碑，大到微信、支付寶這些國民級應用，影響國計民生。面對難以免的天災人禍，容災架構的建設就成爲了數字化企業的迫切訴求。

2020 年 12 月份，阿里雲應用高可用產品 AHAS（Application High Availability Service）發佈了新的功能模塊 AHAS-MSHA，它是在阿⾥巴巴電商業務環境演進出來的多活容災架構解決⽅案。本篇文章咱們首先介紹容災領域的幾個重要概念，而後將結合一個的電商微服務案例，分享一下如何基於 AHAS 的異地多活能力（AHAS-MSHA）和混沌工程能力（AHAS-Chaos）幫助業務實現容災架構的高可用實踐。

容災與評價指標

1. 什麼是容災？

容災（Disaster Tolerance）是指在相隔較遠的異地，創建兩套或多套功能相同的系統，系統之間能夠相互進行健康狀態監視和功能切換，當一處系統因意外（如火災、洪水、地震、人爲蓄意破壞等）中止工做時，整個應用系統能夠切換到另外一處，使得該系統功能能夠繼續正常工做。

2. 容災能力如何評估？

容災系統主要爲了在災難發生時業務不發生中斷，那麼容災能力如何評估和量化呢？這裏須要介紹一下業界一般採用的容災能力評價指標：

• RPO（Recovery Point Objective）

即數據恢復點目標，以時間爲單位，即在災難發生時，系統和數據必須恢復的時間點要求。RPO 標誌系統可以容忍的最大數據丟失量，系統容忍丟失的數據量越小，RPO 的值越小。

• RTO（Recovery Time Objective）

即恢復時間目標，以時間爲單位，即在災難發生後，信息系統或業務功能從中止到必須恢復的時間要求。RTO 標誌系統可以容忍的服務中止的最長時間，系統服務的緊迫性要求越高，RTO 的值越小。

AHAS-MSHA

1. 介紹

MSHA（Multi-Site High Availability）是一個多活容災架構解決⽅案（解決方案=技術產品+諮詢服務+生態夥伴），能夠將業務恢復和故障恢復解耦，支持故障場景下業務的快速恢復，助⼒企業的容災穩定性建設。

1）產品架構

MSHA 採用異地多活的容災架構，核心思想是 「隔離的冗餘」，咱們將各個冗餘的邏輯數據中心稱爲單元，MSHA 作到了業務流量在單元內封閉，單元之間隔離，把故障爆炸半徑控制在一個單元內，不只能解決容災問題，提高業務連續性，而且能實現容量的擴展。

2）主流容災架構對比

2. 功能特性

• 故障快速恢復

秉承先恢復，再定位的原則，MSHA 提供了容災切流能力，在數據保護的前提下讓業務恢復時間和故障恢復時間解耦合，保障業務連續性。

• 容量異地擴展

業務⾼速發展，受限於單地有限資源，也存在數據庫瓶頸等問題。使用 MSHA 能夠在其它地域、機房快速擴建業務單元，實現快速水平擴容的目的。

• 流量分配與糾錯

MSHA 提供了從接入層到應用層的層層流量糾錯和校驗，將不符合流量路由規則的調用從新轉發，將故障爆炸半徑可控制在一個單元內。

• 數據防髒寫

多單元寫數據可能形成髒寫覆蓋的問題，MSHA 提供流量打入錯誤單元時的禁寫保護，以及切流數據同步延時期間的禁寫/禁更新保護。

3. 應用場景

MSHA 可適用於如下典型業務場景的多活容災架構建設：

• 讀多寫少型業務

  • 業務場景：典型的業務場景就是資訊、導購類服務（如商品瀏覽、新聞資訊）。
  • 數據特色：讀多寫少型業務，核心是讀業務，可以接受寫業務的暫時不可用。
• 流水單據型業務
  • 業務場景：典型的業務場景就是電商交易、帳單流水類服務（如訂單、通話記錄等）。
  • 數據特色：數據能夠按必定的維度進行分片且能接受數據的最終一致。

業務容災實踐

下面咱們經過一個電商微服務案例，來介紹不一樣場景的容災架構建設案例。

1. 電商業務背景

1）業務應用

• frontend，入口 WEB 應用，負責和用戶交互
• cartservice，購物車應用。記錄用戶的購物車數據，使用自建的 Redis
• productservice，商品應用。提供商品、庫存服務，使用 RDS MySQL
• checkoutservice，下單應用。將購物車中的商品生成購買訂單，使用 RDS MySQL

2）技術棧

• SpringBoot
• RPC 框架：SpringCloud，註冊中心使用自建的 Eureka

3）電商應用架構 1.0

電商業務初期，跟不少互聯網企業同樣，沒有考慮容災問題，只在單地域進行了部署。

2. 案例一：讀多寫少型業務容災案例

1）一次故障的發生

電商業務初期發展迅速，小而美的單地域部署方式也一直沒有變化，直到一次商品應用故障的發生，致使電商業務癱瘓，頁面長時間沒法訪問。故障最終得以解決，但故障致使的客戶流失和企業口碑影響，對快速發展的業務形成不小的打擊，迫使咱們開始考慮高可用能力的建設。

電商業務主要分爲導購、購物車、交易等業務場景，首當其衝的就是導購。它是典型的讀多寫少型業務場景，核心是導購頁面的展現（讀鏈路），一般能夠接受發佈、上架商品服務的暫時不可用（寫鏈路）。結合自身容災訴求，咱們先定下一個改進的小目標--「異地多讀」。

2）異地多讀容災架構改造

基於 MSHA 將導購業務改造爲「異地多讀」。

多活改造 & MSHA 接入：

• 分區維度：使用 userId 來做分流標識。

• 改造範圍：將導購鏈路相關的入口 WEB 應用 、 商品應用 進行兩地域部署。

• 管控配置：進入 MSHA 控制檯進行各層多活資源的配置。

3）故障復現

容災架構改造完成後，並無結束，還需驗證容災能力是否符合預期。接下來咱們將歷史故障進行復現，經過製造真實的故障來驗證容災恢復能力。

【演練準備】

業務監控指標：基於 MSHA 流量監控或其餘監控能力，肯定業務穩態監控指標，以便在故障發生時判斷故障影響面以及在故障恢復後判斷業務的實際恢復狀況。

演練預期：

• 導購鏈路對購物車應用是弱依賴（導購頁會展現用戶放入購物車的商品數量），弱依賴故障不影響業務。

• 導購鏈路對商品應用是強依賴，強依賴故障將致使業務不可用，故障的爆炸半徑應該控制在單元內。

【故障演練】

利用 AHAS-Chaos 故障演練功能，可以方便的進行多種故障場景的演練。

第一階段：弱依賴故障演練

• 故障注入：對購物車應用進行故障注入
  • 預期：導購業務不受影響
  • 結果：導購頁能正常打開，符合預期

第二階段：強依賴故障演練

演練前配置的路由規則以下（userId%10000 後根據以下路由範圍規則進行匹配）：

• 故障注入：對北京單元的商品應用進行故障注入
  • 預期：userId=6000 的用戶路由到北京單元，會受故障的影響
  • 結果：導購頁訪問異常，符合預期

• 爆炸半徑驗證：驗證保障半徑是否控制在故障單元內
  • 預期：userId=50 的用戶路由到杭州單元，不受北京單元故障的影響
  • 結果：導購頁訪問正常，符合預期

4）切流恢復

故障場景下，使用 MSHA 切流功能，驗證容災恢復能力。

• 容災切換驗證：將 userId=6000 切流到杭州單元
  • 預期：切流後該用戶將路由到杭州單元，不受北京單元故障的影響。
  • 結果：導購頁訪問正常（導購請求的實際調用鏈參見下面動圖），容災恢復能力符合預期。

後續：故障撤銷

• 故障注入終止
• 演練結果反饋，記錄演練識別到的風險問題
• 流量回切
• 查看穩態業務指標是否恢復

3. 案例二：流水單據型業務容災案例

1）新的故障

通過上述的改造，導購業務已經具有抵禦地域級故障的能力。而訂單應用大面積故障，成爲了壓死訂單業務的最後一根稻草。因而，下單業務的高可用架構建設，也提上了議程。

下單是典型的流水單據型業務場景，相比導購，是更爲複雜的讀寫結合業務，結合業務場景和業務容災訴求，咱們選取了適合業務的容災建設方案--「異地多活」。

2）異地多活容災架構改造

基於 MSHA 將訂單業務改造爲「異地多活」。

注：下單鏈路強依賴購物車應用，完整的多活容災建設，後續還應將購物車應用也改造爲「異地多活」。

多活改造 & MSHA 接入：

• 改造範圍：下單應用和訂單數據庫進行兩地域部署。

• MSHA 接入：將下單鏈路的應用安裝上 Agent，從而無侵入的實現 SpringCloud RPC 跨單元路由功能和數據防髒寫功能。

• 管控配置：

3）故障復現

容災架構改造完成後，接下來咱們將歷史故障進行復現，經過製造真實的故障來驗證容災恢復能力。

【演練準備】

業務監控指標：基於 MSHA 流量監控或其餘監控能力，肯定業務穩態監控指標。

演練預期：下單鏈路對訂單應用是強依賴，強依賴故障影響業務不可用，且故障爆炸半徑控制在單元內。

【故障演練】

演練前配置的路由規則以下（userId%10000 後根據以下路由範圍規則進行匹配）：

• 故障注入：對北京單元的訂單應用進行故障注入
  • 預期：userId=6000 的用戶路由到北京單元，會受到故障影響
  • 結果：下單異常，符合預期

• 爆炸半徑驗證：驗證保障半徑是否控制在故障單元內
  • 預期：userId=50的用戶路由到杭州單元，不受北京單元故障的影響
  • 結果：下單正常，符合預期

4）切流恢復

使用 MSHA 切流功能，驗證故障場景下的容災切換能力。

• 容災切換驗證：將 userId=6000 切流到杭州單元
  • 預期：切流後該用戶將路由到杭州單元，不受北京單元故障的影響
  • 結果：下單正常（下單請求的實際調用鏈參見下面動圖），容災恢復能力符合預期。

總結

在本篇文章中，咱們介紹了 AHAS 爲業務容災提供的一大利器：MSHA 多活容災解決方案，並結合一個電商業務，介紹了讀多寫少型和流水單據型 2 個典型業務場景下的容災建設案例，給出容災架構建設實踐方法，同時結合 AHAS-Chaos 故障演練功能模擬一次真實可能發生的故障，驗證容災能力是否符合預期。

公有云 MSHA 已經開始公測，並已提供文中 2 個業務場景的電商業務 Demo 體驗（無需開通便可體驗），歡迎你們申請體驗。

最後想跟你們說的是，容災建設是一個系統工程，不能一蹴而就也不是一錘子買賣，須要根據業務場景、容災訴求、技術棧、容災預算等綜合來評估和制定合適的容災架構建設方案，歡迎你們針對自身的容災訴求和場景進行諮詢和交流。

延伸閱讀

• AHAS-MSHA 多活容災解決方案官方文檔：https://help.aliyun.com/document_detail/181717.html

• AHAS-Chaos 故障演練官方文檔：https://help.aliyun.com/document_detail/90327.html

• 電商業務多活實踐：https://help.aliyun.com/document_detail/184984.html

• 強弱依賴治理&故障演練最佳實踐：https://help.aliyun.com/document_detail/185932.html