程式設計師必須掌握的效能調優 X Y Z
熱評博文：《如何設計出優美的Web API？》，現閱讀量超 2500，小夥伴們不要錯過哦！
2003 ~ 2008 年，這五年老兵哥我在通訊行業做實習生和開發崗，主要用 C / C++ / MFC 開發嵌入式 / 伺服器 / 桌面等應用程式，期間做過大量程式碼重構優化，但很少涉及效能調優，要麼我負責的區域性無需考慮併發訪問和海量資料，要麼網管平臺僅供客戶內部人員使用，不存在併發訪問和海量資料。2008 年底，老兵哥我跳槽到了移動網際網路做技術經理，隨後五年主要用 Java / C++ 開發 Web / 伺服器等網際網路應用。
當時，架構師這個崗位在業界還是很罕見的，不懂預估併發使用者、業務資料等規模，自然就預見不到後續併發訪問和海量資料會帶來巨大的效能挑戰。我們趕著工期把功能需求實現、業務流程跑通，然後就上線了，但移動網際網路爆發的那些年業務增長非常快，系統上線不久就遇到效能問題了，其現象就是原來耗時很短的操作現在動不動就超時，或者介面刷不出來資料等等，巨大的壓力跟著客戶投訴一起擺到了我面前。
效能調優任務不像普通開發任務，它需要揹負業務、時間和難度等多種壓力。羅馬不是一天建成的，導致效能問題的原因錯綜複雜，當時老兵哥我也不知道從何處下手，找不到解決問題的切入點。好效能不是調優出來的，更多是設計出來的。只有經歷過效能調優，才能體會這句話的真諦。效能調優，其實就是對承載業務的現網系統做重構優化，就像是邊開車邊換輪胎，它所需要的技能跟程式碼重構完全不在一個層級上。
現在老兵哥我知道，效能是系統性問題，效能調優離不開架構視角。不識廬山真面目，只緣身在此山中。當你陷在具體的、區域性的問題當中，你是無法找到解決問題的思路的。你必須從實現細節跳脫出來，從更加巨集觀全域性的視角來梳理業務流程，就像文末連結的系列文章《圖解 Spring Cloud：HTTP 請求的處理流程與機制》的剖析過程類似，然後以業務流程為線索分析每個環節存在的效能瓶頸原因，這樣你就不再困惑了。
當每個環節潛在問題梳理出來之後，根據資源、時間等外部限制，按照帕累託二八原則，你可以決定優先解決哪些問題，從而有條不紊地化解效能壓力了。隨著在效能調優上的經驗不斷豐富，你就越來越有信心掌控更大規模的系統了。更值得高興的是，當你費老牛勁把這些自己挖的巨坑填上後，你就記得下次不要再給自己挖坑了，也就懂得怎樣設計一個高效能的網際網路系統了，這不就是從開發躍遷至架構的契機嗎？
效能調優，是從開發崗躍遷至架構崗的攔路虎。升級思維的過程是痛苦的，尤其是在揹負壓力下的被動升級，跳出原先的舒適區，進入更大的舒適區，這樣才能站上新平面。記得當時老兵哥我還有不少負面情緒，回顧過往才懂得要感謝當時的領導給我這份壓力，逼迫我高強度學習並突破了舊的思維，機會和挑戰是並存的。效能優化是一個不斷迭代、持續進行的過程，涉及軟體開發生命週期的所有階段，對於某款採用 Hibernate 作為持久層框架的 Java EE 典型應用程式，效能優化會涉及以下幾個方面：
- 業務規則調優，包括業務流程、互動設計等
- 應用容器調優，包括啟動引數、連線數和執行緒數等
- Spring 調優，包括事務管理、二級快取等
- Hibernate 調優，包括批量操作、抓取策略和快取等
- 資料庫調優，包括索引、SQL 語句和配置等
- JVM 調優，包括記憶體、垃圾回收 GC等
- 底層系統調優，包括作業系統、硬體等
如果對上述效能優化方向做些分類歸併，我們可以採用下列分類維度來看：
- X 維度，即業務維度，技術始終是服務業務的，任何技術問題的原點就是業務需求。在啟動技術層面的效能優化之前，我們有必要先審視一下業務流程是否合理，互動設計上有沒有可以優化的空間等。
- Y 維度，待業務維度優化完畢，接下來就是審視技術在實現當前業務流程或互動設計的全鏈路上有沒有可優化的地方，即 HTTP 請求處理全流程，從瀏覽器到應用容器，再到 Spring、Hibernate、資料庫等。
- Z 維度，除了沿著 HTTP 請求的橫向鏈路，我們還要審視支援應用系統的縱向技術棧，從上到下包括 JVM、作業系統和硬體等，這是整套應用系統執行的環境，許多效能問題都跟執行環境存在關係。
XYZ 維度分類是從不同層次梳理效能優化方向，有助於幫我們搭建起了效能優化的框架體系，這三個維度跟應用架構也是一一對應的。除了按照層次、縱橫分類之外，我們還可以按效能優化物件的粒度劃分，將優化範圍分為函式、模組、框架、系統、鏈路和環境等等，從開發崗到架構師，我們就是要練就從小粒度到大粒度優化的能力，跳脫出原來的思維框架，站到更寬廣的視角來選擇優化路線。如果你沒有精心設計優化方案就開始上述調優，這將會是非常耗時的，而且很可能收效甚微。一個好的優化方案必然要為各種調優任務劃分優先順序，任何時候都不可能有足夠的時間和資金做全面優化，優先順序的判斷依據是投入產出比。在確定了優先順序之後，接下來我們就按照帕累託 Pareto 定律（即 80/20 法則）來選取調優任務，集中百分之八十的力量去改善應用程式中最影響效能的百分之二十的問題。
今天先分享到這裡，後續老兵哥我把這些調優經驗和架構視角梳理出來供大家參考。堅持技術寫作不容易，如果你覺得有價值，麻煩動動手指點下文 「 推薦 」按鈕，讓更多小夥伴可以看到，我也會更加有動力堅持分享。另外，老兵哥我後續還會分享職業規劃、應聘面試、技能提升、影響力打造等經驗，歡迎 關注 本專欄或歪信公主號 「 IT老兵哥 」！
關注「 IT老兵哥 」，賦能程式人生
- 軟技能-熱點文章：
- “花式”裁員套路深，你知道嗎？
- 遭遇裁員，如何渡過心理危機？
- 如何在寒冬中找到好工作？
- 2C 還是 2B，跟找工作有什麼關係？
- 大公司 vs 小公司，你會選哪個？
- 記住這一點，不怕找不到好工作！
- 跳槽，跳還是不跳，該怎麼跳？
- 程式設計師“求包養”攻略揭祕
- 很努力了，為什麼我還在原地踏步？
- 硬技能-熱點文章：
- 圖解 Spring：HTTP 請求的處理流程與機制【1】
- 圖解 Spring：HTTP 請求的處理流程與機制【2】
- 圖解 Spring：HTTP 請求的處理流程與機制【3】
- 圖解 Spring：HTTP 請求的處理流程與機制【4】
- 圖解 Spring：HTTP 請求的處理流程與機制【5】
- 如何正確使用 Spring Cloud？【上】
- 如何正確使用 Spring Cloud？【中】
- 如何正確使用 Spring Cloud？【下】
- Spring 核心技術與產品理念剖析【上】
- Spring 核心技術與產品理念剖析【下】