程序員必須掌握的性能調優 X Y Z

時間 2020-01-12

原文原文鏈接

熱評好文：如何設計出優美的Web API？，現閱讀量超過了2500，小夥伴們不要錯過哦！
思否地址：如何設計出優美的Web API？，堅持技術寫做不易，小夥伴們記得點個贊哦！html

2003 ~ 2008 年，這五年老兵哥我在通訊行業作實習生和開發崗，主要用 C / C++ / MFC 開發嵌入式 / 服務器 / 桌面等應用程序，期間作過大量代碼重構優化，但不多涉及性能調優，要麼我負責的局部無需考慮併發訪問和海量數據，要麼網管平臺僅供客戶內部人員使用，不存在併發訪問和海量數據。2008 年末，老兵哥我跳槽到了移動互聯網作技術經理，隨後五年主要用 Java / C++ 開發 Web / 服務器等互聯網應用。程序員

當時，架構師這個崗位在業界仍是很罕見的，不懂預估併發用戶、業務數據等規模，天然就預見不到後續併發訪問和海量數據會帶來巨大的性能挑戰。咱們趕着工期把功能需求實現、業務流程跑通，而後就上線了，但移動互聯網爆發的那些年業務增加很是快，系統上線不久就遇到性能問題了，其現象就是原來耗時很短的操做如今動不動就超時，或者界面刷不出來數據等等，巨大的壓力跟着客戶投訴一塊兒擺到了我面前。面試

性能調優任務不像普通開發任務，它須要揹負業務、時間和難度等多種壓力。羅馬不是一天建成的，致使性能問題的緣由錯綜複雜，當時老兵哥我也不知道從何處下手，找不到解決問題的切入點。好性能不是調優出來的，更可能是設計出來的。只有經歷過性能調優，才能體會這句話的真諦。性能調優，其實就是對承載業務的現網系統作重構優化，就像是邊開車邊換輪胎，它所須要的技能跟代碼重構徹底不在一個層級上。數據庫

如今老兵哥我知道，性能是系統性問題，性能調優離不開架構視角。不識廬山真面目，只緣身在此山中。當你陷在具體的、局部的問題當中，你是沒法找到解決問題的思路的。你必須從實現細節跳脫出來，從更加宏觀全局的視角來梳理業務流程，就像前面系列文章《圖解 Spring Cloud：HTTP 請求的處理流程與機制》的剖析過程相似，而後以業務流程爲線索分析每一個環節存在的性能瓶頸緣由，這樣你就再也不困惑了。segmentfault

當每一個環節潛在問題梳理出來以後，根據資源、時間等外部限制，按照帕累託二八原則，你能夠決定優先解決哪些問題，從而有條不紊地化解性能壓力了。隨着在性能調優上的經驗不斷豐富，你就愈來愈有信心掌控更大規模的系統了。更值得高興的是，當你費老牛勁把這些本身挖的巨坑填上後，你就記得下次不要再給本身挖坑了，也就懂得怎樣設計一個高性能的互聯網系統了，這不就是從開發躍遷至架構的契機嗎？瀏覽器

性能調優，是從開發崗躍遷至架構崗的攔路虎。升級思惟的過程是痛苦的，尤爲是在揹負壓力下的被動升級，跳出原先的溫馨區，進入更大的溫馨區，這樣才能站上新平面。記得當時老兵哥我還有很多負面情緒，回顧過往才懂得要感謝當時的領導給我這份壓力，逼迫我高強度學習並突破了舊的思惟，機會和挑戰是並存的。緩存

性能優化是一個不斷迭代、持續進行的過程，涉及軟件開發生命週期的全部階段，對於某款採用 Hibernate 做爲持久層框架的 Java EE 典型應用程序，性能優化會涉及如下幾個方面：性能優化

業務規則調優，包括業務流程、交互設計等
應用容器調優，包括啓動參數、鏈接數和線程數等
Spring 調優，包括事務管理、二級緩存等
Hibernate 調優，包括批量操做、抓取策略和緩存等
數據庫調優，包括索引、SQL 語句和配置等
JVM 調優，包括內存、垃圾回收 GC等
底層系統調優，包括操做系統、硬件等

若是對上述性能優化方向作些分類歸併，咱們能夠採用下列分類維度來看：服務器

X 維度，即業務維度，技術始終是服務業務的，任何技術問題的原點就是業務需求。在啓動技術層面的性能優化以前，咱們有必要先審視一下業務流程是否合理，交互設計上有沒有能夠優化的空間等。
Y 維度，待業務維度優化完畢，接下來就是審視技術在實現當前業務流程或交互設計的全鏈路上有沒有可優化的地方，即 HTTP 請求處理全流程，從瀏覽器到應用容器，再到 Spring、Hibernate、數據庫等。

Z 維度，除了沿着 HTTP 請求的橫向鏈路，咱們還要審視支持應用系統的縱向技術棧，從上到下包括 JVM、操做系統和硬件等，這是整套應用系統運行的環境，許多性能問題都跟運行環境存在關係。

XYZ 維度分類是從不一樣層次梳理性能優化方向，有助於幫咱們搭建起了性能優化的框架體系，這三個維度跟應用架構也是一一對應的。除了按照層次、縱橫分類以外，咱們還能夠按性能優化對象的粒度劃分，將優化範圍分爲函數、模塊、框架、系統、鏈路和環境等等，從開發崗到架構師，咱們就是要練就從小粒度到大粒度優化的能力，跳脫出原來的思惟框架，站到更寬廣的視角來選擇優化路線。若是你沒有精心設計優化方案就開始上述調優，這將會是很是耗時的，並且極可能收效甚微。一個好的優化方案必然要爲各類調優任務劃分優先級，任什麼時候候都不可能有足夠的時間和資金作全面優化，優先級的判斷依據是投入產出比。在肯定了優先級以後，接下來咱們就按照帕累託 Pareto 定律（即 80/20 法則）來選取調優任務，集中百分之八十的力量去改善應用程序中最影響性能的百分之二十的問題。架構

今天先分享到這裏，後續老兵哥我把這些調優經驗和架構視角梳理出來供你們參考。堅持技術寫做不容易，若是你以爲有價值，麻煩動動手指點下文「點贊」按鈕，讓更多小夥伴能夠看到，我也會更加有動力堅持分享。另外，老兵哥我後續還會分享職業規劃、應聘面試、技能提高、影響力打造等經驗，歡迎關注本專欄或公衆號「IT老兵哥」，賦能程序人生！