作者 |?遠(yuǎn)跖、瀚闌
來源|阿里巴巴云原生公眾號(hào)

前言

由于外部環(huán)境的復(fù)雜以及硬件的不可靠，互聯(lián)網(wǎng)服務(wù)的高可用面臨著巨大的挑戰(zhàn)，由于斷網(wǎng)、斷電等事故導(dǎo)致的各大互聯(lián)網(wǎng)公司服務(wù)不可用的案例也不在少數(shù)。業(yè)務(wù)不可用，小到帶來經(jīng)濟(jì)損失影響企業(yè)口碑，大到微信、支付寶這些國民級(jí)應(yīng)用，影響國計(jì)民生。面對(duì)難以避免的天災(zāi)人禍，容災(zāi)架構(gòu)的建設(shè)就成為了數(shù)字化企業(yè)的迫切訴求。

2020 年 12 月份，阿里云應(yīng)用高可用產(chǎn)品 AHAS（Application High Availability Service）發(fā)布了新的功能模塊 AHAS-MSHA，它是在阿?巴巴電商業(yè)務(wù)環(huán)境演進(jìn)出來的多活容災(zāi)架構(gòu)解決?案。本篇文章我們首先介紹容災(zāi)領(lǐng)域的幾個(gè)重要概念，然后將結(jié)合一個(gè)的電商微服務(wù)案例，分享一下如何基于 AHAS 的異地多活能力（AHAS-MSHA）和混沌工程能力（AHAS-Chaos）幫助業(yè)務(wù)實(shí)現(xiàn)容災(zāi)架構(gòu)的高可用實(shí)踐。

容災(zāi)與評(píng)價(jià)指標(biāo)

1. 什么是容災(zāi)？

容災(zāi)（Disaster Tolerance）是指在相隔較遠(yuǎn)的異地，建立兩套或多套功能相同的系統(tǒng)，系統(tǒng)之間可以相互進(jìn)行健康狀態(tài)監(jiān)視和功能切換，當(dāng)一處系統(tǒng)因意外（如火災(zāi)、洪水、地震、人為蓄意破壞等）停止工作時(shí)，整個(gè)應(yīng)用系統(tǒng)可以切換到另一處，使得該系統(tǒng)功能可以繼續(xù)正常工作。

2. 容災(zāi)能力如何評(píng)估？

容災(zāi)系統(tǒng)主要為了在災(zāi)難發(fā)生時(shí)業(yè)務(wù)不發(fā)生中斷，那么容災(zāi)能力如何評(píng)估和量化呢？這里需要介紹一下業(yè)界通常采用的容災(zāi)能力評(píng)價(jià)指標(biāo)：

• RPO（Recovery Point Objective）

即數(shù)據(jù)恢復(fù)點(diǎn)目標(biāo)，以時(shí)間為單位，即在災(zāi)難發(fā)生時(shí)，系統(tǒng)和數(shù)據(jù)必須恢復(fù)的時(shí)間點(diǎn)要求。RPO 標(biāo)志系統(tǒng)能夠容忍的最大數(shù)據(jù)丟失量，系統(tǒng)容忍丟失的數(shù)據(jù)量越小，RPO 的值越小。

• RTO（Recovery Time Objective）

即恢復(fù)時(shí)間目標(biāo)，以時(shí)間為單位，即在災(zāi)難發(fā)生后，信息系統(tǒng)或業(yè)務(wù)功能從停止到必須恢復(fù)的時(shí)間要求。RTO 標(biāo)志系統(tǒng)能夠容忍的服務(wù)停止的最長時(shí)間，系統(tǒng)服務(wù)的緊迫性要求越高，RTO 的值越小。

AHAS-MSHA

1. 介紹

MSHA（Multi-Site High Availability）是一個(gè)多活容災(zāi)架構(gòu)解決?案（解決方案=技術(shù)產(chǎn)品+咨詢服務(wù)+生態(tài)伙伴），可以將業(yè)務(wù)恢復(fù)和故障恢復(fù)解耦，支持故障場景下業(yè)務(wù)的快速恢復(fù)，助?企業(yè)的容災(zāi)穩(wěn)定性建設(shè)。

1）產(chǎn)品架構(gòu)

MSHA 采用異地多活的容災(zāi)架構(gòu)，核心思想是 “隔離的冗余”，我們將各個(gè)冗余的邏輯數(shù)據(jù)中心稱為單元，MSHA 做到了業(yè)務(wù)流量在單元內(nèi)封閉，單元之間隔離，把故障爆炸半徑控制在一個(gè)單元內(nèi)，不僅能解決容災(zāi)問題，提升業(yè)務(wù)連續(xù)性，并且能實(shí)現(xiàn)容量的擴(kuò)展。

2）主流容災(zāi)架構(gòu)對(duì)比

2. 功能特性

• 故障快速恢復(fù)

秉承先恢復(fù)，再定位的原則，MSHA 提供了容災(zāi)切流能力，在數(shù)據(jù)保護(hù)的前提下讓業(yè)務(wù)恢復(fù)時(shí)間和故障恢復(fù)時(shí)間解耦合，保障業(yè)務(wù)連續(xù)性。

• 容量異地?cái)U(kuò)展

業(yè)務(wù)?速發(fā)展，受限于單地有限資源，也存在數(shù)據(jù)庫瓶頸等問題。使用 MSHA 可以在其它地域、機(jī)房快速擴(kuò)建業(yè)務(wù)單元，實(shí)現(xiàn)快速水平擴(kuò)容的目的。

• 流量分配與糾錯(cuò)

MSHA 提供了從接入層到應(yīng)用層的層層流量糾錯(cuò)和校驗(yàn)，將不符合流量路由規(guī)則的調(diào)用重新轉(zhuǎn)發(fā)，將故障爆炸半徑可控制在一個(gè)單元內(nèi)。

• 數(shù)據(jù)防臟寫

多單元寫數(shù)據(jù)可能造成臟寫覆蓋的問題，MSHA 提供流量打入錯(cuò)誤單元時(shí)的禁寫保護(hù)，以及切流數(shù)據(jù)同步延時(shí)期間的禁寫/禁更新保護(hù)。

3. 應(yīng)用場景

MSHA 可適用于以下典型業(yè)務(wù)場景的多活容災(zāi)架構(gòu)建設(shè)：

• 讀多寫少型業(yè)務(wù)

  • 業(yè)務(wù)場景：典型的業(yè)務(wù)場景就是資訊、導(dǎo)購類服務(wù)（如商品瀏覽、新聞資訊）。
  • 數(shù)據(jù)特點(diǎn)：讀多寫少型業(yè)務(wù)，核心是讀業(yè)務(wù)，能夠接受寫業(yè)務(wù)的暫時(shí)不可用。

• 流水單據(jù)型業(yè)務(wù)

  • 業(yè)務(wù)場景：典型的業(yè)務(wù)場景就是電商交易、賬單流水類服務(wù)（如訂單、通話記錄等）。
  • 數(shù)據(jù)特點(diǎn)：數(shù)據(jù)可以按一定的維度進(jìn)行分片且能接受數(shù)據(jù)的最終一致。

業(yè)務(wù)容災(zāi)實(shí)踐

下面我們通過一個(gè)電商微服務(wù)案例，來介紹不同場景的容災(zāi)架構(gòu)建設(shè)案例。

1. 電商業(yè)務(wù)背景

1）業(yè)務(wù)應(yīng)用

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

2）技術(shù)棧

• SpringBoot
• RPC 框架：SpringCloud，注冊(cè)中心使用自建的 Eureka

3）電商應(yīng)用架構(gòu) 1.0

電商業(yè)務(wù)初期，跟很多互聯(lián)網(wǎng)企業(yè)一樣，沒有考慮容災(zāi)問題，只在單地域進(jìn)行了部署。

2. 案例一：讀多寫少型業(yè)務(wù)容災(zāi)案例

1）一次故障的發(fā)生

電商業(yè)務(wù)初期發(fā)展迅速，小而美的單地域部署方式也一直沒有變化，直到一次商品應(yīng)用故障的發(fā)生，導(dǎo)致電商業(yè)務(wù)癱瘓，頁面長時(shí)間無法訪問。故障最終得以解決，但故障導(dǎo)致的客戶流失和企業(yè)口碑影響，對(duì)快速發(fā)展的業(yè)務(wù)造成不小的打擊，迫使我們開始考慮高可用能力的建設(shè)。

電商業(yè)務(wù)主要分為導(dǎo)購、購物車、交易等業(yè)務(wù)場景，首當(dāng)其沖的就是導(dǎo)購。它是典型的讀多寫少型業(yè)務(wù)場景，核心是導(dǎo)購頁面的展示（讀鏈路），通常可以接受發(fā)布、上架商品服務(wù)的暫時(shí)不可用（寫鏈路）。結(jié)合自身容災(zāi)訴求，我們先定下一個(gè)改進(jìn)的小目標(biāo)–“異地多讀”。

2）異地多讀容災(zāi)架構(gòu)改造

基于 MSHA 將導(dǎo)購業(yè)務(wù)改造為“異地多讀”。

多活改造 & MSHA 接入：

• 分區(qū)維度：使用 userId 來作分流標(biāo)識(shí)。

• 改造范圍：將導(dǎo)購鏈路相關(guān)的入口 WEB 應(yīng)用 、 商品應(yīng)用 進(jìn)行兩地域部署。

• 管控配置：進(jìn)入 MSHA 控制臺(tái)進(jìn)行各層多活資源的配置。

3）故障復(fù)現(xiàn)

容災(zāi)架構(gòu)改造完成后，并沒有結(jié)束，還需驗(yàn)證容災(zāi)能力是否符合預(yù)期。接下來我們將歷史故障進(jìn)行復(fù)現(xiàn)，通過制造真實(shí)的故障來驗(yàn)證容災(zāi)恢復(fù)能力。

【演練準(zhǔn)備】

業(yè)務(wù)監(jiān)控指標(biāo)：基于 MSHA 流量監(jiān)控或其他監(jiān)控能力，確定業(yè)務(wù)穩(wěn)態(tài)監(jiān)控指標(biāo)，以便在故障發(fā)生時(shí)判斷故障影響面以及在故障恢復(fù)后判斷業(yè)務(wù)的實(shí)際恢復(fù)情況。

演練預(yù)期：

• 導(dǎo)購鏈路對(duì)購物車應(yīng)用是弱依賴（導(dǎo)購頁會(huì)展示用戶放入購物車的商品數(shù)量），弱依賴故障不影響業(yè)務(wù)。

• 導(dǎo)購鏈路對(duì)商品應(yīng)用是強(qiáng)依賴，強(qiáng)依賴故障將導(dǎo)致業(yè)務(wù)不可用，故障的爆炸半徑應(yīng)該控制在單元內(nèi)。

【故障演練】

利用 AHAS-Chaos 故障演練功能，能夠方便的進(jìn)行多種故障場景的演練。

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

• 故障注入：對(duì)購物車應(yīng)用進(jìn)行故障注入
  • 預(yù)期：導(dǎo)購業(yè)務(wù)不受影響
  • 結(jié)果：導(dǎo)購頁能正常打開，符合預(yù)期

第二階段：強(qiáng)依賴故障演練

演練前配置的路由規(guī)則如下（userId%10000 后根據(jù)如下路由范圍規(guī)則進(jìn)行匹配）：

• 故障注入：對(duì)北京單元的商品應(yīng)用進(jìn)行故障注入
  • 預(yù)期：userId=6000 的用戶路由到北京單元，會(huì)受故障的影響
  • 結(jié)果：導(dǎo)購頁訪問異常，符合預(yù)期

• 爆炸半徑驗(yàn)證：驗(yàn)證保障半徑是否控制在故障單元內(nèi)
  • 預(yù)期：userId=50 的用戶路由到杭州單元，不受北京單元故障的影響
  • 結(jié)果：導(dǎo)購頁訪問正常，符合預(yù)期

4）切流恢復(fù)

故障場景下，使用 MSHA 切流功能，驗(yàn)證容災(zāi)恢復(fù)能力。

• 容災(zāi)切換驗(yàn)證：將 userId=6000 切流到杭州單元
  • 預(yù)期：切流后該用戶將路由到杭州單元，不受北京單元故障的影響。
  • 結(jié)果：導(dǎo)購頁訪問正常（導(dǎo)購請(qǐng)求的實(shí)際調(diào)用鏈參見下面動(dòng)圖），容災(zāi)恢復(fù)能力符合預(yù)期。

后續(xù)：故障撤銷

• 故障注入終止
• 演練結(jié)果反饋，記錄演練識(shí)別到的風(fēng)險(xiǎn)問題
• 流量回切
• 查看穩(wěn)態(tài)業(yè)務(wù)指標(biāo)是否恢復(fù)

3. 案例二：流水單據(jù)型業(yè)務(wù)容災(zāi)案例

1）新的故障

經(jīng)過上述的改造，導(dǎo)購業(yè)務(wù)已經(jīng)具備抵御地域級(jí)故障的能力。而訂單應(yīng)用大面積故障，成為了壓死訂單業(yè)務(wù)的最后一根稻草。于是，下單業(yè)務(wù)的高可用架構(gòu)建設(shè)，也提上了議程。

下單是典型的流水單據(jù)型業(yè)務(wù)場景，相比導(dǎo)購，是更為復(fù)雜的讀寫結(jié)合業(yè)務(wù)，結(jié)合業(yè)務(wù)場景和業(yè)務(wù)容災(zāi)訴求，我們選取了適合業(yè)務(wù)的容災(zāi)建設(shè)方案–“異地多活”。

2）異地多活容災(zāi)架構(gòu)改造

基于 MSHA 將訂單業(yè)務(wù)改造為“異地多活”。

注：下單鏈路強(qiáng)依賴購物車應(yīng)用，完整的多活容災(zāi)建設(shè)，后續(xù)還應(yīng)將購物車應(yīng)用也改造為“異地多活”。

多活改造 & MSHA 接入：

• 改造范圍：下單應(yīng)用和訂單數(shù)據(jù)庫進(jìn)行兩地域部署。

• MSHA 接入：將下單鏈路的應(yīng)用安裝上 Agent，從而無侵入的實(shí)現(xiàn) SpringCloud RPC 跨單元路由功能和數(shù)據(jù)防臟寫功能。

• 管控配置：

3）故障復(fù)現(xiàn)

容災(zāi)架構(gòu)改造完成后，接下來我們將歷史故障進(jìn)行復(fù)現(xiàn)，通過制造真實(shí)的故障來驗(yàn)證容災(zāi)恢復(fù)能力。

【演練準(zhǔn)備】

業(yè)務(wù)監(jiān)控指標(biāo)：基于 MSHA 流量監(jiān)控或其他監(jiān)控能力，確定業(yè)務(wù)穩(wěn)態(tài)監(jiān)控指標(biāo)。

演練預(yù)期：下單鏈路對(duì)訂單應(yīng)用是強(qiáng)依賴，強(qiáng)依賴故障影響業(yè)務(wù)不可用，且故障爆炸半徑控制在單元內(nèi)。

【故障演練】

演練前配置的路由規(guī)則如下（userId%10000 后根據(jù)如下路由范圍規(guī)則進(jìn)行匹配）：

• 故障注入：對(duì)北京單元的訂單應(yīng)用進(jìn)行故障注入
  • 預(yù)期：userId=6000 的用戶路由到北京單元，會(huì)受到故障影響
  • 結(jié)果：下單異常，符合預(yù)期

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

4）切流恢復(fù)

使用 MSHA 切流功能，驗(yàn)證故障場景下的容災(zāi)切換能力。

• 容災(zāi)切換驗(yàn)證：將 userId=6000 切流到杭州單元
  • 預(yù)期：切流后該用戶將路由到杭州單元，不受北京單元故障的影響
  • 結(jié)果：下單正常（下單請(qǐng)求的實(shí)際調(diào)用鏈參見下面動(dòng)圖），容災(zāi)恢復(fù)能力符合預(yù)期。

總結(jié)

在本篇文章中，我們介紹了 AHAS 為業(yè)務(wù)容災(zāi)提供的一大利器：MSHA 多活容災(zāi)解決方案，并結(jié)合一個(gè)電商業(yè)務(wù)，介紹了讀多寫少型和流水單據(jù)型 2 個(gè)典型業(yè)務(wù)場景下的容災(zāi)建設(shè)案例，給出容災(zāi)架構(gòu)建設(shè)實(shí)踐方法，同時(shí)結(jié)合 AHAS-Chaos 故障演練功能模擬一次真實(shí)可能發(fā)生的故障，驗(yàn)證容災(zāi)能力是否符合預(yù)期。

公有云 MSHA 已經(jīng)開始公測(cè)，并已提供文中 2 個(gè)業(yè)務(wù)場景的電商業(yè)務(wù) Demo 體驗(yàn)（無需開通即可體驗(yàn)），歡迎大家申請(qǐng)?bào)w驗(yàn)。

最后想跟大家說的是，容災(zāi)建設(shè)是一個(gè)系統(tǒng)工程，不能一蹴而就也不是一錘子買賣，需要根據(jù)業(yè)務(wù)場景、容災(zāi)訴求、技術(shù)棧、容災(zāi)預(yù)算等綜合來評(píng)估和制定合適的容災(zāi)架構(gòu)建設(shè)方案，歡迎大家針對(duì)自身的容災(zāi)訴求和場景進(jìn)行咨詢和交流。

延伸閱讀

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

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

• 電商業(yè)務(wù)多活實(shí)踐：https://help.aliyun.com/document_detail/184984.html

• 強(qiáng)弱依賴治理&故障演練最佳實(shí)踐：https://help.aliyun.com/document_detail/185932.html

歡迎釘釘搜索群號(hào)：31623894，加入多活容災(zāi)(MSHA)交流釘釘群。

總結(jié)

以上是生活随笔為你收集整理的MSHA x Chaos 容灾高可用实践的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。