一提起軟件系統(tǒng)中的性能問(wèn)題，或許你首先想到的是 CPU 使用率過(guò)高或者內(nèi)存占用率太大，進(jìn)而致使程序執(zhí)行速度變慢。此時(shí)，關(guān)注點(diǎn)往往只停留在軟件實(shí)現(xiàn)層面的性能調(diào)優(yōu)上。實(shí)際上，這種以最小化資源占用為導(dǎo)向的性能優(yōu)化，其核心目標(biāo)是降低成本。

然而，對(duì)于產(chǎn)品來(lái)說(shuō)，最為關(guān)鍵的其實(shí)是從客戶視角所關(guān)注的業(yè)務(wù)性能，比如用戶的平均響應(yīng)時(shí)延、99% 的用戶響應(yīng)時(shí)延分布等。這類性能優(yōu)化的核心目標(biāo)是提升用戶體驗(yàn)，增強(qiáng)產(chǎn)品的行業(yè)競(jìng)爭(zhēng)力。

但問(wèn)題在于，在互聯(lián)網(wǎng)服務(wù)領(lǐng)域，從客戶視角去定位分析業(yè)務(wù)的性能問(wèn)題存在一定挑戰(zhàn)，主要原因有兩點(diǎn)：

1. 針對(duì)一些存在業(yè)務(wù)性能問(wèn)題的場(chǎng)景，其系統(tǒng)內(nèi)的服務(wù)或組件并不一定處于飽和狀態(tài)，所以無(wú)法直接從系統(tǒng)資源級(jí)監(jiān)控中識(shí)別出問(wèn)題。
2. 如果只是個(gè)別服務(wù)或組件處于飽和狀態(tài)，往往可以通過(guò)彈性擴(kuò)展來(lái)更快地提升性能體驗(yàn)，所以這種情況也不是最棘手的性能問(wèn)題。

再來(lái)看看嵌入式領(lǐng)域，以無(wú)線通信領(lǐng)域?yàn)槔嬖诤芏鄻I(yè)務(wù)性能優(yōu)化非?？量痰膱?chǎng)景，如 FTP 下載速率優(yōu)化、速度平穩(wěn)沒有毛刺優(yōu)化等。在這類系統(tǒng)的實(shí)現(xiàn)過(guò)程中，導(dǎo)致出現(xiàn)業(yè)務(wù)性能問(wèn)題的原因會(huì)更多更復(fù)雜，問(wèn)題可能發(fā)生在鏈路上的任何一個(gè)網(wǎng)元設(shè)備內(nèi)，或者具體設(shè)備內(nèi)的任何一個(gè)軟件組件或硬件單元上。因此，定位分析業(yè)務(wù)層性能問(wèn)題的挑戰(zhàn)會(huì)更大。

事實(shí)上，定位分析業(yè)務(wù)的性能問(wèn)題是很多程序員都很頭疼的問(wèn)題。它需要你具備很高的業(yè)務(wù)能力，包括對(duì)業(yè)務(wù)流程的熟悉度、對(duì)軟件架構(gòu)及軟件內(nèi)實(shí)現(xiàn)邏輯的理解程度，甚至是對(duì)操作系統(tǒng)和硬件原理都要有深入的理解。不過(guò)，就我的實(shí)踐經(jīng)驗(yàn)來(lái)看，即使掌握了這些信息，如果沒有系統(tǒng)的定位分析方法的指導(dǎo)，依舊很難定位出性能問(wèn)題。

所以，今天這節(jié)課我會(huì)給你分享一套性能調(diào)優(yōu)方法論，帶你理解企業(yè)應(yīng)用系統(tǒng)架構(gòu)的整體邏輯和工作流程，在此基礎(chǔ)上了解引起性能問(wèn)題的潛在軟硬件瓶頸點(diǎn)，最后介紹系統(tǒng)分析定位的方法?；谶@個(gè)方法，當(dāng)你再碰到比較棘手的業(yè)務(wù)性能問(wèn)題時(shí)，就可以做到有的放矢，使用這套系統(tǒng)定位分析方法去解決真實(shí)的性能問(wèn)題。

好了，下面我們就來(lái)了解下系統(tǒng)的整體架構(gòu)。

系統(tǒng)架構(gòu)視圖

為了能更好地分析與定位復(fù)雜的性能問(wèn)題，你首先需要理解整個(gè)系統(tǒng)架構(gòu)視圖，其核心主要包含這三層：產(chǎn)品業(yè)務(wù)模型、軟件系統(tǒng)架構(gòu)、組件或服務(wù)實(shí)現(xiàn)，如下圖中所示：

圖片

產(chǎn)品業(yè)務(wù)模型：這是系統(tǒng)對(duì)外提供的業(yè)務(wù)功能與邏輯。以購(gòu)物流程為例，其對(duì)外提供的功能邏輯為：瀏覽商品 —> 添加購(gòu)物車 —> 查看庫(kù)存 —> 支付 —> 發(fā)快遞等。這實(shí)際上是站在用戶視角所感知到的與系統(tǒng)發(fā)生交互的過(guò)程。這個(gè)業(yè)務(wù)模型是軟件業(yè)務(wù)領(lǐng)域建模階段的重要產(chǎn)物，也是每個(gè)系統(tǒng)級(jí)產(chǎn)品都應(yīng)包含的模型。

軟件系統(tǒng)架構(gòu)：它表示的是整個(gè)軟件系統(tǒng)到具體組件或服務(wù)之間的拆分邏輯，以及組件或服務(wù)間的交互關(guān)系，如圖中的 A、B、C、E、F 等。這些軟件運(yùn)行單元可以是一個(gè)微服務(wù)實(shí)例，也可以是一個(gè)組件實(shí)例，它們會(huì)通過(guò)通信與交互支撐實(shí)現(xiàn)復(fù)雜的業(yè)務(wù)功能。實(shí)際上，不管是嵌入式領(lǐng)域還是互聯(lián)網(wǎng)領(lǐng)域，軟件系統(tǒng)架構(gòu)設(shè)計(jì)本質(zhì)上都是對(duì)業(yè)務(wù)功能拆解的一個(gè)過(guò)程，通過(guò)拆分形成具有獨(dú)立清晰邊界的、更小的軟件運(yùn)行單元。

組件或服務(wù)實(shí)現(xiàn)：這是組件或服務(wù)的內(nèi)部代碼實(shí)現(xiàn)，它會(huì)依托于進(jìn)程、內(nèi)核、硬件的協(xié)作來(lái)完成核心的業(yè)務(wù)功能。我們知道，系統(tǒng)的業(yè)務(wù)性能是由硬件、操作系統(tǒng)、軟件實(shí)現(xiàn)以及之上的業(yè)務(wù)流程綜合決定的。當(dāng)我們碰到業(yè)務(wù)性能問(wèn)題時(shí)，會(huì)基于系統(tǒng)的架構(gòu)視圖從上到下進(jìn)行分析，最后總能找到具體的制約性能的瓶頸點(diǎn)。

那么，如果你可以提前認(rèn)識(shí)軟硬件中常見的一些性能瓶頸點(diǎn)，了解它們對(duì)系統(tǒng)性能的影響，就能夠幫助你更加準(zhǔn)確地分析業(yè)務(wù)性能問(wèn)題。但是，很多程序員在定位性能問(wèn)題時(shí)，喜歡只聚焦到某個(gè)點(diǎn)上持續(xù)優(yōu)化，而這個(gè)點(diǎn)可能并不是性能瓶頸，所以最后很難有比較好的效果。那么，系統(tǒng)潛在的性能瓶頸點(diǎn)都有哪些呢？接下來(lái)，我們就一起來(lái)看看。

潛在的性能瓶頸點(diǎn)

首先，一般來(lái)說(shuō)，性能瓶頸通常是由一些關(guān)鍵資源使用過(guò)度所引起的，并且不同資源使用到達(dá)瓶頸（飽和）狀態(tài)對(duì)性能產(chǎn)生的影響和規(guī)律各不相同。在計(jì)算機(jī)系統(tǒng)中，每種硬件資源，如 CPU、Cache、內(nèi)存、磁盤、網(wǎng)絡(luò)接口、總線等，都有可能成為性能瓶頸。這是因?yàn)楫?dāng)硬件處理到達(dá)飽和狀態(tài)時(shí)，會(huì)直接導(dǎo)致硬件上的軟件運(yùn)行性能下降，最終使得業(yè)務(wù)性能受到影響。

相比之下，軟件實(shí)現(xiàn)所導(dǎo)致的性能問(wèn)題及影響很容易被忽略。所以今天，我會(huì)重點(diǎn)介紹由于軟件實(shí)現(xiàn)而引起業(yè)務(wù)性能問(wèn)題的瓶頸點(diǎn)，以便在你分析業(yè)務(wù)性能問(wèn)題的過(guò)程中，更好地識(shí)別和發(fā)現(xiàn)這些問(wèn)題。

串行資源受限

第一類典型的瓶頸問(wèn)題是串行資源（或互斥資源），這是一種可能觸發(fā)業(yè)務(wù)性能問(wèn)題的軟件實(shí)現(xiàn)方式。下圖為串行資源的擴(kuò)展對(duì)性能影響的模型圖，它展示了隨著業(yè)務(wù)規(guī)模的擴(kuò)大，對(duì)性能所造成的影響。

圖片

如圖中左側(cè)所示，由于串行資源是有限的，隨著業(yè)務(wù)請(qǐng)求量的增加，當(dāng)資源使用飽和后，會(huì)導(dǎo)致請(qǐng)求處理吞吐量到達(dá)峰值后便無(wú)法再提升。同時(shí)，如圖的右側(cè)所示，當(dāng)串行資源使用飽和后，平均處理時(shí)延也會(huì)因排隊(duì)或者阻塞而不斷拉長(zhǎng)。在軟件實(shí)現(xiàn)中，對(duì)性能影響較大的串行資源種類有很多，從粒度從小到大可以包括：互斥鎖、并行設(shè)計(jì)中的串行部分、系統(tǒng)依賴的不可擴(kuò)展的服務(wù)或接口等，它們都有著相似的影響。但需要注意的是，在業(yè)務(wù)場(chǎng)景中，還有不少資源數(shù)目是大于等于 2 的情況，比如線程池、數(shù)據(jù)庫(kù)連接池、其他不能無(wú)限擴(kuò)展的服務(wù)或接口。這種有限軟件資源的場(chǎng)景，它們對(duì)性能的影響與串行資源對(duì)性能的影響較為類似，所以同樣可以參考串行資源對(duì)性能影響的分析視圖。

緩沖類資源消息溢出

第二種容易引發(fā)性能問(wèn)題的軟件實(shí)現(xiàn)是緩沖類資源，像緩沖區(qū)、消息隊(duì)列、消息中間件等都?xì)w屬于緩沖類資源。緩沖技術(shù)能夠?qū)崿F(xiàn)削峰填谷的機(jī)制，從而平滑上游和下游處理速度之間的差異。如下圖所示，倘若緩沖區(qū)設(shè)置過(guò)小，當(dāng)上游請(qǐng)求到達(dá)峰值時(shí)，可能會(huì)致使部分請(qǐng)求被阻塞或者丟棄，進(jìn)而影響到業(yè)務(wù)性能。而如果緩沖區(qū)設(shè)置得越大，其實(shí)現(xiàn)削峰填谷的能力就會(huì)更強(qiáng)。

但如果緩沖區(qū)設(shè)置得過(guò)大，也會(huì)造成內(nèi)存資源的浪費(fèi)，所以緩沖區(qū)大小設(shè)置對(duì)性能的影響也很關(guān)鍵。

緩存命中率過(guò)低

緩存技術(shù)在軟件實(shí)現(xiàn)層面是一項(xiàng)重要的性能優(yōu)化手段，同時(shí)也可能成為影響業(yè)務(wù)性能的潛在因素。我們了解到，在緩存的使用中有一個(gè)關(guān)鍵指標(biāo)，即緩存命中率，其計(jì)算公式為緩存命中個(gè)數(shù)除以（緩存命中個(gè)數(shù)與緩存未命中個(gè)數(shù)之和）。這個(gè)指標(biāo)對(duì)業(yè)務(wù)性能的影響如下圖所示

圖片

軟件 Bug

最后，軟件實(shí)現(xiàn)中存在一個(gè)對(duì)性能有著極大影響的因素 —— 軟件 Bug。在以往對(duì)業(yè)務(wù)性能問(wèn)題進(jìn)行定位分析的過(guò)程中，由軟件 Bug 導(dǎo)致的性能問(wèn)題并不在少數(shù)。例如，代碼本應(yīng)是批處理操作，卻因處理錯(cuò)誤退化為循環(huán)調(diào)用；又或者在運(yùn)用緩存技術(shù)時(shí)，由于緩存 Key 構(gòu)造錯(cuò)誤，使得緩存永遠(yuǎn)無(wú)法命中，進(jìn)而引發(fā)業(yè)務(wù)性能驟然下降等情況。

然而，看到這里，你或許會(huì)產(chǎn)生疑問(wèn)：是不是所有的業(yè)務(wù)性能問(wèn)題都是由軟硬件層面的資源性能瓶頸所觸發(fā)的呢？在我看來(lái)，并非如此。有些性能問(wèn)題可能源于業(yè)務(wù)模型或者流程本身的問(wèn)題，軟件和硬件僅僅是其載體。例如，業(yè)務(wù)中的某些限速策略會(huì)致使處理性能受到限制。另外，在一些更為復(fù)雜的系統(tǒng)業(yè)務(wù)設(shè)計(jì)中，也可能會(huì)引入性能問(wèn)題，這就如同設(shè)計(jì)不合理的十字路口紅綠燈一般，會(huì)導(dǎo)致嚴(yán)重的擁堵狀況。不過(guò)，對(duì)于這種因業(yè)務(wù)模型等因素引發(fā)的性能問(wèn)題，我們其實(shí)可以通過(guò)調(diào)整紅綠燈時(shí)間，也就是調(diào)整軟件不同模塊的業(yè)務(wù)職責(zé)和接口實(shí)現(xiàn)，從而顯著改善擁堵現(xiàn)象。

總而言之，在軟件實(shí)現(xiàn)的過(guò)程中，可能引發(fā)潛在性能問(wèn)題的因素眾多。鑒于此，我們需要系統(tǒng)的分析定位方法作為指導(dǎo)，否則將很難準(zhǔn)確識(shí)別出系統(tǒng)中的所有性能瓶頸點(diǎn)。

所以接下來(lái)，我們就一起探討下這個(gè)系統(tǒng)分析定位方法吧。

系統(tǒng)分析定位法

實(shí)際上，用于分析定位性能問(wèn)題的方法有不少。像 USE 方法，也就是從檢查各類資源、觀察其使用率飽和的角度去探尋可能存在的性能瓶頸；還有從下往上逐步分析系統(tǒng)中資源使用指標(biāo)的方法來(lái)查找性能瓶頸。另外，還有隨機(jī)變動(dòng)訛方法（這是一種先隨機(jī)猜測(cè)再進(jìn)行驗(yàn)證的方法）、科學(xué)實(shí)驗(yàn)法等等。當(dāng)面對(duì)特定的性能問(wèn)題時(shí)，或許每種定位分析方法的效果都不一樣。不過(guò)呢，今天我要向你介紹的這種方法，是我依據(jù)以往分析各類性能問(wèn)題所積累的經(jīng)驗(yàn)總結(jié)出來(lái)的一種方法思路。它相對(duì)比較系統(tǒng)，而且效率較高，當(dāng)你在遭遇各種業(yè)務(wù)領(lǐng)域的性能問(wèn)題時(shí)，都可以運(yùn)用這種方法。具體如下圖所示。

圖片

整個(gè)定位分析方法從上到下分為三層，分別是業(yè)務(wù)模型分析、軟件架構(gòu)分析以及組件或服務(wù)實(shí)現(xiàn)分析。下面逐一為你介紹。

一、業(yè)務(wù)模型分析

業(yè)務(wù)模型分析的目標(biāo)是找出引發(fā)業(yè)務(wù)性能問(wèn)題的業(yè)務(wù)觸發(fā)點(diǎn)，并對(duì)分析的正確性進(jìn)行驗(yàn)證。越是復(fù)雜的業(yè)務(wù)模型，導(dǎo)致業(yè)務(wù)性能問(wèn)題出現(xiàn)的根本原因可能就越難以察覺。如果在業(yè)務(wù)模型分析中確定的根本原因不準(zhǔn)確，那么后續(xù)投入再多精力進(jìn)行深入分析也將是徒勞無(wú)功。例如，在分析 TCP 流量下降的性能問(wèn)題時(shí)，可能是下行鏈路出了問(wèn)題，也可能是上行鏈路存在問(wèn)題。如果上行鏈路延遲增大，導(dǎo)致 ACK 反饋不及時(shí)，進(jìn)而觸發(fā)擁塞控制，使得 TCP 流量不高。在這種情況下，即便在下行鏈路上花費(fèi)巨大精力去分析，也不會(huì)有任何效果。所以，驗(yàn)證業(yè)務(wù)層性能問(wèn)題根因分析的結(jié)論是否正確十分必要。在此，我建議你可以通過(guò)打樁的方式暫時(shí)規(guī)避根因觸發(fā)點(diǎn)，觀察性能問(wèn)題是否有所改善，以此作為有效的驗(yàn)證手段。當(dāng)然，不同系統(tǒng)的業(yè)務(wù)模型差異很大，所以業(yè)務(wù)模型沒有通用的方法或規(guī)律可循，你只能憑借對(duì)業(yè)務(wù)邏輯的深入理解，并依據(jù)業(yè)務(wù)層實(shí)現(xiàn)的運(yùn)行狀態(tài)監(jiān)控信息來(lái)進(jìn)行分析。當(dāng)完成業(yè)務(wù)模型分析后，你會(huì)發(fā)現(xiàn)導(dǎo)致性能問(wèn)題的原因可能是由某個(gè)具體的業(yè)務(wù)流程引起的。這時(shí)，你就可以針對(duì)這個(gè)具體業(yè)務(wù)流程，深入到軟件架構(gòu)中進(jìn)一步分析。

二、軟件架構(gòu)分析

在軟件架構(gòu)分析中，我們主要依靠軟件架構(gòu)中組件或服務(wù)的接口交互關(guān)系來(lái)進(jìn)行分析。通常對(duì)于大型的系統(tǒng)級(jí)產(chǎn)品來(lái)說(shuō)，組件或服務(wù)間接口的交互信息一定是可以被監(jiān)控、獲取并進(jìn)行分析的。這樣，根據(jù)獲取的接口交互監(jiān)控信息，我們能夠找到觸發(fā)業(yè)務(wù)性能問(wèn)題的具體組件或服務(wù)。此外，和業(yè)務(wù)模型分析一樣，我們?cè)谲浖軜?gòu)分析階段識(shí)別出的存在性能瓶頸的組件或服務(wù)，也需要進(jìn)一步驗(yàn)證。只有在確保分析結(jié)果正確后，才能進(jìn)行下一階段的深入分析。我以前在通信領(lǐng)域從事性能問(wèn)題分析時(shí)，每個(gè)子系統(tǒng)組件都是由不同的團(tuán)隊(duì)開發(fā)維護(hù)的。當(dāng)面對(duì)復(fù)雜的業(yè)務(wù)性能問(wèn)題時(shí)，我需要沿著子系統(tǒng)組件的接口邊界逐步排查分析，將性能問(wèn)題交接給下一個(gè)子系統(tǒng)組件，并提供充足的分析與驗(yàn)證信息。但即使在這樣的情況下，仍然可能出現(xiàn)分析錯(cuò)誤導(dǎo)致返工的情況。所以這一點(diǎn)你一定要注意。

三、軟件內(nèi)部分析

事實(shí)上，在互聯(lián)網(wǎng)業(yè)務(wù)領(lǐng)域分析性能問(wèn)題時(shí)，無(wú)論是業(yè)務(wù)模型分析階段還是軟件架構(gòu)分析階段，驗(yàn)證分析結(jié)論正確性的過(guò)程都很容易被我們忽視，從而導(dǎo)致性能問(wèn)題分析定位出現(xiàn)返工或錯(cuò)誤。根據(jù)我的實(shí)踐經(jīng)驗(yàn)，當(dāng)定位到具體的某個(gè)組件存在性能瓶頸時(shí)，我們就需要深入到這個(gè)組件內(nèi)部去分析其具體實(shí)現(xiàn)，查看這個(gè)組件是否存在之前提到的性能瓶頸點(diǎn)，比如串行資源、緩存、軟件 Bug 等，并根據(jù)分析結(jié)果給出優(yōu)化建議。最后，當(dāng)所有的性能瓶頸點(diǎn)都被解決后，你還需要再次驗(yàn)證性能問(wèn)題是否得到改善。如果沒有改善，那么你可能需要重新審視分析過(guò)程，或者尋找其他可能的性能瓶頸點(diǎn)。

如何在真實(shí)的數(shù)據(jù)分析業(yè)務(wù)中應(yīng)用這套方法論？

這是我曾經(jīng)處理在線數(shù)據(jù)分析業(yè)務(wù)中碰到的真實(shí)性能問(wèn)題，當(dāng)時(shí)產(chǎn)品有部分用戶投訴，在 Web 頁(yè)面中的查詢數(shù)據(jù)下載功能性能很差，造成用戶等待時(shí)間長(zhǎng)。而我采用的就是這套性能定位方法，具體定位過(guò)程如下圖所示：

圖片

第一階段：進(jìn)行業(yè)務(wù)模型分析，以識(shí)別出存在性能問(wèn)題的業(yè)務(wù)流程。在互聯(lián)網(wǎng)服務(wù)領(lǐng)域，許多業(yè)務(wù)的性能問(wèn)題是由用戶發(fā)現(xiàn)的，然而在其他業(yè)務(wù)領(lǐng)域中，業(yè)務(wù)性能瓶頸點(diǎn)則需要依靠業(yè)務(wù)領(lǐng)域的監(jiān)控統(tǒng)計(jì)，并結(jié)合業(yè)務(wù)模型共同分析才能識(shí)別出來(lái)。就這個(gè)案例而言，系統(tǒng)中可能包含眾多的業(yè)務(wù)流程。在業(yè)務(wù)模型分析階段，我們確定了存在性能問(wèn)題的業(yè)務(wù)流程為 “查詢數(shù)據(jù)下載功能”。具體的用戶業(yè)務(wù)流程是：先選擇查詢條件，接著查詢返回?cái)?shù)據(jù)，然后生成壓縮數(shù)據(jù)，再上傳至對(duì)象存儲(chǔ)，最后生成下載鏈接。之后，我們便可以依據(jù)這個(gè)業(yè)務(wù)流程，去尋找并定位那些引入性能瓶頸的組件和服務(wù)。

第二階段：處于軟件架構(gòu)分析階段時(shí)，我們能夠根據(jù)存在性能問(wèn)題的業(yè)務(wù)流程，找到由軟件導(dǎo)致性能瓶頸的組件和服務(wù)。在這個(gè)階段，主要運(yùn)用系統(tǒng)的微服務(wù)間的接口日志進(jìn)行分析，主要基于 Elasticsearch+Kibana 工具，沿著業(yè)務(wù)請(qǐng)求接口鏈路去尋找具體的組件或者服務(wù)，最終將性能問(wèn)題定位到一個(gè)確定的微服務(wù)組件中。

第三階段：進(jìn)行組件或服務(wù)內(nèi)實(shí)現(xiàn)分析。在此階段，深入到導(dǎo)致性能問(wèn)題的微服務(wù)中，通過(guò)查看內(nèi)部實(shí)現(xiàn)的相關(guān)監(jiān)控或統(tǒng)計(jì)信息，發(fā)現(xiàn)導(dǎo)致性能問(wèn)題的原因是：壓縮數(shù)據(jù)處理與瀏覽統(tǒng)計(jì)邏輯使用了相同的計(jì)算任務(wù)隊(duì)列。由于之前的突發(fā)瀏覽業(yè)務(wù)，使得隊(duì)列中積攢了許多待處理的瀏覽統(tǒng)計(jì)任務(wù)，進(jìn)而導(dǎo)致壓縮數(shù)據(jù)處理任務(wù)被排隊(duì)阻塞，時(shí)延變長(zhǎng)。這樣一來(lái)，經(jīng)過(guò)仔細(xì)分析后我們會(huì)發(fā)現(xiàn)，因?yàn)橛脩魺o(wú)法感知到瀏覽統(tǒng)計(jì)邏輯，而壓縮數(shù)據(jù)處理對(duì)用戶來(lái)說(shuō)卻比較敏感，所以在這里使用同一個(gè)任務(wù)隊(duì)列，就造成了非關(guān)鍵業(yè)務(wù)邏輯對(duì)核心業(yè)務(wù)的處理時(shí)延產(chǎn)生了影響。