一提起軟體系統中的效能問題，或許你首先想到的是 CPU 使用率過高或者記憶體占用率太大，進而致使程式執行速度變慢。此時，關註點往往只停留在軟體實作層面的效能調優上。實際上，這種以最小化資源占用為導向的效能最佳化，其核心目標是降低成本。
然而，對於產品來說，最為關鍵的其實是從客戶視角所關註的業務效能，比如使用者的平均響應時延、99% 的使用者響應時延分布等。這類效能最佳化的核心目標是提升使用者體驗，增強產品的行業競爭力。
但問題在於，在互聯網服務領域，從客戶視角去定位分析業務的效能問題存在一定挑戰，主要原因有兩點：
- 針對一些存在業務效能問題的場景，其系統內的服務或元件並不一定處於飽和狀態，所以無法直接從系統資源級監控中辨識出問題。
- 如果只是個別服務或元件處於飽和狀態，往往可以透過彈性擴充套件來更快地提升效能體驗，所以這種情況也不是最棘手的效能問題。
再來看看嵌入式領域，以無線通訊領域為例，存在很多業務效能最佳化非常苛刻的場景，如 FTP 下載速率最佳化、速度平穩沒有毛刺最佳化等。在這類系統的實作過程中，導致出現業務效能問題的原因會更多更復雜，問題可能發生在鏈路上的任何一個網元裝置內，或者具體裝置內的任何一個軟體元件或硬體單元上。因此，定位分析業務層效能問題的挑戰會更大。
事實上，定位分析業務的效能問題是很多程式設計師都很頭疼的問題。它需要你具備很高的業務能力，包括對業務流程的熟悉度、對軟體架構及軟體內實作邏輯的理解程度，甚至是對作業系統和硬體原理都要有深入的理解。不過，就我的實踐經驗來看，即使掌握了這些資訊，如果沒有系統的定位分析方法的指導，依舊很難定位出效能問題。
所以，今天這節課我會給你分享一套效能調優方法論，帶你理解企業套用系統架構的整體邏輯和工作流程，在此基礎上了解引起效能問題的潛在軟硬體瓶頸點，最後介紹系統分析定位的方法。基於這個方法，當你再碰到比較棘手的業務效能問題時，就可以做到有的放矢，使用這套系統定位分析方法去解決真實的效能問題。
好了，下面我們就來了解下系統的整體架構。
系統架構檢視
為了能更好地分析與定位復雜的效能問題，你首先需要理解整個系統架構檢視，其核心主要包含這三層：產品業務模型、軟體系統架構、元件或服務實作，如下圖中所示：
圖片
產品業務模型：這是系統對外提供的業務功能與邏輯。以購物流程為例，其對外提供的功能邏輯為：瀏覽商品 —> 添加購物車 —> 檢視庫存 —> 支付 —> 發快遞等。這實際上是站在使用者視角所感知到的與系統發生互動的過程。這個業務模型是軟體業務領域建模階段的重要產物，也是每個系統級產品都應包含的模型。
軟體系統架構：它表示的是整個軟體系統到具體元件或服務之間的拆分邏輯，以及元件或服務間的互動關系，如圖中的 A、B、C、E、F 等。這些軟體執行單元可以是一個微服務例項，也可以是一個元件例項，它們會透過通訊與互動支撐實作復雜的業務功能。實際上，不管是嵌入式領域還是互聯網領域，軟體系統架構設計本質上都是對業務功能拆解的一個過程，透過拆碎形成具有獨立清晰邊界的、更小的軟體執行單元。
元件或服務實作：這是元件或服務的內部程式碼實作，它會依托於行程、內核、硬體的協作來完成核心的業務功能。我們知道，系統的業務效能是由硬體、作業系統、軟體實作以及之上的業務流程綜合決定的。當我們碰到業務效能問題時，會基於系統的架構檢視從上到下進行分析，最後總能找到具體的制約效能的瓶頸點。
那麽，如果你可以提前認識軟硬體中常見的一些效能瓶頸點，了解它們對系統效能的影響，就能夠幫助你更加準確地分析業務效能問題。但是，很多程式設計師在定位效能問題時，喜歡只聚焦到某個點上持續最佳化，而這個點可能並不是效能瓶頸，所以最後很難有比較好的效果。那麽，系統潛在的效能瓶頸點都有哪些呢？接下來，我們就一起來看看。
潛在的效能瓶頸點
首先，一般來說，效能瓶頸通常是由一些關鍵資源使用過度所引起的，並且不同資源使用到達瓶頸（飽和）狀態對效能產生的影響和規律各不相同。在電腦系統中，每種硬體資源，如 CPU、Cache、記憶體、磁盤、網路介面、匯流排等，都有可能成為效能瓶頸。這是因為當硬體處理到達飽和狀態時，會直接導致硬體上的軟體執行效能下降，最終使得業務效能受到影響。
相比之下，軟體實作所導致的效能問題及影響很容易被忽略。所以今天，我會重點介紹由於軟體實作而引起業務效能問題的瓶頸點，以便在你分析業務效能問題的過程中，更好地辨識和發現這些問題。
序列資源受限
第一類典型的瓶頸問題是序列資源（或互斥資源），這是一種可能觸發業務效能問題的軟體實作方式。下圖為序列資源的擴充套件對效能影響的模型圖，它展示了隨著業務規模的擴大，對效能所造成的影響。
圖片
如圖中左側所示，由於序列資源是有限的，隨著業務請求量的增加，當資源使用飽和後，會導致請求處理吞吐量到達峰值後便無法再提升。同時，如圖的右側所示，當序列資源使用飽和後，平均處理時延也會因排隊或者阻塞而不斷拉長。在軟體實作中，對效能影響較大的序列資源種類有很多，從粒度從小到大可以包括：互斥鎖、並列設計中的序列部份、系統依賴的不可延伸的服務或介面等，它們都有著相似的影響。但需要註意的是，在業務場景中，還有不少資源數目是大於等於 2 的情況，比如執行緒池、資料庫連線池、其他不能無限擴充套件的服務或介面。這種有限軟體資源的場景，它們對效能的影響與序列資源對效能的影響較為類似，所以同樣可以參考序列資源對效能影響的分析檢視。
緩沖類資源訊息溢位
第二種容易引發效能問題的軟體實作是緩沖類資源，像緩沖區、訊息佇列、訊息中介軟體等都歸屬於緩沖類資源。緩沖技術能夠實作削峰填谷的機制，從而平滑上遊和下遊處理速度之間的差異。如下圖所示，倘若緩沖區設定過小，當上遊請求到達峰值時，可能會致使部份請求被阻塞或者丟棄，進而影響到業務效能。而如果緩沖區設定得越大，其實作削峰填谷的能力就會更強。
但如果緩沖區設定得過大，也會造成記憶體資源的浪費，所以緩沖區大小設定對效能的影響也很關鍵。
緩存命中率過低
緩存技術在軟體實作層面是一項重要的效能最佳化手段，同時也可能成為影響業務效能的潛在因素。我們了解到，在緩存的使用中有一個關鍵指標，即緩存命中率，其計算公式為緩存命中個數除以（緩存命中個數與緩存未命中個數之和）。這個指標對業務效能的影響如下圖所示
圖片
軟體 Bug
最後，軟體實作中存在一個對效能有著極大影響的因素 —— 軟體 Bug。在以往對業務效能問題進行定位分析的過程中，由軟體 Bug 導致的效能問題並不在少數。例如，程式碼本應是批次處理操作，卻因處理錯誤退化為迴圈呼叫；又或者在運用緩存技術時，由於緩存 Key 構造錯誤，使得緩存永遠無法命中，進而引發業務效能驟然下降等情況。
然而，看到這裏，你或許會產生疑問：是不是所有的業務效能問題都是由軟硬體層面的資源效能瓶頸所觸發的呢？在我看來，並非如此。有些效能問題可能源於業務模型或者流程本身的問題，軟體和硬體僅僅是其載體。例如，業務中的某些限速策略會致使處理效能受到限制。另外，在一些更為復雜的系統業務設計中，也可能會引入效能問題，這就如同設計不合理的十字路口紅綠燈一般，會導致嚴重的擁堵狀況。不過，對於這種因業務模型等因素引發的效能問題，我們其實可以透過調整紅綠燈時間，也就是調整軟體不同模組的業務職責和介面實作，從而顯著改善擁堵現象。
總而言之，在軟體實作的過程中，可能引發潛在效能問題的因素眾多。鑒於此，我們需要系統的分析定位方法作為指導，否則將很難準確辨識出系統中的所有效能瓶頸點。
所以接下來，我們就一起探討下這個系統分析定位方法吧。
系統分析定位法
實際上，用於分析定位效能問題的方法有不少。像 USE 方法，也就是從檢查各類資源、觀察其使用率飽和的角度去探尋可能存在的效能瓶頸；還有從下往上逐步分析系統中資源使用指標的方法來尋找效能瓶頸。另外，還有隨機變動訛方法（這是一種先隨機猜測再進行驗證的方法）、科學實驗法等等。當面對特定的效能問題時，或許每種定位分析方法的效果都不一樣。不過呢，今天我要向你介紹的這種方法，是我依據以往分析各類效能問題所積累的經驗總結出來的一種方法思路。它相對比較系統，而且效率較高，當你在遭遇各種業務領域的效能問題時，都可以運用這種方法。具體如下圖所示。
圖片
整個定位分析方法從上到下分為三層，分別是業務模型分析、軟體架構分析以及元件或服務實作分析。下面逐一為你介紹。
一、業務模型分析
業務模型分析的目標是找出引發業務效能問題的業務觸發點，並對分析的正確性進行驗證。越是復雜的業務模型，導致業務效能問題出現的根本原因可能就越難以察覺。如果在業務模型分析中確定的根本原因不準確，那麽後續投入再多精力進行深入分析也將是徒勞無功。例如，在分析 TCP 流量下降的效能問題時，可能是下行鏈路出了問題，也可能是上行鏈路存在問題。如果上行鏈路延遲增大，導致 ACK 反饋不及時，進而觸發擁塞控制，使得 TCP 流量不高。在這種情況下，即便在下行鏈路上花費巨大精力去分析，也不會有任何效果。所以，驗證業務層效能問題根因分析的結論是否正確十分必要。在此，我建議你可以透過打樁的方式暫時規避根因觸發點，觀察效能問題是否有所改善，以此作為有效的驗證手段。當然，不同系統的業務模型差異很大，所以業務模型沒有通用的方法或規律可循，你只能憑借對業務邏輯的深入理解，並依據業務層實作的執行狀態監控資訊來進行分析。當完成業務模型分析後，你會發現導致效能問題的原因可能是由某個具體的業務流程引起的。這時，你就可以針對這個具體業務流程，深入到軟體架構中進一步分析。
二、軟體架構分析
在軟體架構分析中，我們主要依靠軟體架構中元件或服務的介面互動關系來進行分析。通常對於大型的系統級產品來說，元件或服務間介面的互動資訊一定是可以被監控、獲取並進行分析的。這樣，根據獲取的介面互動監控資訊，我們能夠找到觸發業務效能問題的具體元件或服務。此外，和業務模型分析一樣，我們在軟體架構分析階段辨識出的存在效能瓶頸的元件或服務，也需要進一步驗證。只有在確保分析結果正確後，才能進行下一階段的深入分析。我以前在通訊領域從事效能問題分析時，每個子系統元件都是由不同的團隊開發維護的。當面對復雜的業務效能問題時，我需要沿著子系統元件的介面邊界逐步排查分析，將效能問題交接給下一個子系統元件，並提供充足的分析與驗證資訊。但即使在這樣的情況下，仍然可能出現分析錯誤導致返工的情況。所以這一點你一定要註意。
三、軟體內部份析
事實上，在互聯網業務領域分析效能問題時，無論是業務模型分析階段還是軟體架構分析階段，驗證分析結論正確性的過程都很容易被我們忽視，從而導致效能問題分析定位出現返工或錯誤。根據我的實踐經驗，當定位到具體的某個元件存在效能瓶頸時，我們就需要深入到這個元件內部去分析其具體實作，檢視這個元件是否存在之前提到的效能瓶頸點，比如序列資源、緩存、軟體 Bug 等，並根據分析結果給出最佳化建議。最後，當所有的效能瓶頸點都被解決後，你還需要再次驗證效能問題是否得到改善。如果沒有改善，那麽你可能需要重新審視分析過程，或者尋找其他可能的效能瓶頸點。
如何在真實的數據分析業務中套用這套方法論？
這是我曾經處理線上數據分析業務中碰到的真實效能問題，當時產品有部份使用者投訴，在 Web 頁面中的查詢數據下載功能效能很差，造成使用者等待時間長。而我采用的就是這套效能定位方法，具體定位過程如下圖所示：
圖片
第一階段：進行業務模型分析，以辨識出存在效能問題的業務流程。在互聯網服務領域，許多業務的效能問題是由使用者發現的，然而在其他業務領域中，業務效能瓶頸點則需要依靠業務領域的監控統計，並結合業務模型共同分析才能辨識出來。就這個案例而言，系統中可能包含眾多的業務流程。在業務模型分析階段，我們確定了存在效能問題的業務流程為 「查詢數據下載功能」。具體的使用者業務流程是：先選擇查詢條件，接著查詢返回數據，然後生成壓縮數據，再上傳至物件儲存，最後生成下載連結。之後，我們便可以依據這個業務流程，去尋找並定位那些引入效能瓶頸的元件和服務。
第二階段：處於軟體架構分析階段時，我們能夠根據存在效能問題的業務流程，找到由軟體導致效能瓶頸的元件和服務。在這個階段，主要運用系統的微服務間的介面日誌進行分析，主要基於 Elasticsearch+Kibana 工具，沿著業務請求介面鏈路去尋找具體的元件或者服務，最終將效能問題定位到一個確定的微服務元件中。
第三階段：進行元件或服務內實作分析。在此階段，深入到導致效能問題的微服務中，透過檢視內部實作的相關監控或統計資訊，發現導致效能問題的原因是：壓縮數據處理與瀏覽統計邏輯使用了相同的計算任務佇列。由於之前的突發瀏覽業務，使得佇列中積攢了許多待處理的瀏覽統計任務，進而導致壓縮數據處理任務被排隊阻塞，時延變長。這樣一來，經過仔細分析後我們會發現，因為使用者無法感知到瀏覽統計邏輯，而壓縮數據處理對使用者來說卻比較敏感，所以在這裏使用同一個任務佇列，就造成了非關鍵業務邏輯對核心業務的處理時延產生了影響。
更多資訊，點選全場景直播解決方案-航天雲網解決方案
