講師：牛兔（張春梅）
本次分享将按照以下四個方面展開：
高可用體系
雲上PTS服務
AHAS流量防護 一．高可用體系
1.高可用體系概念：除了像日常代碼功能測試之外，其他與業務穩定性或者可用性相關的都可成為高可用體系，所謂高可用即就是讓業務和服務高可用。
2.高可用體系按照功能或者業務實作可以分為：
①全鍊路壓測：容量規劃，彈性伸縮，線上壓測；
②線上管控：限流降級，開關預案，流量排程，監控報警；
③異地多活：容錯容災；
④故障演練：依賴治理，灰階測試。
3.高可用體系中商業化的産品包括：PTS(性能測試服務)和AHAS 應用高可用服務。
4.AHAS 應用高可用服務包括線上流量防護以及故障演練兩個部分。
在做業務需求或者業務維護時：除了關注資源層面問題，要站在更高一層去關注業務服務的情況，業務服務的整個系統架構能不能夠高可用使用，從工具、方法、角度去關注可以如何做這些事情。
二．雲上PTS服務
PTS的發展曆程
從2008年開始，阿裡巴巴開始做性能測試和分布式化，到2010年開始做容量規劃方面，像CSP,Autoload的工具；之後開始做線下的性能測試，像PAP分布式壓測平台，但是線下測試會産生相關問題，由于線上環境與線下規模以及代碼配置之間有差異，會産生準确性能不夠高的問題，可能會導緻壓出來的資料沒有意義。之後開始嘗試用CSP做線上測試，會涉及到基礎的操作，會根據線上流量，從日志上裡面爬一下裡面涉及到的接口是什麼，這些接口的大概比例是什麼，相關日志回放，但是日志回放會有一個問題，用最簡單的post類型來看，post類型幾乎不會打到表單裡去，就算打入日志裡面去，資料能否正常使用也是一個問題。到2013年釋出全鍊路壓測1.0版本，該版本可以做全部鍊路的一些壓測，包括基礎資料構造，構造的資料可以全部放進去，以及鍊路之間的接口配置可以做到；到2014年，通過SV平台輸出，但是此時SV平台利用做線下測試，類似于之前做的PAP，到2015年推出PTS基礎版，形式為腳本形式，資料以及要壓的東西，腳本以要在PTS版本裡面寫好，同年全鍊路壓測開始做平台化，依賴的第三方端，例如在支付上，要如何去做，是要mooc掉還是做鍊路打通，探尋更多的平台，到16年一方面業務體系繁多,支援更多生态業務，第二個是否能做到更智能化，直到17年全鍊路壓測的鉑金輸出，18年又加入開源方向，支援了Jmeter類型壓測，19年性能測試與高可用領域的子產品的深度融合。
PTS經過十多年的沉澱，逐漸形成當今的成熟平台。
為什麼要做性能測試？
性能測試-驅動力1
①價格和複雜度：分布式業務複雜度高，任何業務有可能成為一個瓶頸；
②業務量擠壓非常大：比如線上教育、線上問診業務量特别大；
③覆寫範圍，貼合真實的業務場景：工具、壓測模型要求流量更加真實，更加貼合業務場景，從客戶測模拟。
性能測試-驅動力2
④壓測方式：更加貼合真實業務場景，包含三種方式：引流，日志回放，全構造，一般會通過第三種方式來做。
⑤全場景：包括全場景壓測，必須全場景覆寫，業務模型比較完整，要有容量規劃或者容量評估的主線在，主要目的是發現問題在哪，得出自己的瓶頸點在哪，做優化主要是最後得出容量到底是什麼樣子；
⑥簡&強：第一點：對于全場景的要求，主要是多角色的時候都需要有一個簡單的操作在；
第二點：流量必須真實存在；第三點：形成一塊閉環操作。
在不同的測試規模，以及對應的壓測階段會産生的相關問題，基于此，形成了如下模型：
總結：可以看到，非生産環境，一般發現的是代碼類問題，比如說GC，記憶體，洩露或者配置做的可能不好，那麼在生産環境會發現更多系統化，調用鍊路或者更多通用層面的問題，比如說負載均衡的問題。
對上述所有内容的總結分如下四大驅動力來總結：
第一點：分布式環境分布式環境，分布式架構導緻瓶頸點有可能在A，也有可能在B,就會導緻無法在黑盒環境下來看到具體問題在哪，就需要做分布式環境下的壓測，除此之外，分布式還展現在壓縮平台的伸縮性；
第二點：雲化，本地維護成本高；
第三點：移動網際網路，業務連續性要求高，包括業務不能中斷，搶斷市場比較滞後；
第四點：DevOps，操作成本非常低，有更好的體驗。
性能測試的價值：
①品牌保障體驗以及營銷體驗；
②洪峰流量或者大促，資料上來看，每0.1s的體驗延時，會有10%的營收比例降低；
③成本人力以及伺服器資源成本，如果可以簡便評估目前的容量成本，在容量規劃成本上會有大幅度降低。
如果做容量評估應該怎麼做：
容量評估分為三步：
第一步:壓測方法
①架構梳理；②确定目标以及方法；③測試準備：資料準備，模型準備；④Checklist記錄：在關鍵時刻應該做什麼事情。
第二步：工具選型
①：開源；②：SaaS産品。
第三步：場景壓測
①構造方式；②壓測模式；③定位方法。
開源和SaaS如何選擇（以JMeter為例）：
開源工具：開源工具本身具有其特點，協定支援範圍比較廣，是支援一些自定義的方法；
自研平台：對自身來說，對于源代碼有一個比較深入的了解或者深入的熟悉過程，并且自研平台對于一些特殊的協定進行适配，但是在人力/資源成本、維護成本都比較高，并且穩定性也比較弱，如果原碼版本有疊代，是否要跟着繼續疊代；
PTS中JMeter的支援：高并發能力，流量可以按照真實的地域來發起，以及PTS自身有自己的采樣日志，其次也透漏了JMeter的錯誤日志。
用SaaS的工具相對成本以及成本效益都比較高。
壓測報告中的一些日志記錄：
上文主要講述了JMeter平台的有關知識，PTS最核心能力的主要是自研的一個引擎，阿裡巴巴雙11活動主要用到的引擎，目前常用的主要用兩套引擎，一套是自研的，另外一套是JMeter原生的。自研的引擎是純UI編輯的形式，不需要涉及0代碼，本地也不需要維護一些東西，隻需要維護資料檔案即可。
從流程介紹性能測試服務的能力：
從壓測的階段來分析PTS的能力：
雲端錄制：配置好代理，在pc上邊操作就可錄制下來。
從功能上來說：如圖
SLA：服務協定，在某次壓測時，可以定義壓測服務對應的服務等級協定是什麼，比如rt不能超過500ms，成功不能低于四個九，如果低于的話則可以做告警或者停止壓測，這樣就可以在壓測的過程中幫助你監測壓測過程的準确性。
定時壓測：多用于預約或者定時的周期執行的工作，比如說每個月定時會有大促活動，基本每周疊代一次，前一天可以疊代幾分鐘，第二天對疊代結果進行分析就行，包括結合SLA中的服務等級協定，設定好狀态成功率，則可以實作無人值守的工作。
壓測過程中會有一些問題：如下
除圖上列出的問題之外，還有預估與實際可能有差異，比如在春節期間，線上教育使用者量可能會有所增加，那麼會在春節之前就線上教育方面會有所擴容，但是會可能會出現意料之外的情況，比如疫情，那麼就線上教育來說，肯定要再繼續擴容以應對突增的使用者，但是具體要擴增多少，并且擴容之後如果還出現問題那麼要加一些防護措施。
出現問題之後處理時一定要高效，并且要在多層次多元度上處理問題。
三．AHAS流量防護
由2018年雙十一相關資料來看：如圖
從圖上資料可以得出兩點:
①量級很大；②時間非常短。
那麼就要做好如果一旦出現問題的時候，對于客戶的影響情況，如果問題沒有得到及時處理，使用者可能就會退出界面。
洪峰流量：
Sential的誕生：以雙十一的經典界面為例。如下圖所示：該圖展現的是雙十一活動中出現的經典界面，是為了限流。為了避免峰值過來時導緻系統的雪崩，以保證大部分使用者的體驗。是以有了流量防護的工具。
Sential是什麼？
Sential是一款面向分布式架構的輕量級控制架構，主要以流量為切入點，從以下幾個次元保護系統及服務的穩定性：
①流量控制 ②熔斷降級 ③流量整形 ④系統保護
以下述架構為例來進行相關說明：
網關層面：在網關層面可以做一些流量控制，分布式架構應用本身是叢集化的，不同的應用本身之間會有調用，那就可以在應用級别做一些流量化的塑形，這個可以應用在錯峰相關上。
适用場景：
①電商業務類，存在大促、秒殺等場景
②資訊類業務，社會熱點帶來不可預知的突發流量
③直播、視訊類業務，線上觀看連接配接數徒增
④突然出現來自某個ip的大量流量
⑤可能會出現刷單的情況，搶占了正常商品的流量
⑥需要自動識别并限制某些過熱流量
那麼在進行流量防護時都要考慮什麼因素？
①允許通路的速率
②爆發量
③爆發間隔時間
接下來我們來看一下熔斷降級的相關知識：
經過的鍊路越多，小明失敗的機率就越高。
在被保護的應用發現有部分應用掉了，其中有一個應用異常，那麼就會選擇将這個應用降級掉，來保證其他服務的正常運作。也就是說，鍊路中某個資源不穩定時，對該資源調用進行限制。
傳統的系統負載保護：根據硬名額做，但是硬名額具有延遲性，浪費了系統的處理能力；系統的恢複速度慢。進而導緻以下問題：調節具有延遲性；恢複慢。
進而産生新的過載保護算法:如下圖所示：
提出新的算法，需要結果來進行驗證，如圖：
對比了效果之後，我們來看一下性能的相關資訊：
本文由社群志願者整理而成，設區内容志願者火熱招募中，有好禮相贈哦。歡迎加入！
戳我了解詳情加入！