企業上雲如何優化性能？

• 2020 年 1 月 16 日
• 筆記

​​應用系統上線運行後，隨著系統數據量的不斷增長、訪問量的不斷上升，系統的響應速度通常會越來越慢，尤其日常峰值情況下常不能滿足業務需要，甚至出現應用服務中斷的現象，給企業造成巨大的品牌損失和經濟損失。大量數據表明，每0.1秒的核心體驗響應時間延長會導致1%的營收下降。企業應用系統上雲，如何在雲端利用雲的優勢進行性能優化，是一個值得深入分析的重點問題。

性能優化的價值與策略

1、性能優化價值

性能是一個應用系統最重要的指標，除非沒有選擇，否則沒有用戶會忍受一個響應緩慢的應用系統或網站。大量數據表明，每0.1秒的核心體驗響應時間延長會導致1%的營收下降。

應用系統上線運行後，隨著系統數據量的不斷增長、訪問量的不斷上升，系統的響應速度通常會越來越慢，尤其峰值情況下常不能滿足業務需要，甚至出現應用服務中斷，給企業造成巨大的品牌損失和經濟損失，因此性能優化會顯得至關重要。

通過性能優化，可以用更少的硬體資源，支撐更大量的業務發展，從而達到節省硬體成本的目的；同時，可以在有限資源的情況下，提升系統的響應能力，為用戶帶來更好的使用體驗，促進業務增長。

2、性能優化策略

對於應用系統來說，用戶從瀏覽器發出請求到資料庫完成事務操作，中間需要經過很多環節，如果系統響應慢，必須對請求經過的各個環節進行分析，排查可能出現性能瓶頸的地方，定位問題。

排查瓶頸的方法通常是檢查請求處理的各個環節的日誌，分析哪個環節響應時間不合理、超出預期；然後檢查監控數據，分析影響性能的主要因素是CPU，還是記憶體、磁碟、網路等基礎設施資源的問題，還是架構設計的問題，或是慢SQL語句的問題等。

定位出導致性能問題的具體原因後，再做針對性的性能優化。

雲上性能優化體系

1、性能優化體系

性能優化，簡而言之，就是在不影響系統運行正確性的前提下，使之運行的更快，完成特定功能所需的時間更短。

性能優化的維度很多，綜合來看可以從下面五個方面展開性能優化：資源層、架構層、應用層、資料庫層、中間件層。性能優化體系如下圖：

2、資源層優化

雲資源層的優化包括雲資源水平方向和垂直方向擴展，資源層面優化的依據可來自雲監控的量化指標數據。

雲監控可實時監控雲資源動態指標，是所有雲產品的監控管理總入口。可以通過雲監控查看最全、最詳細的監控數據。雲監控能夠實時對雲伺服器、雲資料庫、負載均衡等雲產品進行監控，提取雲產品關鍵指標，以監控圖表形式展示。可以通過使用雲監控全面地了解資源使用率、應用程式性能和雲產品運行狀況。

水平方向擴展是增加雲伺服器、雲資料庫等實例數量，垂直方向擴展是升級雲伺服器、雲資料庫等雲資源的規格配置，比如CPU、記憶體、磁碟、頻寬等參數配置，從解決資源瓶頸的角度來優化系統的訪問性能。

3、架構層優化

系統的性能問題也有可能是系統架構設計不合理造成的。比如在架構設計上，沒有考慮做讀寫分離、資料庫分庫分表、動靜分離、CDN加速、快取加速、彈性伸縮等。

讀寫分離與資料庫分庫分表解決的是資料庫訪問性能問題，在雲上實現讀寫分離非常方便，創建只讀實例後，在應用程式中配置讀寫分離地址，就可以使寫請求自動轉發到主實例，讀請求自動轉發到各個只讀實例。

動靜分離、CDN加速、快取解決的是靜態文件或熱點數據快速讀取問題，比如圖片、影片、熱門商品、庫存等等，企業上雲時需要儘可能使用一些成熟的雲原生解決方案，從架構設計層面去優化訪問性能的問題。

彈性伸縮解決的是應用伺服器自動擴展的問題，通過提前配置伸縮規則與策略，在業務需求增長時自動增加雲伺服器實例以保證計算能力，避免訪問延時和資源超負荷運行。

4、應用層優化

應用層優化的關鍵是首先快速診斷出應用的問題瓶頸。

互聯網業務的高速發展帶來了日益增長的流量壓力，業務邏輯也日趨複雜，傳統的單機應用已經無法滿足需求。越來越多的網站或系統逐漸採用了分散式部署架構。

同時，隨著 Spring Cloud/Dubbo 等基礎開發框架不斷成熟，越來越多的企業開始對應用架構按照業務模組進行垂直拆分，形成了更適合團隊協同開發、快速迭代的微服務架構。

分散式的微服務架構在開發效率上具備先進性，但給傳統的監控、運維、診斷技術帶來了巨大挑戰。主要挑戰包括：

定位問題難：

微服務分散式架構一個業務請求通常要經過多個服務/節點後返回結果，一旦請求出現錯誤，往往要在多台機器上反覆翻看日誌才能初步定位問題，對簡單問題的排查也常常涉及多個團隊。

發現瓶頸難：

當用戶回饋系統出現卡頓現象，很難快速發現瓶頸在哪裡：是用戶終端到服務端的網路問題，是服務端負載過高導致響應變慢，還是資料庫壓力過大？即使定位到了導致卡頓的環節，也很難快速定位到程式碼層面的根本原因。

架構梳理難：

在業務邏輯變得逐漸複雜以後，很難從程式碼層面去梳理某個應用依賴了哪些下游服務（資料庫、HTTP API、快取），以及被哪些外部調用所依賴。業務邏輯的梳理、架構的治理和容量的規劃也變得更加困難。

通常，需要使用性能壓測工具（比如PTS）、應用實時監控服務（比如ARMS）等工具，基於前端、應用、業務自定義等維度進行鏈路追蹤，實現完整的調用鏈路還原、調用請求量統計、鏈路拓撲和應用依賴分析等。鏈路追蹤能夠幫助快速分析和診斷分散式應用架構下的性能瓶頸，提高微服務時代下的開發診斷效率。

定位瓶頸問題後，展開針對性的優化工作，比如優化慢SQL語句、優化調用報錯程式程式碼、優化調用異常API等。通常應用優化後可結合性能壓測工具對系統性能、容量水位進行再次壓力測試，通過壓測結果進一步分析系統瓶頸，對應用不斷迭代優化。

5、資料庫優化

影響資料庫系統性能主要有如下幾個因素：系統的硬體配置、資料庫文件的物理分布、資料庫實例的參數、資料庫的物理設計、應用的SQL語句。

資料庫性能優化，首先需要進行下述數據內容採集：

系統軟硬體環境：包括伺服器的作業系統設置、硬體配置、網路配置、軟體環境、啟動選項、進程資訊、性能資訊、磁碟使用情況等。

硬體運行情況：包括CPU、記憶體、磁碟、網路的運行數據。

資料庫實例的配置： 實例配置參數。

資料庫配置：包括恢復模式、自動收縮、空間增長等資訊。

資料庫磁碟使用：包括資料庫大小、表大小、記錄數、索引大小、佔用空間等。

索引及碎片情況：包括表上的索引、索引的碎片情況、索引的維護計劃等。

SQL語句執行情況：包括SQL 語句執行時間、啟動時間、所在資料庫、語句內容、死鎖、阻塞等情況。

應用程式運行狀況：包括系統高峰時段、晚間的資料庫維護任務、用戶報告比較慢的業務、系統運行特點。

資料庫性能主要優化項見下圖：

6、中間件優化

在資訊系統中，不少性能問題是由不起眼的應用中間件造成的。應用中間件之所以誕生，是為了幫助應用程式的編碼人員處理與業務邏輯沒有太大關係而又必須處理的經常性事物，比如處理應用程式和資料庫之間的關係，設置開啟多少個session來處理客戶請求，session的超時時間等等。

然而在享受便利的同時，應用中間件也會成為系統性能問題的締造者，開發人員和測試人員往往忽視了中間件本身對性能的影響，這種影響包括交易吞吐量的制約、響應時間的影響、交易成功率的影響等等。

中間件優化的目標是把耗費在中間件的時間縮短（提升用戶體驗），提高整個應用伺服器的吞吐量。中間件優化，調什麼參數，一定要了解其含義、原理、調整後的收益和風險是什麼，最好是N個參數能在腦子裡纏繞為一個整體。

高優先：調整JDBC連接池大小、執行緒池、JVM虛擬機的heap size。

中優先：會話數、垃圾回收GC策略。

另外還有高速快取、數據源語句快取大小。

不當的配置也會導致中間件處於假死狀態。比如某類資源（session或jdbc）被應用完全佔滿了，並且短期不釋放，這樣新的請求就沒法執行，造成了假死的情況。這類情況，要做好超時放棄的參數配置。

性能優化的進一步思考

性能優化是一個複雜的系統工程，首先需要定位性能瓶頸，然後從雲資源、系統架構、應用程式、資料庫、中間件等方面進行綜合分析和優化；性能優化的最終目的是為了改善用戶的體驗，離開這個目的而追求技術上的所謂高性能是捨本逐末，沒有任何意義。

隨著系統數據量、訪問用戶量的不斷增加，以及系統功能的不斷迭代，系統需要持續進行性能優化，性能優化是一場持久戰，只有這樣才能讓用戶擁有更好的訪問體驗，從而支撐業務增長。

作者：龔華兵