企業上雲如何優化性能？

應用系統上線運行後，隨着系統數據量的不斷增加、訪問量的不斷上升，系統的響應速度一般會愈來愈慢，尤爲平常峯值狀況下常不能知足業務須要，甚至出現應用服務中斷的現象，給企業形成巨大的品牌損失和經濟損失。大量數據代表，每0.1秒的核心體驗響應時間延長會致使1%的營收降低。企業應用系統上雲，如何在雲端利用雲的優點進行性能優化，是一個值得深刻分析的重點問題。

性能優化的價值與策略

一、性能優化價值

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

應用系統上線運行後，隨着系統數據量的不斷增加、訪問量的不斷上升，系統的響應速度一般會愈來愈慢，尤爲峯值狀況下常不能知足業務須要，甚至出現應用服務中斷，給企業形成巨大的品牌損失和經濟損失，所以性能優化會顯得相當重要。

經過性能優化，能夠用更少的硬件資源，支撐更大量的業務發展，從而達到節省硬件成本的目的；同時，能夠在有限資源的狀況下，提高系統的響應能力，爲用戶帶來更好的使用體驗，促進業務增加。

二、性能優化策略

對於應用系統來講，用戶從瀏覽器發出請求到數據庫完成事務操做，中間須要通過不少環節，若是系統響應慢，必須對請求通過的各個環節進行分析，排查可能出現性能瓶頸的地方，定位問題。

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

定位出致使性能問題的具體緣由後，再作針對性的性能優化。

雲上性能優化體系

一、性能優化體系

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

性能優化的維度不少，綜合來看能夠從下面五個方面展開性能優化：資源層、架構層、應用層、數據庫層、中間件層。性能優化體系以下圖：

二、資源層優化

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

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

水平方向擴展是增長雲服務器、雲數據庫等實例數量，垂直方向擴展是升級雲服務器、雲數據庫等雲資源的規格配置，好比CPU、內存、磁盤、帶寬等參數配置，從解決資源瓶頸的角度來優化系統的訪問性能。

三、架構層優化

系統的性能問題也有多是系統架構設計不合理形成的。好比在架構設計上，沒有考慮作讀寫分離、數據庫分庫分表、動靜分離、CDN加速、緩存加速、彈性伸縮等。

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

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

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

四、應用層優化

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

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

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

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

定位問題難：

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

發現瓶頸難：

當用戶反饋系統出現卡頓現象，很難快速發現瓶頸在哪裏：是用戶終端到服務端的網絡問題，是服務端負載太高致使響應變慢，仍是數據庫壓力過大？即便定位到了致使卡頓的環節，也很難快速定位到代碼層面的根本緣由。

架構梳理難：

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

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

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

五、數據庫優化

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

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

系統軟硬件環境：包括服務器的操做系統設置、硬件配置、網絡配置、軟件環境、啓動選項、進程信息、性能信息、磁盤使用狀況等。

硬件運行狀況：包括CPU、內存、磁盤、網絡的運行數據。

數據庫實例的配置： 實例配置參數。

數據庫配置：包括恢復模式、自動收縮、空間增加等信息。

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

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

SQL語句執行狀況：包括SQL 語句執行時間、啓動時間、所在數據庫、語句內容、死鎖、阻塞等狀況。

應用程序運行情況：包括系統高峯時段、晚間的數據庫維護任務、用戶報告比較慢的業務、系統運行特色。

數據庫性能主要優化項見下圖：

六、中間件優化

在信息系統中，很多性能問題是由不起眼的應用中間件形成的。應用中間件之因此誕生，是爲了幫助應用程序的編碼人員處理與業務邏輯沒有太大關係而又必須處理的常常性事物，好比處理應用程序和數據庫之間的關係，設置開啓多少個session來處理客戶請求，session的超時時間等等。

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

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

高優先：調整JDBC鏈接池大小、線程池、JVM虛擬機的heap size。

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

另外還有高速緩存、數據源語句緩存大小。

不當的配置也會致使中間件處於假死狀態。好比某類資源（session或jdbc）被應用徹底佔滿了，而且短時間不釋放，這樣新的請求就無法執行，形成了假死的狀況。這類狀況，要作好超時放棄的參數配置。

性能優化的進一步思考

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

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

做者：龔華兵

優質文章

jmeter集羣下腳本日誌和報告處理

企業應用運維自動化應該如何設計？

域內計算機本地管理員密碼管理