云原生高可用技术体系的构建
伴隨著互聯(lián)網(wǎng)業(yè)務的高速發(fā)展,越來越多的線下場景需要轉(zhuǎn)移到線上,而線上業(yè)務的量級也在飛速增長,給互聯(lián)網(wǎng)業(yè)務的技術(shù)架構(gòu)帶來了嚴峻的挑戰(zhàn),原來的“一體機+數(shù)據(jù)庫”的方式已經(jīng)不適用于當前的主流業(yè)務,越來越來的業(yè)務開始向分布式架構(gòu)和云原生架構(gòu)演進。同時,原來單一的技術(shù)環(huán)境開始走向分布式、分層的多組件技術(shù)架構(gòu),越來越多的組件使得保障業(yè)務穩(wěn)定運行的工作也越來越艱巨。
一、容災
航空系統(tǒng)的容災體系做得非常優(yōu)秀。航空系統(tǒng)的容災體系從人、飛機和環(huán)境三個維度來考慮,才能構(gòu)建一套優(yōu)秀的容災方案。
從人的維度,以防萬分之一的緊急情況出現(xiàn)的可能,每年要進行多次的模擬機訓練或者實景演練。一架飛機上都會配備至少兩名飛行員,二者相互合作的同時也要相互監(jiān)督。
從飛機的維度,每一個航段前,光是一個繞機檢查可能就有幾十個項目需要檢查。機檢查是由地面機務人員和飛行機組分別完成,同樣也是為了更仔細的檢查,降低錯誤率。每架飛機還有短期全面檢查和長期全面檢查,飛機上的每一個設備都是獨立的雙系統(tǒng)在工作。
從環(huán)境的維度,氣象雷達可以讓飛行員感知到幾十甚至幾百海里范圍內(nèi)的天氣情況。飛機防撞系統(tǒng)可以讓飛行導航顯示儀上顯示正在接近的可能存在威脅的飛機。盲降系統(tǒng)是由地面發(fā)射的兩束無線電信號實現(xiàn)航向道和下滑道指引,飛機通過機載接收設備,進行降落。
從航空業(yè)的容災體系構(gòu)建中我們可以發(fā)現(xiàn),容災的核心思想是基于隔離的冗余。在系統(tǒng)設計中,其實也經(jīng)常用到冗余的機制,比如機器經(jīng)常是多臺、數(shù)據(jù)是多備份等。容災的評價指標主要有兩個:
一是RPO(Recovery Point Objective),即數(shù)據(jù)恢復點目標,以時間為單位,即在災難發(fā)生時,系統(tǒng)和數(shù)據(jù)必須恢復的時間點要求。
二是RTO(Recovery Time Objective),即恢復時間目標,以時間為單位,即在災難發(fā)生后,信息系統(tǒng)或業(yè)務功能從停止到必須恢復的時間要求。RTO標志著系統(tǒng)能夠容忍的服務停止的最長時間,系統(tǒng)服務的緊迫性要求越高,RTO的值越小。
1. 業(yè)界主流容災方案
如下圖所示,業(yè)內(nèi)主流的容災方案最早是異地冷備的方式,后來演進到同城雙活方式,最后發(fā)展成為“兩地三中心”。
業(yè)界主流容災方案
2. 阿里AHAS
阿里AHAS容災方案使用的是比“兩地三中心”更前沿的“異地多活”方案,在所有的數(shù)據(jù)中心都能提供服務的同時,RPO和RTO能做到分鐘級甚至秒級。下圖是阿里AHAS的產(chǎn)品形態(tài)。AHAS在2013年之后就開始大規(guī)模在阿里內(nèi)部使用,并且作為高可用平臺的一個核心模塊,開始服務外部客戶。AHAS通過異地多活,能夠真正做到對于宏觀架構(gòu)的容災,并抵御大規(guī)模的失敗場景。比如一個城市的機房出了故障,可以很輕易地把流量實時切換到另外一個機房。
AHAS異地多活的產(chǎn)品形態(tài)
二、容量
在互聯(lián)網(wǎng)業(yè)務下,流量的不確定性非常明顯,經(jīng)常會出現(xiàn)流量高峰事件,比如微博的熱點、阿里的雙11、12306的火車票放購等事件。在這種場景下,如何做好容量規(guī)劃就變得至關重要。
1. 壓測
傳統(tǒng)的壓力測試通常關注的是性能的好壞,這是一個相對模糊的概念,不需要很精準。但是在互聯(lián)網(wǎng)的情況下, 我們需要精準地獲取到一個系統(tǒng)的實時吞吐量,以便更好地應對突發(fā)事件。在這種情況下,壓測要盡可能地模擬一個真實的環(huán)境,而不能像以往一樣,在一個額外的環(huán)境去測試。壓測時在流量規(guī)模、流量模型、系統(tǒng)環(huán)境上都需要一個盡可能真實的環(huán)境,這樣才能精準做好容量規(guī)劃。
傳統(tǒng)的壓測工具雖然仍在發(fā)揮作用,但是隨著互聯(lián)網(wǎng)的發(fā)展,已經(jīng)越來越不能去適應互聯(lián)網(wǎng)技術(shù)的迭代。互聯(lián)網(wǎng)的壓測有幾個明顯的特點:
強調(diào)流量的真實性;
壓測規(guī)模要足夠大;
必須簡單易用,交互式壓測。
當下互聯(lián)網(wǎng)壓測已經(jīng)變成了一個實時的產(chǎn)品,方便進行實時的調(diào)控。基于這樣的背景,阿里構(gòu)建了基于PTS的流量引擎,大家可以在阿里云上直接使用,其特點如下:
流量真實。流量來源于全國上百城市,覆蓋各運營商(可拓展至海外),真實模擬最終用戶的流量來源,相應的報表、數(shù)據(jù)更接近用戶真實體感;發(fā)現(xiàn)端到端更多更全面的問題,壓測即是模擬考。
壓測規(guī)模強大,可支持3kW QPS。
簡單易用,門檻低。復雜場景的全可視化編排,支持自定義編排能力、指令、控制、函數(shù)等相關能力,覆蓋95%以上的HTTP壓測場景,和JMeter構(gòu)建能力不相伯仲,同時免去復雜的理解學習成本;除了自身豐富的客戶側(cè)監(jiān)控數(shù)據(jù),還可集成云監(jiān)控和ARMS監(jiān)控。壓測過程提供日志明細查詢,配套有請求瀑布模型,壓測之后的報告和問題定位更方便。結(jié)合AHAS可額外提供流量吞吐控制能力、容量水位管理、熔斷降級保護功能。除了強大的自研功能,對于開源JMeter的支持也很友好,支持JMeter腳本轉(zhuǎn)化為PTS壓測,同樣支持原生JMeter引擎進行壓測。
2. 全鏈路壓測
在實踐中發(fā)現(xiàn),單系統(tǒng)單應用的壓測與真實場景之間的誤差非常大,因為在壓測的時候無法驗證整個系統(tǒng)的方方面面,而且很多問題只有在真正的大流量場景下才會暴露,所以要進行全鏈路壓測,其核心是希望未來的事件能夠提前到在當前時間內(nèi)發(fā)生,能夠用最真實的場景來端對端的驗證系統(tǒng)的能力和穩(wěn)定性。
為了實現(xiàn)更好地進行全鏈路壓測,阿里云提出了基于PTS的全鏈路壓測解決方案,其架構(gòu)如下圖所示。
基于PTS的全鏈路壓測
從壓測環(huán)境、壓測基礎數(shù)據(jù)、壓測流量(模型、數(shù)據(jù))、流量發(fā)起和問題定位對基于PTS的全鏈路壓測解決方案總結(jié)如下:
壓測環(huán)境:對應真實的線上環(huán)境,壓測結(jié)果和問題暴露都是最真實的情況,可通過壓測流量全局識別、透傳(影子表),或者等比隔離環(huán)境,或復用生產(chǎn)庫(壓測使用測試數(shù)據(jù)),業(yè)務擋板。
壓測基礎數(shù)據(jù):構(gòu)造滿足大促場景的核心基礎相關數(shù)據(jù)(如買家、賣家、商品信息),以線上數(shù)據(jù)為數(shù)據(jù)源,進行采樣、過濾和脫敏,保持和線上一個量級。
壓測流量(模型、數(shù)據(jù)):鏈路范圍、訪問量級、參數(shù)集合、基礎數(shù)據(jù)的特性一起構(gòu)造壓測的業(yè)務模型,和真實業(yè)務情況保持一致。
流量發(fā)起:模擬全國各地真實的用戶請求訪問,探測站點能力。
問題定位:發(fā)起側(cè)多維度的監(jiān)控和報表,服務端可通過其他生態(tài)產(chǎn)品協(xié)助定位。
三、線上防護
線上防護對于系統(tǒng)高可用來說是一個非常重要的環(huán)節(jié)。隨著分布式技術(shù)的應用,節(jié)點越來越多,技術(shù)越來越復雜,出錯的機會也相對增大。同時,在互聯(lián)網(wǎng)的條件下,業(yè)務的發(fā)布也越來越頻繁。在互聯(lián)網(wǎng)的環(huán)境下,系統(tǒng)隨時面臨一些不確定事件、流量沖擊等,不能奢望每次出現(xiàn)故障的時候都有人工來干預,而是需要系統(tǒng)自身有一定的防護能力,能夠讓自身在任何環(huán)境下都能有最佳的工作狀態(tài)。
1. AHAS流量防護
阿里云將流量防護廣泛應用于各種場景,比如雙11峰值流量、秒殺活動、物流、訂單處理、商品查詢、付款等。同時,阿里云也成功地將流量防護能力融合到了云產(chǎn)品AHAS(Application High Availability Service,應用高可用服務)中。AHAS涵蓋了阿里巴巴多年來在應用高可用服務領域的技術(shù)沉淀,包括架構(gòu)感知、流量防護、故障演練和功能開關四大獨立的功能模塊。如下圖所示,AHAS構(gòu)建了一個從入口到最后端的一個完整的防護體系。
AHAS經(jīng)典流量防護布局
2. AHAS針對大流量場景的保護措施
流量防護首先需要考慮的是對大流量場景的保護,比如url、服務提供方、重點業(yè)務等,突然出現(xiàn)超乎預期的大流量,基于AHAS可以做如下防護措施:
(1)如果有性能壓測,可以精準設置QPS閾值。有了QPS閾值,可以用來限流,避免出現(xiàn)超負載的流量。
(2)如果沒有性能壓測,也可以通過秒級監(jiān)控,實時設置閾值。
(3)支持高階功能:流控模式支持直接、關聯(lián)、鏈路,流控方式支持快速失敗、Warm UP、排隊等待。
3. AHAS針對不同場景的措施——異常隔離
在特定未知的場景下,可能出現(xiàn)不穩(wěn)定的因素,如慢SQL,甚至死鎖,導致整個應用越來越慢,甚至整個應用沒有響應,這時候要對異常流量進行隔離,以免影響到正常的流量。
4. AHAS針對不同場景的措施——系統(tǒng)防護
在某些場景下,比如系統(tǒng)的負載CPU飆升,系統(tǒng)沒有反應,無法確認具體哪個接口導致問題的出現(xiàn),這時AHAS提供了一個終極大招:系統(tǒng)保護。系統(tǒng)保護就是當系統(tǒng)負載比較高的時候,會自動根據(jù)入口流量和系統(tǒng)的負載取得一個動態(tài)的平衡,保證系統(tǒng)不會惡化的同時,也能處理最大的入口請求。在這種情況下,系統(tǒng)對各種流量都是平等的,無法設置流量的優(yōu)先級。
四、演練
很多故障是一個小概率事件,但是一旦發(fā)生,所造成的損失是不可估量的,比如巴黎圣母院的火災。互聯(lián)網(wǎng)業(yè)務也是一樣,小概率的故障也可能帶來不可挽回的經(jīng)濟損失,甚至是法律風險。因此,故障演練是一個完備的容災體系所必需進行的一步。
1. 企業(yè)為什么需要做故障演練?
如果一個業(yè)務系統(tǒng)的流量很小且趨于穩(wěn)定,就沒有必要進行故障演練。但是如果一個企業(yè)處于高速發(fā)展中,業(yè)務發(fā)展快,有大量的穩(wěn)定性技術(shù)債,其業(yè)務系統(tǒng)不斷的變化,甚至今天的形態(tài)跟昨天的形態(tài)都不一致,架構(gòu)也日益復雜,那么故障演練就是十分必要且必需的。因為每個環(huán)節(jié)的不確定因子都是累積的,如果不進行故障演練,最后一旦發(fā)生故障,極大可能會對系統(tǒng)造成嚴重破壞。故障演練還可以培養(yǎng)企業(yè)人員的故障處理經(jīng)驗,增強人員的應急能力。
2. 企業(yè)引入故障演練遇到的常見問題
在企業(yè)進行故障演練的時候,經(jīng)常會遇到一些問題,比如如何設計組織架構(gòu),如何選擇技術(shù)方案,如何落地演練實踐等。如果業(yè)務牽涉到資金,就要做一個清晰化的深層評估,不要因為演練導致出現(xiàn)資金上的虧損,比如在演練中用到的收費內(nèi)容(例如短信等)要考慮周全。
3. 阿里的故障演練方案
如下圖所示,阿里有一套完整的故障演練方案。一開始是通過一些工具或者腳本,在2016年之后才開始將通用的故障模式沉淀為系統(tǒng)。2018年阿里將內(nèi)部沉淀多年的實踐正式在阿里云商用,2019年將沉淀多年的故障注入場景正式開源,成為國內(nèi)首個混沌工程開源產(chǎn)品。
阿里故障演練歷程
4. AHAS故障演練
AHAS故障演練的產(chǎn)品架構(gòu)如下圖所示,其定位是一款簡單、安全、低成本的故障演練工具,能夠幫助用戶快速實施演練并發(fā)現(xiàn)問題。
原文鏈接:https://developer.aliyun.com/article/768244?
版權(quán)聲明:本文中所有內(nèi)容均屬于阿里云開發(fā)者社區(qū)所有,任何媒體、網(wǎng)站或個人未經(jīng)阿里云開發(fā)者社區(qū)協(xié)議授權(quán)不得轉(zhuǎn)載、鏈接、轉(zhuǎn)貼或以其他方式復制發(fā)布/發(fā)表。申請授權(quán)請郵件developerteam@list.alibaba-inc.com,已獲得阿里云開發(fā)者社區(qū)協(xié)議授權(quán)的媒體、網(wǎng)站,在轉(zhuǎn)載使用時必須注明"稿件來源:阿里云開發(fā)者社區(qū),原文作者姓名",違者本社區(qū)將依法追究責任。 如果您發(fā)現(xiàn)本社區(qū)中有涉嫌抄襲的內(nèi)容,歡迎發(fā)送郵件至:developer2020@service.aliyun.com 進行舉報,并提供相關證據(jù),一經(jīng)查實,本社區(qū)將立刻刪除涉嫌侵權(quán)內(nèi)容。總結(jié)
以上是生活随笔為你收集整理的云原生高可用技术体系的构建的全部內(nèi)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 八位技术专家分享他们最喜欢的物联网技术
- 下一篇: 人工智能、物联网和大数据如何拯救蜜蜂