以下是視訊内容的精華整理。
伴随着網際網路業務的高速發展，越來越多的線下場景需要轉移到線上，而線上業務的量級飛速增長，也給網際網路業務的技術架構帶來了嚴峻挑戰，原來的“一體機+資料庫”的方式已經不适用于目前的主流業務，越來越來的業務開始向分布式架構和雲原生架構演進。同時，原來單一的技術環境開始走向分布式、分層的多元件技術架構，越來越多的元件使得我們保障業務穩定運作的工作也越來越艱巨。
依據阿裡雲的實踐經驗，将以下四個次元做好了才能真正建構一個高可用體系，下文從這四個次元介紹如何建構一個雲原生高可用技術體系。
容災：切流，同城雙活，異地多活；
容量：全鍊路壓測，瓶頸探測，容量規劃；
線上防護：流量防護，開關預案，流量排程；
演練：故障演練，容災演練，預案演練。
一、容災
航空系統的容災體系做的是非常優秀的。如下圖所示，航空系統的容災體系從人、機和環境三個次元來考慮，才能建構一套優秀的容災方案。
從航空業的容災體系建構中我們可以發現容災的核心思想——備援。在系統設計中，其實我們也經常用到備援的機制，比如機器經常是多台的、資料是多備份的等等。
容災的評價名額主要有兩個：
RPO：Recovery Point Objective，即資料恢複點目标，以時間為機關，即在災難發生時，系統和資料必須恢複的時間點要求；
RTO：Recovery Time Objective，即恢複時間目标，以時間為機關，即在災難發生後，資訊系統或業務功能從停止到必須恢複的時間要求；RTO标志系統能夠容忍的服務停止的最長時間，系統服務的緊迫性要求越高，RTO的值越小。
（一）業界主流容災方案
如下圖所示，業内主流的容災方案最早是異地冷備的方式，後來演進到同城雙活方式，最後不斷發展成為“兩地三中心”。
（二）阿裡AHAS
阿裡AHAS容災方案使用的是比“兩地三中心”走的更靠前的“異地多活”方案，在所有的資料中心都能提供服務的同時，RPO和RTO都能做到分鐘級甚至秒級。下圖是阿裡AHAS的産品形态，AHAS在13年之後就開始大規模在阿裡内部使用，并且作為高可用平台的一個核心子產品，開始服務外部客戶。AHAS通過異地多活，能夠真正做到對于宏觀架構的容災能力，能夠抵禦大規模的失敗場景，比如一個城市的機房出了故障，可以很輕易的把流量實時切換到另外一個機房。
二、容量
網際網路業務下，流量的不确定性非常明顯，經常會出現比如微網誌的熱點事件、阿裡的雙十一、12306的火車票放購等事件。在這種場景下，如何做好容量規劃，就變得至關重要。
（一）壓測
傳統的壓力測試，我們通常關注的是性能的好壞，是一個相對模糊的概念，不需要很精準。但是在網際網路的情況下， 我們需要精準的擷取到一個系統的實時吞吐量，以便能更好的應對突發事件。在這種情況下，壓測必須要盡可能的模拟一個真實的環境，而不能像以往一樣，在一個特殊的環境去測試，壓測時在流量規模、流量模型、系統環境上都需要一個盡可能真實的環境，這樣子才能在故障發生時從容應對。
傳統的壓測工具雖然仍在發揮着作用，但是随着網際網路的發展，卻越來越不能去适應網際網路技術的疊代。網際網路的壓測有着幾個特點：
強調流量的真實性；
壓測規模要足夠大；
必須簡單易用；
如今的網際網路壓測已經變成了一個實時的産品，友善進行實時的調控。基于以上，阿裡建構了基于PTS的流量引擎，大家可以在阿裡雲上直接使用，其特點如下圖所示。
（二）全鍊路壓測
在實踐中，我們發現單系統單應用的壓測與真實場景之間的誤差非常大，因為在壓測的時候無法驗證整個系統的方方面面，而且很多問題隻有在真正的大流量場景下才會暴露，是以要進行全鍊路壓測，其核心是希望未來的事件能夠提前的在目前時間内發生，能夠用最真實的場景來端對端的驗證系統的能力和穩定性。
為了實作更好的全鍊路壓測，阿裡提出了基于PTS的全鍊路壓測，其架構如下圖所示。
從壓測環境、壓測基礎資料、壓測流量（模型、資料）、流量發起和問題定為對基于TPS的全鍊路壓測解決方案總結如下：
三、線上防護
線上防護對于容災體系來說也是一個非常重要的環節。随着分布式技術的應用，節點越來越多，技術越來越複雜，出錯的機會也相對增大；同時，在網際網路的條件下，業務的釋出也越來越頻繁，bug也會随之增多；最後，網際網路的條件下，我們随時都面臨着一些不确定事件、流量沖擊等等，我們不能奢望每次出現故障的時候都有人工來進行幹預，是以我們希望系統自身有一定的防護能力，能夠讓自身在任何環境下都能有最佳的工作狀态。
（一）AHAS流量防護
流量防護在阿裡巴巴廣泛應用于各種場景，比如雙十一峰值流量、秒殺活動、物流、訂單處理、商品查詢、付款等等。同時，阿裡也成功的将流量防護能力融合到了雲産品AHAS（Application High Availability Service，應用高可用服務）中。AHAS涵蓋了阿裡多年來在應用高可用服務領域的技術沉澱，包含架構感覺、流量防護、故障演練和功能開關四大獨立的功能子產品，如下圖所示，AHAS建構了一個從入口到最後端的一個完整的防護體系。
（二）AHAS針對大流量場景的保護措施
流量防護最首先需要考慮的就是對大流量場景的保護，比如url，服務提供方，重點業務等，突然出現超乎預期的大流量，基于AHAS可以做如下防護措施：
（1）如果有性能壓測，可以精準設定QPS門檻值，有了QPS門檻值，可以用來限流，避免出現超負載的流量；
（2）如果沒有性能壓測，也可以通過秒級監控，實時設定門檻值；
（3）支援高階功能：流控模式支援直接、關聯、鍊路，流控方式支援快速失敗、Warm UP、排隊等待。
（三）AHAS針對不同場景的措施——異常隔離
在特定未可知的場景，可能出現不穩定因素，例如慢SQL，甚至死鎖，導緻整個應用越來越慢，甚至整個應用沒有響應，這時候要對異常流量進行隔離，以免影響到正常的流量。
（三）AHAS針對不同場景的措施之系統防護
在某些場景下，比如系統的負載CPU飙升，系統沒有反應，來不及定為具體哪個接口導緻這個原因，這時候AHAS提供了一個終極大招：系統保護。系統保護就是當系統負載比較高的時候，會自動根據入口流量和系統的負載取得一個動态的平衡，保證系統不會惡化的同時，同時處理最大的入口請求。但是這種情況下，系統對各種流量都是平等的，無法設定流量的優先級。
四、演練
很多故障是一個小機率事件，但是一旦發生，所造成的損失是不可估量的，比如巴黎聖母院的火災。同樣的，網際網路業務也是一樣，小機率的故障也可能帶來不可挽回的經濟損失，甚至是法律風險，系統崩潰了，痛的可能不僅是股價，更重要的是信任和使用者流失。是以，故障演練是一個完備的容災體系所必須進行的一步。
（一）企業為什麼需要做故障演練
如果一個業務系統的流量很小且趨于穩定，那麼是沒有必要進行故障演練的，但是如果一個企業處于高速發展中，業務發展快，有大量的穩定性技術債，其業務系統不斷的變化，甚至今天的形态跟昨天的形态都不一緻，架構也日益複雜，那麼故障演練就是十分必要且必需的。因為每個環節的不确定因子都是累積的，如果不進行故障演練，最後一旦發生故障，極大可能會對系統造成嚴重破壞。進行故障演練，還可以培養企業的人員故障處理經驗，增強人員的應急能力。
（二）企業引入故障演練遇到的常見問題
在企業進行故障演練的時候，經常會遇到一些問題，比如如何設計組織架構？如何選擇技術方案？如何落地演練實踐？更多的問題見下圖。在解決這些問題的時候，我們需要注意一個問題就是如果業務牽涉到資金，就要做一個清晰化的深層評估，不要因為演練導緻出現資金上的虧損，比如在演練中用到的收費内容（例如短信等）我們要考慮周全。
（三）阿裡的故障演練方案
如下圖所示，阿裡自己有着一套完整的故障演練方案，一開始也是通過一些工具或者腳本來進行，在2016年之後才開始将通用的故障模式沉澱為系統，之後在2018年将内部沉澱多年的實踐正式在阿裡雲商用，2019年時将沉澱多年的故障注入場景正式開源，成為國内首個混沌工程開源産品。
（四）AHAS故障演練
AHAS故障演練的産品架構如下圖所示，其定位是一款簡單、安全、低成本的故障演練工具，能夠幫助使用者快速實施演練并發現問題。
從産品角度來講，AHAS故障演練産品有兩個特色：可視化和安全。通過可視化功能我們可以将演練過程中的系統名額直覺展示，可以“邊演練，邊觀察”；另外，AHAS還可以指定保護政策，自動觸發并終止演練，避免系統因演練而引發的預期外故障。
AHAS和PTS都可以在阿裡雲的平台上直接使用，大家感興趣的話可以到阿裡雲官網進行更詳細的了解。
關鍵詞：高可用技術體系，容災，容量，全鍊路壓測，線上防護，故障演練，AHAS，PTS