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 可适用于以下典型業務場景的多活容災架建構設：
1）讀多寫少型業務
- 業務場景：典型的業務場景就是資訊、導購類服務（如商品浏覽、新聞資訊）。
- 資料特點：讀多寫少型業務，核心是讀業務，能夠接受寫業務的暫時不可用。
2）流水單據型業務
- 業務場景：典型的業務場景就是電商交易、賬單流水類服務（如訂單、通話記錄等）。
- 資料特點：資料可以按一定的次元進行分片且能接受資料的最終一緻。
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 控制台進行各層多活資源的配置。
4.2.3 故障複現
容災架構改造完成後，并沒有結束，還需驗證容災能力是否符合預期。接下來我們将曆史故障進行複現，通過制造真實的故障來驗證容災恢複能力。
1.演練準備
業務監控名額：基于 MSHA 流量監控或其他監控能力，确定業務穩态監控名額，以便在故障發生時判斷故障影響面以及在故障恢複後判斷業務的實際恢複情況。
演練預期：
導購鍊路對購物車應用是弱依賴（導購頁會展示使用者放入購物車的商品數量），弱依賴故障不影響業務。
導購鍊路對商品應用是強依賴，強依賴故障将導緻業務不可用，故障的爆炸半徑應該控制在單元内。
2.故障演練
利用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 跨單元路由功能和資料防髒寫功能。
- 管控配置：
4.3.3 故障複現
容災架構改造完成後，接下來我們将曆史故障進行複現，通過制造真實的故障來驗證容災恢複能力
- 業務監控名額：基于 MSHA 流量監控或其他監控能力，确定業務穩态監控名額。
- 演練預期：下單鍊路對訂單應用是強依賴，強依賴故障影響業務不可用，且故障爆炸半徑控制在單元内。
-
故障注入：對北京單元的訂單應用進行故障注入
預期：userId=6000 的使用者路由到北京單元，會受到故障影響
結果：下單異常，符合預期
-
預期：userId=50的使用者路由到杭州單元，不受北京單元故障的影響
結果：下單正常，符合預期
4.3.4 切流恢複
使用 MSHA 切流功能，驗證故障場景下的容災切換能力。
-
預期：切流後該使用者将路由到杭州單元，不受北京單元故障的影響
結果：下單正常（下單請求的實際調用鍊參見下面動圖），容災恢複能力符合預期。
5. 總結
在本篇文章中，我們介紹了 AHAS 為業務容災提供的一大利器：MSHA 多活容災解決方案，并結合一個電商業務，介紹了讀多寫少型和流水單據型2個典型業務場景下的容災建設案例，給出容災架建構設實踐方法，同時結合 AHAS-Chaos 故障演練功能模拟一次真實可能發生的故障，驗證容災能力是否符合預期。
最後想跟大家說的是，容災建設是一個系統工程，不能一蹴而就也不是一錘子買賣，需要根據業務場景、容災訴求、技術棧、容災預算等綜合來評估和制定合适的容災架建構設方案，歡迎大家針對自身的容災訴求和場景進行咨詢和交流。
我們是阿裡雲智能全球技術服務-SRE團隊，我們緻力成為一個以技術為基礎、面向服務、保障業務系統高可用的工程師團隊；提供專業、體系化的SRE服務，幫助廣大客戶更好地使用雲、基于雲建構更加穩定可靠的業務系統，提升業務穩定性。我們期望能夠分享更多幫助企業客戶上雲、用好雲，讓客戶雲上業務運作更加穩定可靠的技術，您可用釘釘掃描下方二維碼，加入阿裡雲SRE技術學院釘釘圈子，和更多雲上人交流關于雲平台的那些事。