前言
之前有很多同學問我，效能測試中到底該如何去定位分析瓶頸並進行效能優化？感覺壓測場景設計做的很全面，分析工具也用了很多，但一直無法快速的定位分析並進行優化。
效能分析和優化一直是技術領域熱門的一個話題，無論是三高（高效能、高可用、高穩定），還是CAP（資料一致性、服務可用性、分割槽容錯性），都強調了服務的效能和可用。
那麼在工作中，該如何去測試並進行效能優化呢？這篇文章，我來談談我對於效能分析和優化的一些理解。
請求是如何被處理的？
“工欲善其事，必先利其器；欲利其器，必曉其理”。
在進行效能分析優化之前，先來看看一個請求處理的生命週期圖。
如上圖所示，是常見的一個微服務分散式架構下的請求處理過程。
我們經常談的效能快和慢，實際上是一個相對的數值，它更多的是我們對於使用者使用系統時訪問速度體驗的評估。
因此在進行效能定位分析之前，一定要清楚請求經過了哪些鏈路環節？它們的耗時分別是多少？是否是正常數值區間？如果數值異常，可能的原因是什麼？
通過快速排除法，最終將效能分析和優化的點聚焦在一定範圍內，這樣才能快速的定位排查原因。
常見的效能問題與原因
看了上面的請求處理生命週期流程圖，可以得到下面幾點影響效能的因素。
網路頻寬
網路對效能的影響不言而喻。
如果頻寬不足，單位時間內的請求過多，就會導致資料包的傳輸延遲較大。
如果網路不穩定，也會導致RT的曲線抖動較為劇烈，產生毛刺甚至丟包，這個時候P90/P99的數值也可能變大。
因此穩定和足夠的網路頻寬，對系統的效能來說是很重要的。
負載均衡
現在的SLB層已經優化的足夠好，但如果負載均衡出現問題，可能會導致流量分發不均勻，導致部分應用節點流量異常，健康檢查不通過從而被踢下線。
甚至服務註冊重試失敗或者彈性擴容不夠及時，還會導致可用的節點承受了較多的請求最終導致雪崩效應。
安全策略
現在的軟體系統，常見的安全防護策略有ddos高防以及WAF，一般都是部署在SLB和流量閘道器之間或者更上層。
安全防護策略常見的場景有異常檢測、輸入驗證、安全補丁、狀態管理以及基於規則和異常的保護功能。
這些安全策略能夠有效的保護系統不受到一些惡意的攻擊和侵入，但這些策略生效也是需要耗費時間的。
流量閘道器
上面提到的幾個部分都可以看做是網際網路時代的基礎通用層，而閘道器是伴隨著微服務和容器化出現的，作為使用者流量的系統入口，閘道器也承擔了較多的功能，比如：
- 日誌
- 身份鑑權
- 灰度釋出
- 限流熔斷
- 可觀測性metrics
- 應用限流apm tracing
上述的功能，無論是身份鑑權還是可觀測性的metrics的實現，都需要耗費一定時間。
特別是對於請求的RT比較敏感的業務，對流量閘道器功能的耗時要求更為嚴格。
相關文章：基於Apache APISIX的全流量API閘道器統籌叢集流量
Web應用層
近幾年前後端分離的系統設計越來越多，web層更多的負責頁面的渲染展示和部分討好使用者的互動設計。
如何讓使用者更快的感知到他所感興趣的東西，這個時候CDN和快取就派上用場了。
利用CDN和快取的特性“就近載入”，讓使用者感知到的效能更快，也是效能優化領域很重要的一點。
APP應用層
前面講了web層負責頁面渲染展示和友好的互動，那App應用層（即我們常說的後端服務）則更多的負責邏輯計算。
邏輯計算是很吃資源的，當然和它的一些引數配置以及技術架構也有較大關聯。
常見的影響後端服務效能的因素如下：
- 硬體資源：如CPU/Memory；
- 引數配置：如Activethreads/TimeOut；
- 快取配置：快取中的大Key及快取命中率；
- 平行計算：請求下游依賴是序列還是並行？
- 程式碼邏輯：最經典的例子——for迴圈無線套娃；
- 日誌處理：特別是異常日誌的處理以及生產日誌級別；
- 處理機制：同步還是非同步？如果是非同步，MQ容量及消費能力如何？
推薦閱讀：認清效能問題
資料儲存層
資料儲存層我們通常理解為資料庫。資料庫層面影響效能的因素應該是最常見也是最多的。比如：
- 鎖：不合理的鎖使用導致的請求等待；
- 索引：未加索引或索引未生效導致慢SQL；
- 資料量：表資料量過大導致的讀寫變慢等問題；
針對業務擴張以及資料量變大的問題，常見的優化策略有分表、資料庫垂直拆分、讀寫分離等；
壓測不是發現問題的唯一手段
回到效能定位分析和優化的話題上，關於效能優化，如下三點是必須銘記的。
效能優化的目標
在保持和降低系統99%RT的前提下，不斷提高系統吞吐量，提高流量高峰時期的服務可用性。
效能優化的挑戰
- 日益增長的使用者量（帶來訪問量的提升，大資料量的儲存和處理）；
- 越來越多樣的業務（業務的不斷迭代和發展，會使其複雜性指數提升）；
- 越來越複雜的系統（為了支撐業務迭代發展，系統架構會變得很複雜）；
效能優化的路徑
- 降低響應時間；
- 提高系統吞吐量；
- 提高服務可用性；
PS：三者關係在某些場景下互相矛盾衝突，不可兼得！
效能優化的道法術器
基於上述關於效能優化的幾點內容，結合我個人的實踐經驗和看法，效能定位和分析分為下面四個境界。
- 道：熟悉業務邏輯，瞭解系統架構；
- 法：掌握技術原理，熟知問題定位和分析優化的軟體工程方法論；
- 術：不斷實踐踩坑，總結歸納效能驗證、定位分析的方法和經驗；
- 器：熟練使用效能測試、監控追蹤、問題分析和優化的各種工具並擅加利用；
如何讓系統執行的更快更穩定
時間空間
軟體系統的三高（高效能、高可用、高穩定）要求，歸根結底實際上需要在成本、收益、風險之間做取捨，我們很難做到用最低的成本達到最好的效果。
有個很早之前的優化理論，叫做“時間換空間，空間換時間”，講的就是在響應時間和硬體資源消耗之間做平衡。效能優化的關鍵在於平衡各部分元件的效能平衡點，
如果CPU資源有空閒，但是記憶體使用緊張，便可以使用時間換空間的策略，達到整體的效能優化；反之CPU資源緊張，記憶體資源有空閒，則可以使用空間換時間的策略，提升整體效能。
分層優化
請求的處理過程要經過多個鏈路環節，除了優化耗時最長難度和成本較低的環節之外，在每個環節都進行一定優化，則對整體效能的提升有很大幫助。下面是流量高峰時的一些優化或者說應對案例：
資料庫
- 擴容：DB是有狀態服務，計算層便於擴容，將DB節點放到容器中，有需要擴容；
- 災備：對於大流量讀場景可通過流量切換方式，將部分流量遷移到備份叢集分流；
- 巡檢：慢SQL是常見的問題，可通過自動監控和歷史資料分析，提供輔助式決策；
應用層(計算層)
- 限流：控制訪問應用的流量在系統承載範圍內
- 在業務請求入口（閘道器）限流，避免內部互相呼叫放大流量；
- 限流是個演進狀態，從連線池、IP、指定SQL到更細的層級粒度做限流；
- 每個呼叫層都做限流，每個應用先保證自己可用，對其他依賴呼叫要做到“零信任”；
- 降級：強依賴通過熔斷做緊急處理，弱依賴提前主動降級
- 主動降級：提前進行風險識別，然後針對性的降級，可降低已知的風險；
- 緊急降級：假設出現重大的問題，才需要決策是否啟用的方案（風險較大）；
- 預案平臺：預案平臺的目的是留痕，方便後續把限流降級等配置恢復回來；
- 熔斷：熔斷下游強依賴的服務
- 雙十一零點的前半小時， 做一個動態推送，把日誌關掉；
- 真正流量來的時候，留一臺機器來觀察錯誤和異常的日誌；
- 隔離：核心和非核心業務做隔離
身份識別和業務隔離案例如下：
- RPC group分組：假設有100個節點，40個給核心業務(交易)，60個給其他業務；
- 業務身份：中臺架構可通過業務身份把訂單秒殺等應用打上標記，便於隔離區分；