高可用DevHa實踐，告訴你生產環境0性能故障是如何作到的！

導讀：近日，數列科技CTO陸學慧參加ArchSummit全球架構師峯會，並進行了題爲《0性能故障是如何作到的：高可用性能領域的DevHA實踐》的主題演講，詳細介紹了0性能故障的實踐經驗及對應解決方案，如下爲演講摘錄。

在正式開始以前分享一個小故事 ：夏天來了，我前段時間在深圳發現已經有蚊子了，晚上睡覺燈一關，就聽到身邊有嗡嗡嗡的聲音，想起來打死蚊子，但等我把燈打開，就找不到那個蚊子了。這種經歷，你們應該都會有！

這跟我今天講的性能瓶頸，它很是相似，咱們都知道系統裏面必定有性能的瓶頸。但它具體在哪裏，若是不畫一個範圍的話，很是難找到這個性能的瓶頸。找到以後去優化它，相信不少架構師同窗都是沒有問題的，但這難就難在咱們找不到它。

從7次故障，到連續兩年0故障

咱們能夠先看一組性能實踐數據！
這是咱們服務的一家客戶從2018年到2020年的數據。在2018年的時候，它的生產環境性能故障有7次，影響時長超過500分鐘。從2018年開始着手作生產環境的全鏈路壓測，到2020年接入了全部的應用，一直在持續不斷的進行這種全鏈路壓測，保證在生產環境上沒有了性能故障。接下來看看咱們是怎麼作到的。

性能故障頻發，核心問題在哪裏？

這個客戶2016年推出了一塊新業務，增加比較快速，當時他面臨的幾個問題，第一個是系統老，第二個是它需求迭代特別快，第三就是新人比較多。

這個就是當時他們面臨的一個現狀。性能故障這麼多，若是永遠被動的去響應去解決，那可能永遠都解決不完。因此咱們須要從這些複雜的現象裏面抓住一些核心矛盾點，並持續地解決掉，纔有可能把控整個的局面。

當咱們分析完整個的現狀以後，就發現了他們最多見的故障緣由就是數據庫，它數據庫的性能故障佔了一半以上。其中還發現了一個頗有意思的數據，可能你們日常都沒怎麼注意，就是數據庫的硬件成本基本上會佔整個除了大數據以外的其餘硬件總和50%以上。但機器的數量並無那麼多，因此數據庫的計算資源是很是昂貴的，也是常常出問題地方。

第二個主要矛盾點，就是性能測試周期特別長，成本也很高。

當時這個公司它的性能團隊有8我的，整個機器成本差很少是450萬，3年均攤下來每一年差很少在150萬的成本。早上順豐科技架構委員會負責人劉潭仁有分享他們作壓測的時候硬件成本差很少2000萬左右，因此傳統的性能測試，它成本是很高的。

另外，對於老闆、CIO、CTO來講，最關注最頭疼的就是週期比較長，提一個性能需求排期排到兩週以上，這就意味着只有提早規劃好的大項目才能作性能壓測。像平常迭代原本我只有一週的時間去開發，根本沒有能力去作性能測試，致使生產環境的故障頻發。

第三個主要矛盾的就是大促的這種性能的保障靠架構師團隊的人拍腦殼。他缺少能夠客觀衡量生產環境我容量的手段，只能依靠經驗判斷難以找到性能瓶頸與優化方向。

3大核心問題，該如何解決？

跟大部分公司技術團隊同樣，內部相關人員作了不懈努力，架構師升級了分佈式數據庫，使得系統擁有超強計算力；業務端作了架構優化、系統重構，以此提升性能；針對核心鏈路資源提供獨立保障……儘管你們作的很好，但是性能問題依舊存在。

咱們這邊當時給出來的一個解決思路就是三步走：

第一步針對這種數據庫的問題，咱們當時並無說把引入分佈式的數據庫做爲一個核心原則，而是經過優化它的計算架構去給數據庫減負，其實就跟給小學生減負同樣，少佈置點做業讓他有更多的時間來處理好應該作的一件事情。

第二步就是作生產環境的全鏈路壓測。

第三步你們可能以爲很是更恐怖，就是暴力破解式高頻壓測。這主要就是爲了持續的去保障線上沒有性能問題，那咱們就必須保證一個高頻的壓測態勢。就像咱們剛纔說蚊子的這個問題，把這個門窗都關上，能夠把我屋子裏的蚊子都消滅掉，那一次性的沒問題，可是，咱們平常生活中常常會開窗開門，你過幾天發現蚊子又來了。 若是沒有一個持續性滅蚊手段的話，是不可能作到屋子裏沒有蚊子的，在系統裏面也是同樣。

那下面咱們看看這三步咱們當時都是怎麼走的？

1.優化計算架構進行數據庫減負

其實最核心的就兩步，第一步就是把TP類型的查詢計算跟AP類型的作資源隔離。

經過各類各樣的方式，能不用數據庫的儘可能就不用，由於數據庫的資源是很是寶貴。在作完這一步以後數據庫的負載降了不少，性能問題也下來了不少。

那第二步呢， 就是咱們須要去作一個簡單又可落地的SQL規範。這個SQL規範就是單SQL單表，作起來也很簡單，可是從一個不遵循單SQL單表架構開始去作到這一步，它的阻力仍是很是大的。

我記得當時這個客戶找上咱們，就是由於當時他們有一個系統上線上了一個禮拜都失敗，緣由就是數據庫資源競爭太厲害了。當時Oracl的專家提出上個XData花2000萬問題就解決了。

這個客戶經過朋友找到了咱們，咱們瞭解的狀況以後就提出，咱們有辦法能夠幫你持續的解決這個問題，不須要花費2000萬。咱們當時給出來的方案就是把他們那些幾百行的這種SQL全都拆掉，歷時一個多月，系統成功上線且數據庫的資源還有不少的剩餘。經過這個動做，咱們順利幫客戶省下了大約2000萬。

咱們作完這兩步以後，不少的性能問題已經被抑制下來了。

2.生產環境全鏈路壓測

客戶公司CTO當時提出了一個問題，今年的雙11系統還會不會掛？若是隻是作一些數據庫層面架構優化，其實很難回答這個問題。因而咱們給出了在生產環境作全鏈路壓測的第二步方案。好多人第一次聽到這個概念的時候內心會很是的不安——在生產環境萬一掛了怎麼辦？因此今天我會着重講一下安全問題。

其實生產全鏈路壓測的核心邏輯特別簡單。

首先就是壓測的流量要可識別，在任何一個節點均可識別，在任何處理的邏輯裏面，我都要能知道如今我處理的，究竟是一個壓測流量仍是一個生產流量。

第二點就是壓測的這個標籤，它要在微服務架構裏面不停的傳遞下去，不能說傳着傳着斷了，這時候也會出問題。

第三點很重要，就是壓測的數據要能夠隔離。不能把壓測產生的任何的數據跟業務產生的的數據混到一塊兒。

咱們要作壓測流量可識別其實比較簡單，以http流量爲例，咱們只須要在http的head裏面增長key value就能夠有效識別了。可是它難在怎麼在整個微服務的架構裏面傳下去，作到標籤傳遞這一點是有一些技術難度的。須要技術人員對公司所使用的全部中間件很是瞭解，而且沒有一個適用於全部中間件的一招鮮的方法，是須要根據不一樣中間件去定製傳遞方案的。

最後說說這種數據怎麼去作隔離，我這邊列舉了一些，不是很全。

好比消息系統能夠經過Topic進行隔離、搜索能夠經過索引進行隔離、數據庫能夠經過庫/表進行隔離。原理是比較簡單的，複雜與困難主要體如今一些技術細節上。

像咱們在作時候消息隔離時也出現過問題，這是一套消息系統rocket MQ的數據隔離流程，分爲消息的生產者、消費者以及服務器三大塊。經過Topic對正式和壓測的消息數據進行隔離，將壓測數據放進影子Topic裏，方案思路很簡單，後期對於壓測數據清理也好，維護也好，都很是簡單。但在試跑驗證時咱們發現有條壓測數據跑到線上去了，咱們也以爲很奇怪，按方案來講是不會出現這種狀況的。

後來經過排查發現那條數據造的有問題致使訂閱者在消費時失敗了，在RocketMQ裏消費失敗三次就會被放進重試隊列裏。在這以前咱們沒有考慮到這塊，只作了業務消息的影子Topic，因此這條數據在接收回來以後就被認定爲正常的業務消息，跑到線上去了。爲此咱們增長了重試隊列的影子Topic，問題順利解決。

講這個細節就是爲了說明數據隔離以及數據標籤傳遞當中都有許多技術細節，是須要技術人員對公司全部的中間件的細節都很是瞭解，否則就容易出現問題。

爲了保障系統的安全與穩定，除了剛纔說的在技術設計上的這種安全保障，整個全鏈路壓測前中後針對不一樣的點，咱們都有作不少的安全校驗。

我這邊就挑幾個例子給你們分享一下。好比說有一個叫作白名單的功能，它是幹嗎的呢？假設當咱們在作全鏈路壓測上線的時候，個人一條鏈路是 a 調b 調c 調 d，但因爲資源協調問題abcd並不能所有同時上線，只能a和b先上線，這時候就會出現問題，a和b能夠識別壓測流量，但c和d識別不了，那這部分流量就會成爲真實流量跑到線上去，白名單就是用來處理這種狀況的。咱們會把全部支持壓測的服務列表所有收集回來，再經過一個聚合的服務把它變成一些白名單的列表的配置，而後再分發下去，防止b的壓測流量進入c。

除此以外咱們還能夠提供監測的服務，E2E巡檢平臺能夠針對不一樣的場景設置RT值、錯誤率值等，一旦達到限定值就會自動中止壓測，作到一邊壓測一邊巡檢，出現問題就當即中止。

那經過這些手段，你們就能夠放心地在生產環境作這種全鏈路壓測，也能夠勇敢地回答前面CTO的問題——今年雙11不會掛！

3. 暴力破解式高頻壓測

除了雙十一、618這些大促節日以外，平常也可能會出現性能問題，咱們要去找出問題並優化，這時就要用到咱們說的暴力破解式高頻壓測。這裏面其實有一個很是重要的轉變，全鏈路壓測的同窗須要從支撐方變成運營方。這二者的區別在於支撐方是你給我提需求我去作，而運營方是我給你定標準你去作，而後我來檢查。

第一點須要去先去爭取到高層CTO或者說架構組領導的一些支持，讓你們願意去作這件事情，去成立一個性能運營的小組。第二點就是在初期推廣的階段，咱們要從一個支撐者變成一個倡導者，在公司裏面推廣這樣的新技術，架構師必定要多幫助業務線的同窗去幫他處理問題，去創建信任。

在高頻壓測的時候，咱們必定要想各類辦法去下降研發同窗的使用成本，好比說經過探針的方式，可讓開發同窗他不用去改任何代碼就能夠作壓測。

使用過程當中會遇到不少的問題，咱們將這些些問題所有沉澱到產品中開發了一系列工具去幫助開發快速上手完成工做。像壓測報告裏面內置了分析的模塊，能夠明確的告訴開發如今的性能與目標是否有差距。

這是我一開始給你們看的數據，還多加了2列數據——生產壓測接入數量和生產壓測次數。不難發現相比2018年，後兩年有一個很是大的數量提高，因此它能作到持續的生產環境性能零故障。

DevHa高可用展望

在將來高可用相關的技術、產品必定會蓬勃發展，以研發爲中心去構建整個生態。往後在生產仿真技術上確定也會有很大的提高，對於性能問題的處理方式也會由過後發現轉變爲事前主動發現故障並作出應對。平常會作相似暴力破解式高頻壓測這樣的事情，去保證系統持續的健壯，去保證一個準確高頻的反饋，好讓研發的同窗不斷的去優化。

數列科技成立於2016年，是國內領先的系統高可用專家，由多名阿里巴巴資深專家發起成立。旨在以解決微服務架構治理及性能問題爲核心，爲企業系統的性能和穩定性提供全方位保障，構建了覆蓋全鏈路壓測、E2E巡檢、故障演練等多模塊的完整產品矩陣，致力於幫助企業將系統可用性提高至99.99%。