程序員必須練就的「性能調優」組合拳【1】

在【 程序員必須掌握的性能調優 XYZ 】這篇文章中，老兵哥結合我的經歷解釋了程序員往架構師方向發展時爲何要跨越性能調優這一關，這是咱們創建流程化、結構化、系統化的思惟的契機。另外，老兵哥還介紹了從 X、Y、Z 三個維度優化性能的思路。接下來，咱們將從 X 維度來談談優化業務交互設計的思路。

• X 維度，即業務維度，技術始終是服務業務的，任何技術問題的原點就是業務需求。在啓動技術層面的性能優化以前，咱們有必要先審視一下業務流程是否合理，交互設計上有沒有能夠優化的空間等。
• Y 維度，待業務維度優化完畢，接下來就是審視技術在實現當前業務流程或交互設計的全鏈路上有沒有可優化的地方，即 HTTP 請求處理全流程，從瀏覽器到應用容器，再到 Spring、Hibernate、數據庫等。
• Z 維度，除了沿着 HTTP 請求的橫向鏈路，咱們還要審視支持應用系統的縱向技術棧，從上到下包括 JVM、操做系統和硬件等，這是整套應用系統運行的環境，許多性能問題都跟運行環境存在關係。

X 維度自己超出了技術範疇，但爲了更好地服務業務，技術人也有必要懂得一些基礎的業務優化思路。若是隻知道埋頭趕路，不知道擡頭看天，那咱們技術人很容易作了費力不討好的事情，例如：某些性能瓶頸是因爲業務流程設計不合理致使的，在業務流程優化完善以前，咱們僅僅從技術視角去優化改善，極有可能事倍功半。具體說來，哪些業務優化思路是值得咱們借鑑實踐的呢？老兵哥我分享幾點我的經驗供你們作引子參考。

讓客戶端分擔部分計算存儲任務。面向公網的互聯網應用最顯著的特色就是用戶基數很是大，每項業務操做自己的計算量可能不大，可是乘上用戶量以後狀況就徹底不同了，爲了保障業務正常高效運轉，咱們就要投入更多服務器和帶寬資源。若是資源投入跟不上業務量的增加，那麼系統性能就會變差，用戶操做就會超時或失敗，用戶體驗就會變差，最終致使業務受損。有沒有辦法在不增長資源投入的狀況下來改善系統性能呢？若是把用戶的終端（手機或電腦等）也歸入到系統範疇，那麼把某些任務放到客戶端計算是緩解服務端資源的有效辦法。

具體有哪些任務適合交給客戶端處理呢？數據合法性的初步驗證、數據的加工轉換、數據呈現形式變換等等，例如在註冊登陸過程當中，客戶端能夠對用戶填寫的信息作格式層面的校驗，若是不符合要求能夠直接給出提示信息讓用戶從新填寫，這樣就免去了將信息發送至服務器的資源消耗。在如今流行的人臉或聲紋驗證身份的場景下，客戶端能夠直接提取照片或聲音的特徵碼發往服務器端作校驗，而不是把照片或聲音文件直接發送過去。還有就是對已呈現數據的排序或展現轉換上，客戶端也徹底能夠勝任。如今的客戶端計算存儲能力都很強大，關鍵是咱們要識別出哪些任務適合在客戶端運行，這是提高性能一個思路方向。

除此以外，優化交互設計是提高性能很是有效的途徑。若是交互設計不合理，那就容易產生許多無效的操做，這就是對資源最大的浪費。舉一個很是廣泛的場景爲例，無論何種類型的業務，都會存在耗時較長的操做，好比將某批任務分派給許多人，分配時要綜合考慮任務和執行者的匹配度，這個匹配過程的耗時跟任務和執行者的數量成正比，咱們習慣性作法就是提交操做指令後阻塞輪詢進度直至完成，而輪詢會致使大量無效的查詢請求，尤爲在海量用戶的狀況下，這就是一場 DDos 攻擊，很容易本身就把本身給搞死了。

化解這種問題的關鍵就是優化交互，把阻塞輪詢改爲異步通知，批量操做指令提交以後就再也不輪詢進度了，而是等待服務器端的進度更新通知，這樣就避免了大量無效的查詢請求。固然，業務流程優化依賴對業務的深入理解，這更可能是產品的職責，但咱們技術也要懂得常見業務模式對性能的影響。下一篇咱們將從 Y 技術維度來看看如何優化應用的性能。

關注「 IT老兵哥 」，賦能程序人生！推薦原創軟技能文章，請點擊連接：程序員，怎樣打造我的影響力？

 

 

近期熱評系列《 程序員必須懂的架構師入門課 》：

• 架構究竟是什麼，你知道嗎？ （閱讀人數：1161）
• 架構都有哪些，我該怎麼選？ （閱讀人數：872）
• 架構師都幹什麼，你知道嗎？ （閱讀人數：1155）
• 練就哪些技能才勝任架構師？ （閱讀人數：1120）
• 怎樣才能搞定上下游的客戶？ （閱讀人數：478）
• 如何從開發崗轉型作架構師？ （閱讀人數：1259）
• 程序員必須懂的架構入門課    （閱讀人數：557）

原文出處：https://www.cnblogs.com/itlaobingge/p/12209482.html