性能分析優化的道與術
前言
之前有很多同學問我，性能測試中到底該如何去定位分析瓶頸並進行性能優化？感覺壓測場景設計做的很全面，分析工具也用了很多，但一直無法快速的定位分析並進行優化。
性能分析和優化一直是技術領域熱門的一個話題，無論是三高（高性能、高可用、高穩定），還是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個給其他業務；
- 業務身份：中台架構可通過業務身份把訂單秒殺等應用打上標記，便於隔離區分；
