簡介：原來單一的技術環境開始走向分布式、分層的多組件技術架構，越來越多的組件使得保障業務穩定運行的工作也越來越艱巨。本文從容災、容量、線上防護、演練四個維度全方位講解如何構建一個真正的高可用體系。

伴隨著互聯網業務的高速發展，越來越多的線下場景需要轉移到線上，而線上業務的量級也在飛速增長，給互聯網業務的技術架構帶來了嚴峻的挑戰，原來的“一體機+數據庫”的方式已經不適用于當前的主流業務，越來越來的業務開始向分布式架構和云原生架構演進。同時，原來單一的技術環境開始走向分布式、分層的多組件技術架構，越來越多的組件使得保障業務穩定運行的工作也越來越艱巨。

一、容災

航空系統的容災體系做得非常優秀。航空系統的容災體系從人、飛機和環境三個維度來考慮，才能構建一套優秀的容災方案。

從人的維度，以防萬分之一的緊急情況出現的可能，每年要進行多次的模擬機訓練或者實景演練。一架飛機上都會配備至少兩名飛行員，二者相互合作的同時也要相互監督。

從飛機的維度，每一個航段前，光是一個繞機檢查可能就有幾十個項目需要檢查。機檢查是由地面機務人員和飛行機組分別完成，同樣也是為了更仔細的檢查，降低錯誤率。每架飛機還有短期全面檢查和長期全面檢查，飛機上的每一個設備都是獨立的雙系統在工作。

從環境的維度，氣象雷達可以讓飛行員感知到幾十甚至幾百海里范圍內的天氣情況。飛機防撞系統可以讓飛行導航顯示儀上顯示正在接近的可能存在威脅的飛機。盲降系統是由地面發射的兩束無線電信號實現航向道和下滑道指引，飛機通過機載接收設備，進行降落。

從航空業的容災體系構建中我們可以發現，容災的核心思想是基于隔離的冗余。在系統設計中，其實也經常用到冗余的機制，比如機器經常是多臺、數據是多備份等。容災的評價指標主要有兩個：
一是RPO（Recovery Point Objective），即數據恢復點目標，以時間為單位，即在災難發生時，系統和數據必須恢復的時間點要求。
二是RTO（Recovery Time Objective），即恢復時間目標，以時間為單位，即在災難發生后，信息系統或業務功能從停止到必須恢復的時間要求。RTO標志著系統能夠容忍的服務停止的最長時間，系統服務的緊迫性要求越高，RTO的值越小。

1. 業界主流容災方案

如下圖所示，業內主流的容災方案最早是異地冷備的方式，后來演進到同城雙活方式，最后發展成為“兩地三中心”。

業界主流容災方案

2. 阿里AHAS

阿里AHAS容災方案使用的是比“兩地三中心”更前沿的“異地多活”方案，在所有的數據中心都能提供服務的同時，RPO和RTO能做到分鐘級甚至秒級。下圖是阿里AHAS的產品形態。AHAS在2013年之后就開始大規模在阿里內部使用，并且作為高可用平臺的一個核心模塊，開始服務外部客戶。AHAS通過異地多活，能夠真正做到對于宏觀架構的容災，并抵御大規模的失敗場景。比如一個城市的機房出了故障，可以很輕易地把流量實時切換到另外一個機房。

AHAS異地多活的產品形態

二、容量

在互聯網業務下，流量的不確定性非常明顯，經常會出現流量高峰事件，比如微博的熱點、阿里的雙11、12306的火車票放購等事件。在這種場景下，如何做好容量規劃就變得至關重要。

1. 壓測

傳統的壓力測試通常關注的是性能的好壞，這是一個相對模糊的概念，不需要很精準。但是在互聯網的情況下， 我們需要精準地獲取到一個系統的實時吞吐量，以便更好地應對突發事件。在這種情況下，壓測要盡可能地模擬一個真實的環境，而不能像以往一樣，在一個額外的環境去測試。壓測時在流量規模、流量模型、系統環境上都需要一個盡可能真實的環境，這樣才能精準做好容量規劃。

傳統的壓測工具雖然仍在發揮作用，但是隨著互聯網的發展，已經越來越不能去適應互聯網技術的迭代?；ヂ摼W的壓測有幾個明顯的特點：
強調流量的真實性；
壓測規模要足夠大；
必須簡單易用，交互式壓測。

當下互聯網壓測已經變成了一個實時的產品，方便進行實時的調控?；谶@樣的背景，阿里構建了基于PTS的流量引擎，大家可以在阿里云上直接使用，其特點如下：
流量真實。流量來源于全國上百城市，覆蓋各運營商（可拓展至海外），真實模擬最終用戶的流量來源，相應的報表、數據更接近用戶真實體感；發現端到端更多更全面的問題，壓測即是模擬考。
壓測規模強大，可支持3kW QPS。
簡單易用，門檻低。復雜場景的全可視化編排，支持自定義編排能力、指令、控制、函數等相關能力，覆蓋95%以上的HTTP壓測場景，和JMeter構建能力不相伯仲，同時免去復雜的理解學習成本；除了自身豐富的客戶側監控數據，還可集成云監控和ARMS監控。壓測過程提供日志明細查詢，配套有請求瀑布模型，壓測之后的報告和問題定位更方便。結合AHAS可額外提供流量吞吐控制能力、容量水位管理、熔斷降級保護功能。除了強大的自研功能，對于開源JMeter的支持也很友好，支持JMeter腳本轉化為PTS壓測，同樣支持原生JMeter引擎進行壓測。

2. 全鏈路壓測

在實踐中發現，單系統單應用的壓測與真實場景之間的誤差非常大，因為在壓測的時候無法驗證整個系統的方方面面，而且很多問題只有在真正的大流量場景下才會暴露，所以要進行全鏈路壓測，其核心是希望未來的事件能夠提前到在當前時間內發生，能夠用最真實的場景來端對端的驗證系統的能力和穩定性。

為了實現更好地進行全鏈路壓測，阿里云提出了基于PTS的全鏈路壓測解決方案，其架構如下圖所示。

基于PTS的全鏈路壓測

從壓測環境、壓測基礎數據、壓測流量（模型、數據）、流量發起和問題定位對基于PTS的全鏈路壓測解決方案總結如下：
壓測環境：對應真實的線上環境，壓測結果和問題暴露都是最真實的情況，可通過壓測流量全局識別、透傳（影子表），或者等比隔離環境，或復用生產庫（壓測使用測試數據），業務擋板。
壓測基礎數據：構造滿足大促場景的核心基礎相關數據（如買家、賣家、商品信息），以線上數據為數據源，進行采樣、過濾和脫敏，保持和線上一個量級。
壓測流量（模型、數據）：鏈路范圍、訪問量級、參數集合、基礎數據的特性一起構造壓測的業務模型，和真實業務情況保持一致。
流量發起：模擬全國各地真實的用戶請求訪問，探測站點能力。
問題定位：發起側多維度的監控和報表，服務端可通過其他生態產品協助定位。

三、線上防護

線上防護對于系統高可用來說是一個非常重要的環節。隨著分布式技術的應用，節點越來越多，技術越來越復雜，出錯的機會也相對增大。同時，在互聯網的條件下，業務的發布也越來越頻繁。在互聯網的環境下，系統隨時面臨一些不確定事件、流量沖擊等，不能奢望每次出現故障的時候都有人工來干預，而是需要系統自身有一定的防護能力，能夠讓自身在任何環境下都能有最佳的工作狀態。

1. AHAS流量防護

阿里云將流量防護廣泛應用于各種場景，比如雙11峰值流量、秒殺活動、物流、訂單處理、商品查詢、付款等。同時，阿里云也成功地將流量防護能力融合到了云產品AHAS（Application High Availability Service，應用高可用服務）中。AHAS涵蓋了阿里巴巴多年來在應用高可用服務領域的技術沉淀，包括架構感知、流量防護、故障演練和功能開關四大獨立的功能模塊。如下圖所示，AHAS構建了一個從入口到最后端的一個完整的防護體系。

AHAS經典流量防護布局

2. AHAS針對大流量場景的保護措施

流量防護首先需要考慮的是對大流量場景的保護，比如url、服務提供方、重點業務等，突然出現超乎預期的大流量，基于AHAS可以做如下防護措施：
（1）如果有性能壓測，可以精準設置QPS閾值。有了QPS閾值，可以用來限流，避免出現超負載的流量。
（2）如果沒有性能壓測，也可以通過秒級監控，實時設置閾值。
（3）支持高階功能：流控模式支持直接、關聯、鏈路，流控方式支持快速失敗、Warm UP、排隊等待。

3. AHAS針對不同場景的措施——異常隔離

在特定未知的場景下，可能出現不穩定的因素，如慢SQL，甚至死鎖，導致整個應用越來越慢，甚至整個應用沒有響應，這時候要對異常流量進行隔離，以免影響到正常的流量。

4. AHAS針對不同場景的措施——系統防護

在某些場景下，比如系統的負載CPU飆升，系統沒有反應，無法確認具體哪個接口導致問題的出現，這時AHAS提供了一個終極大招：系統保護。系統保護就是當系統負載比較高的時候，會自動根據入口流量和系統的負載取得一個動態的平衡，保證系統不會惡化的同時，也能處理最大的入口請求。在這種情況下，系統對各種流量都是平等的，無法設置流量的優先級。

四、演練

很多故障是一個小概率事件，但是一旦發生，所造成的損失是不可估量的，比如巴黎圣母院的火災。互聯網業務也是一樣，小概率的故障也可能帶來不可挽回的經濟損失，甚至是法律風險。因此，故障演練是一個完備的容災體系所必需進行的一步。

1. 企業為什么需要做故障演練？

如果一個業務系統的流量很小且趨于穩定，就沒有必要進行故障演練。但是如果一個企業處于高速發展中，業務發展快，有大量的穩定性技術債，其業務系統不斷的變化，甚至今天的形態跟昨天的形態都不一致，架構也日益復雜，那么故障演練就是十分必要且必需的。因為每個環節的不確定因子都是累積的，如果不進行故障演練，最后一旦發生故障，極大可能會對系統造成嚴重破壞。故障演練還可以培養企業人員的故障處理經驗，增強人員的應急能力。

2. 企業引入故障演練遇到的常見問題

在企業進行故障演練的時候，經常會遇到一些問題，比如如何設計組織架構，如何選擇技術方案，如何落地演練實踐等。如果業務牽涉到資金，就要做一個清晰化的深層評估，不要因為演練導致出現資金上的虧損，比如在演練中用到的收費內容（例如短信等）要考慮周全。

3. 阿里的故障演練方案

如下圖所示，阿里有一套完整的故障演練方案。一開始是通過一些工具或者腳本，在2016年之后才開始將通用的故障模式沉淀為系統。2018年阿里將內部沉淀多年的實踐正式在阿里云商用，2019年將沉淀多年的故障注入場景正式開源，成為國內首個混沌工程開源產品。

阿里故障演練歷程

4. AHAS故障演練

AHAS故障演練的產品架構如下圖所示，其定位是一款簡單、安全、低成本的故障演練工具，能夠幫助用戶快速實施演練并發現問題。

原文鏈接：https://developer.aliyun.com/article/768244?

版權聲明：本文中所有內容均屬于阿里云開發者社區所有，任何媒體、網站或個人未經阿里云開發者社區協議授權不得轉載、鏈接、轉貼或以其他方式復制發布/發表。申請授權請郵件developerteam@list.alibaba-inc.com，已獲得阿里云開發者社區協議授權的媒體、網站，在轉載使用時必須注明"稿件來源：阿里云開發者社區，原文作者姓名"，違者本社區將依法追究責任。 如果您發現本社區中有涉嫌抄襲的內容，歡迎發送郵件至：developer2020@service.aliyun.com 進行舉報，并提供相關證據，一經查實，本社區將立刻刪除涉嫌侵權內容。

總結

以上是生活随笔為你收集整理的云原生高可用技术体系的构建的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。