作者 | 蔣帆

“摩爾定律”的暫時(shí)終結(jié)與《性能之巔》的復(fù)活

《性能之巔（第二版）Systems Performance: Enterprise and the Cloud》中文版在去年重裝上市，作為一本磚頭書，輾轉(zhuǎn)于Solaris、Netflix、Intel的性能分析專家 Brandon Gregg 帶來了許多基于最新實(shí)踐經(jīng)驗(yàn)的性能檢測方法和工具使用建議。

與此同時(shí)，這次發(fā)布的第二版還引入了Linux社區(qū)在eBPF等可觀測性技術(shù)迭代下的最新進(jìn)展，我們可以看到在追求無盡的算力增長的態(tài)勢隨著制程工藝和產(chǎn)能的艱難爬升逐漸遇到了瓶頸，過去兩年貪婪地享受著逐年翻倍的晶體管數(shù)與總線速率以及廉價(jià)能源的程序員們終于意識(shí)到了可（內(nèi)）持（卷）續(xù)發(fā)展的必然性，開始更多地站在計(jì)算機(jī)體系結(jié)構(gòu)的視角看待我們的架構(gòu)設(shè)計(jì)、算法、數(shù)據(jù)架構(gòu)，觀察其是否充分利用好了底層的能力和資源。

開發(fā)者“都應(yīng)該”知道的延時(shí)數(shù)字

https://colin-scott.github.io/personal_website/research/interactive_latency.html

從性能分析的黃金60秒到“持續(xù)性能看護(hù)”工程

與其他非功能性需求（譬如安全）不同，性能分析的契機(jī)，除了來自成本中心對硬件開銷的警告，可能也因?yàn)槠涑３Ｓ绊懙接脩趔w驗(yàn)，而遭到用戶的投訴，尤其是突如其來的性能劣化降級(jí)，常常是伴隨著大量用戶增長的喜悅中的夢魘。

Brandon在Netflix期間，一直在負(fù)責(zé)性能問題處理的工作，因此他總結(jié)了一些自己在工作中提升效率的常見手段，其中“黃金60秒”就代表了他在觀察各級(jí)別系統(tǒng)性能指標(biāo)的核心步驟。

從平均負(fù)載、到上下文切換頻率、再到IO、網(wǎng)絡(luò)性能指標(biāo)，黃金60秒所涵蓋的系統(tǒng)性能指標(biāo)實(shí)際上表達(dá)了工作負(fù)載的近期利用率，當(dāng)出現(xiàn)資源瓶頸時(shí)，往往會(huì)引發(fā)性能降級(jí)甚至雪崩性的問題。

但是這樣的分析方式，往往需要依賴大量的專家經(jīng)驗(yàn)，以及運(yùn)維人員對系統(tǒng)設(shè)計(jì)的熟知程度，盡管我們認(rèn)為DevOps應(yīng)該具有對系統(tǒng)架構(gòu)的深刻認(rèn)識(shí)，但是這在很多企業(yè)仍然是一種較為困難的場景，7x24小時(shí)運(yùn)維團(tuán)隊(duì)并非對開發(fā)者所熟知的系統(tǒng)架構(gòu)那么熟悉，而性能調(diào)優(yōu)更需要對細(xì)致的軟件運(yùn)作原理有較為深刻的認(rèn)識(shí)，這對于需要保證系統(tǒng)穩(wěn)定運(yùn)行的運(yùn)維團(tuán)隊(duì)來說，無疑增加了負(fù)擔(dān)，因此我們也看到性能優(yōu)化常常作為一種非功能性的需求，經(jīng)由生產(chǎn)環(huán)境的用戶反饋或是在運(yùn)維團(tuán)隊(duì)的降本增效會(huì)議中被強(qiáng)調(diào)，這也非常有意思地體現(xiàn)出性能相關(guān)責(zé)任的邊界模糊特點(diǎn)。

在一些客戶場景下，我們也看到另一個(gè)方向的探索，我們可以稱之為“持續(xù)性能看護(hù)”，這項(xiàng)活動(dòng)常常與另一個(gè)更抽象的概念“架構(gòu)守護(hù)”有著異曲同工的執(zhí)行形式。性能數(shù)據(jù)的量化指標(biāo)，成為每個(gè)產(chǎn)品在研發(fā)測試各環(huán)節(jié)的關(guān)鍵門檻，它就像測試覆蓋率、測試bug報(bào)告單，被內(nèi)建到了開發(fā)者熟悉的環(huán)節(jié)，這有些類似過去我們在談?wù)撥浖|(zhì)量問題時(shí)，常常提到的“質(zhì)量左移”、“在持續(xù)集成中加入U(xiǎn)T如何幫助質(zhì)量提升”。

持續(xù)地使用高強(qiáng)度的壓測用例對產(chǎn)品進(jìn)行性能方面的數(shù)據(jù)標(biāo)定，可以幫助開發(fā)團(tuán)隊(duì)時(shí)刻了解產(chǎn)品的資源使用情況，這種方式，既可以對后續(xù)產(chǎn)品演進(jìn)的架構(gòu)方向提出要求和規(guī)約，也可以為硬件采購計(jì)劃提供量化指標(biāo)支撐。

作為一種新形式的性能優(yōu)化工程實(shí)踐，我們建議每個(gè)企業(yè)都可以考慮構(gòu)建自己的性能指標(biāo)庫，并持續(xù)跟蹤研發(fā)環(huán)節(jié)產(chǎn)品各版本的性能趨勢，這可以大大節(jié)約由于過晚進(jìn)行性能優(yōu)化，導(dǎo)致的技術(shù)回撤甚至影響發(fā)布后的用戶體驗(yàn)。

性能看護(hù)過程，持續(xù)對性能劣化問題點(diǎn)進(jìn)行及時(shí)報(bào)告

性能優(yōu)化專家系統(tǒng)的崛起

伴隨著硬件資源瓶頸的日益凸顯，持續(xù)對產(chǎn)品進(jìn)行性能優(yōu)化成了繼續(xù)維持產(chǎn)品生命周期、迭代與發(fā)展新品類的一條路徑。

我們在一些客戶現(xiàn)場，正觀察到一個(gè)有趣的現(xiàn)象，積累了大量性能優(yōu)化經(jīng)驗(yàn)的專家正逐漸成為團(tuán)隊(duì)的明星，因?yàn)檫@一知識(shí)的積累，需要具備眾多技術(shù)棧的扎實(shí)經(jīng)驗(yàn)，并且熟知各類可互相替換組件的性能特性與適用場景，尤其是與硬件或嵌入式軟件相關(guān)的應(yīng)用場景，性能優(yōu)化專家也成為了各個(gè)產(chǎn)品線爭搶的競爭性資源，成為性能專家的路線常常需要常年的學(xué)習(xí)與總結(jié)，需要廣闊的視野和深入系統(tǒng)實(shí)現(xiàn)細(xì)節(jié)和算法原理的研究性能力。因此如何更好地協(xié)助性能專家服務(wù)更多的產(chǎn)品，如何提升性能優(yōu)化的效率，以及如何把這些知識(shí)經(jīng)驗(yàn)以更低的成本傳授給一線的開發(fā)團(tuán)隊(duì)，便成為了性能優(yōu)化體系建設(shè)過程中的關(guān)鍵問題。

此外，隨著對復(fù)雜系統(tǒng)認(rèn)知的不斷升級(jí)，我們也看到通過知識(shí)庫積累可以產(chǎn)生一些可以參考的性能分析的方法路徑，我們將這些分析方法過程總結(jié)成知識(shí)圖譜，并對新手產(chǎn)生足夠的指引，并通過性能可觀測性平臺(tái)，形成更加順暢的體驗(yàn)。

使用性能分析圖譜的方式來積累分析方法與經(jīng)驗(yàn)

積累性能優(yōu)化方面的思路，我們也總結(jié)了一些分析優(yōu)化模式，這些經(jīng)驗(yàn)可以大大加速我們在觀察系統(tǒng)整體性能并制定出方案的效率。

6個(gè)常見的性能反模式與優(yōu)化方向

關(guān)于性能工程平臺(tái)流程方法的構(gòu)建，我們也與一些存儲(chǔ)、通信、車載等領(lǐng)域的客戶開展了試點(diǎn)項(xiàng)目，通過逐層遞進(jìn)的分析流程，我們看到一個(gè)類似IDE的多功能集成環(huán)境，它可能包括了我們在前面提到的觀測手段與工具，高亮并及時(shí)提醒性能劣化的問題點(diǎn)，并提供可參考的優(yōu)化建議，可能未來會(huì)成為性能分析工具的一種常見形式。

使用集成分析環(huán)境承載性能分析過程，進(jìn)行系統(tǒng)性能逐層遞進(jìn)地分析

非功能性系統(tǒng)工程實(shí)踐的下一階段

隨著功能性需求的長期積累，大量功能堆砌過程中缺乏對非功能性問題的關(guān)注和專項(xiàng)設(shè)計(jì)，導(dǎo)致量變引起質(zhì)變，最終形成質(zhì)量和性能差異。越來越多的復(fù)雜遺留系統(tǒng)中，性能問題或穩(wěn)定性問題得以集中暴露。這并非單純的質(zhì)量管理缺失所致，而是復(fù)雜系統(tǒng)中積累大量業(yè)務(wù)上下文的結(jié)果。這些問題給開發(fā)團(tuán)隊(duì)帶來了許多負(fù)擔(dān)，也為工程實(shí)踐領(lǐng)域帶來了機(jī)遇。相信越來越多的復(fù)雜系統(tǒng)開發(fā)者將會(huì)逐漸重視這個(gè)領(lǐng)域，形成更優(yōu)秀的工程方法或工具，幫助我們更好地駕馭復(fù)雜系統(tǒng)。