MSHA x Chaos 容災高可用實踐—高可用

1. 前言

由於外部環境的複雜以及硬件的不可靠，互聯網服務的高可用面臨著巨大的挑戰，由於斷網、斷電等事故導致的各大互聯網公司服務不可用的案例也不在少數。業務不可用，小到帶來經濟損失影響企業口碑，大到微信、支付寶這些國民級應用，影響國計民生。面對難以避免的天災人禍，容災架構的建設就成為了數字化企業的迫切訴求。
2020 年 12 月份，阿里雲應用高可用產品 AHAS（Application High Availability Service）發佈了新的功能模塊 AHAS-MSHA，它是在阿⾥巴巴電商業務環境演進出來的多活容災架構解決⽅案。本篇文章我們首先介紹容災領域的幾個重要概念，然後將結合一個的電商微服務案例，分享一下如何基於 AHAS 的異地多活能力（AHAS-MSHA）和混沌工程能力（AHAS-Chaos）幫助業務實現容災架構的高可用實踐。

2. 容災與評價指標

2.1 什麼是容災

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

2.2 容災能力如何評估

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

RPO（Recovery Point Objective）

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

RTO（Recovery Time Objective）

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

3. AHAS-MSHA

3.1 介紹

MSHA（Multi-Site High Availability）是一個多活容災架構解決⽅案（解決方案=技術產品+諮詢服務+生態夥伴），可以將業務恢復和故障恢復解耦，支持故障場景下業務的快速恢復，助⼒企業的容災穩定性建設。
1）產品架構
MSHA 採用異地多活的容災架構，核心思想是 “隔離的冗餘”，我們將各個冗餘的邏輯數據中心稱為單元，MSHA 做到了業務流量在單元內封閉，單元之間隔離，把故障爆炸半徑控制在一個單元內，不僅能解決容災問題，提升業務連續性，並且能實現容量的擴展。

2）主流容災架構對比

3.2 功能特性

1.故障快速恢復
秉承先恢復，再定位的原則，MSHA 提供了容災切流能力，在數據保護的前提下讓業務恢復時間和故障恢復時間解耦合，保障業務連續性。
2.容量異地擴展
業務⾼速發展，受限於單地有限資源，也存在數據庫瓶頸等問題。使用 MSHA 可以在其它地域、機房快速擴建業務單元，實現快速水平擴容的目的。
3.流量分配與糾錯
MSHA 提供了從接入層到應用層的層層流量糾錯和校驗，將不符合流量路由規則的調用重新轉發，將故障爆炸半徑可控制在一個單元內。
4.數據防髒寫
多單元寫數據可能造成髒寫覆蓋的問題，MSHA 提供流量打入錯誤單元時的禁寫保護，以及切流數據同步延時期間的禁寫/禁更新保護。

3.3 應用場景

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

讀多寫少型業務
- 業務場景：典型的業務場景就是資訊、導購類服務（如商品瀏覽、新聞資訊）。

數據特點：讀多寫少型業務，核心是讀業務，能夠接受寫業務的暫時不可用。

流水單據型業務
- 業務場景：典型的業務場景就是電商交易、賬單流水類服務（如訂單、通話記錄等）。

數據特點：數據可以按一定的維度進行分片且能接受數據的最終一致。

4. 業務容災實踐

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

4.1 電商業務背景

1）業務應用

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

2）技術棧

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

3）電商應用架構 1.0
電商業務初期，跟很多互聯網企業一樣，沒有考慮容災問題，只在單地域進行了部署。

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

4.2.1 一次故障的發生

電商業務初期發展迅速，小而美的單地域部署方式也一直沒有變化，直到一次商品應用故障的發生，導致電商業務癱瘓，頁面長時間無法訪問。故障最終得以解決，但故障導致的客戶流失和企業口碑影響，對快速發展的業務造成不小的打擊，迫使我們開始考慮高可用能力的建設。
電商業務主要分為導購、購物車、交易等業務場景，首當其衝的就是導購。它是典型的讀多寫少型業務場景，核心是導購頁面的展示（讀鏈路），通常可以接受發佈、上架商品服務的暫時不可用（寫鏈路）。結合自身容災訴求，我們先定下一個改進的小目標--“異地多讀”。

4.2.2 異地多讀容災架構改造

基於 MSHA 將導購業務改造為“異地多讀”。
多活改造 & MSHA 接入：

分區維度：使用 userId 來作分流標識。
改造範圍：將導購鏈路相關的入口 WEB 應用、商品應用進行兩地域部署。
管控配置：進入 MSHA 控制檯進行各層多活資源的配置。

3）

4.2.3 故障復現

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

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

演練預期：
導購鏈路對購物車應用是弱依賴（導購頁會展示用戶放入購物車的商品數量），弱依賴故障不影響業務。
導購鏈路對商品應用是強依賴，強依賴故障將導致業務不可用，故障的爆炸半徑應該控制在單元內。

故障演練
利用AHAS-Chaos 故障演練功能，能夠方便的進行多種故障場景的演練。
a）第一階段弱依賴故障演練
- 故障注入：對購物車應用進行故障注入

預期：導購業務不受影響
結果：導購頁能正常打開，符合預期

b）第二階段：強依賴故障演練
演練前配置的路由規則如下（userId%10000 後根據如下路由範圍規則進行匹配）：

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

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

4.2.4 切流恢復

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

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

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

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

4.3.1 新的故障

經過上述的改造，導購業務已經具備抵禦地域級故障的能力。而訂單應用大面積故障，成為了壓死訂單業務的最後一根稻草。於是，下單業務的高可用架構建設，也提上了議程。
下單是典型的流水單據型業務場景，相比導購，是更為複雜的讀寫結合業務，結合業務場景和業務容災訴求，我們選取了適合業務的容災建設方案--“異地多活”。

4.3.2 異地多活容災架構改造

基於 MSHA 將訂單業務改造為“異地多活”。
注：下單鏈路強依賴購物車應用，完整的多活容災建設，後續還應將購物車應用也改造為“異地多活”。

多活改造&MSHA接入：
改造範圍：下單應用和訂單數據庫進行兩地域部署。
MSHA 接入：將下單鏈路的應用安裝上 Agent，從而無侵入的實現 SpringCloud RPC 跨單元路由功能和數據防髒寫功能。
管控配置：

3）

4.3.3 故障復現

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

演練準備
- 業務監控指標：基於 MSHA 流量監控或其他監控能力，確定業務穩態監控指標。

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

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

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

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

4.3.4 切流恢復

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

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

5. 總結

在本篇文章中，我們介紹了 AHAS 為業務容災提供的一大利器：MSHA 多活容災解決方案，並結合一個電商業務，介紹了讀多寫少型和流水單據型 2 個典型業務場景下的容災建設案例，給出容災架構建設實踐方法，同時結合 AHAS-Chaos 故障演練功能模擬一次真實可能發生的故障，驗證容災能力是否符合預期。
最後想跟大家說的是，容災建設是一個系統工程，不能一蹴而就也不是一錘子買賣，需要根據業務場景、容災訴求、技術棧、容災預算等綜合來評估和制定合適的容災架構建設方案，歡迎大家針對自身的容災訴求和場景進行諮詢和交流。