X 維度本身超出了技術範疇，但為了更好地服務業務，技術人也有必要懂得一些基礎的業務優化思路。如果只知道埋頭趕路，不知道抬頭看天，那我們技術人很容易做了費力不討好的事情，例如：某些性能瓶頸是由於業務流程設計不合理導致的，在業務流程優化完善之前，我們僅僅從技術視角去優化改善，極有可能事倍功半。具體說來，... ...
在【 程式員必須掌握的性能調優 XYZ 】這篇文章中，老兵哥結合個人經歷解釋了程式員往架構師方向發展時為什麼要跨越性能調優這一關，這是我們建立流程化、結構化、系統化的思維的契機。另外，老兵哥還介紹了從 X、Y、Z 三個維度優化性能的思路。接下來，我們將從 X 維度來談談優化業務交互設計的思路。
- X 維度，即業務維度，技術始終是服務業務的，任何技術問題的原點就是業務需求。在啟動技術層面的性能優化之前，我們有必要先審視一下業務流程是否合理，交互設計上有沒有可以優化的空間等。
- Y 維度，待業務維度優化完畢，接下來就是審視技術在實現當前業務流程或交互設計的全鏈路上有沒有可優化的地方，即 HTTP 請求處理全流程，從瀏覽器到應用容器，再到 Spring、Hibernate、資料庫等。
- Z 維度，除了沿著 HTTP 請求的橫向鏈路，我們還要審視支持應用系統的縱向技術棧，從上到下包括 JVM、操作系統和硬體等，這是整套應用系統運行的環境，許多性能問題都跟運行環境存在關係。
X 維度本身超出了技術範疇，但為了更好地服務業務，技術人也有必要懂得一些基礎的業務優化思路。如果只知道埋頭趕路，不知道抬頭看天，那我們技術人很容易做了費力不討好的事情，例如：某些性能瓶頸是由於業務流程設計不合理導致的，在業務流程優化完善之前，我們僅僅從技術視角去優化改善，極有可能事倍功半。具體說來，哪些業務優化思路是值得我們借鑒實踐的呢？老兵哥我分享幾點個人經驗供大家做引子參考。
讓客戶端分擔部分計算存儲任務。面向公網的互聯網應用最顯著的特點就是用戶基數非常大，每項業務操作本身的計算量可能不大，但是乘上用戶量之後情況就完全不一樣了，為了保障業務正常高效運轉，我們就要投入更多伺服器和帶寬資源。如果資源投入跟不上業務量的增長，那麼系統性能就會變差，用戶操作就會超時或失敗，用戶體驗就會變差，最終導致業務受損。有沒有辦法在不增加資源投入的情況下來改善系統性能呢？如果把用戶的終端（手機或電腦等）也納入到系統範疇，那麼把某些任務放到客戶端計算是緩解服務端資源的有效辦法。
具體有哪些任務適合交給客戶端處理呢？數據合法性的初步驗證、數據的加工轉換、數據呈現形式變換等等，例如在註冊登錄過程中，客戶端可以對用戶填寫的信息做格式層面的校驗，如果不符合要求可以直接給出提示信息讓用戶重新填寫，這樣就免去了將信息發送至伺服器的資源消耗。在現在流行的人臉或聲紋驗證身份的場景下，客戶端可以直接提取照片或聲音的特征碼發往伺服器端做校驗，而不是把照片或聲音文件直接發送過去。還有就是對已呈現數據的排序或展示轉換上，客戶端也完全可以勝任。現在的客戶端計算存儲能力都很強大，關鍵是我們要識別出哪些任務適合在客戶端運行，這是提升性能一個思路方向。
除此之外，優化交互設計是提升性能非常有效的途徑。如果交互設計不合理，那就容易產生許多無效的操作，這就是對資源最大的浪費。舉一個非常普遍的場景為例，不管何種類型的業務，都會存在耗時較長的操作，比如將某批任務分派給許多人，分配時要綜合考慮任務和執行者的匹配度，這個匹配過程的耗時跟任務和執行者的數量成正比，我們習慣性做法就是提交操作指令後阻塞輪詢進度直至完成，而輪詢會導致大量無效的查詢請求，尤其在海量用戶的情況下，這就是一場 DDos 攻擊，很容易自己就把自己給搞死了。
化解這種問題的關鍵就是優化交互，把阻塞輪詢改成非同步通知，批量操作指令提交之後就不再輪詢進度了，而是等待伺服器端的進度更新通知，這樣就避免了大量無效的查詢請求。當然，業務流程優化依賴對業務的深刻理解，這更多是產品的職責，但我們技術也要懂得常見業務模式對性能的影響。下一篇我們將從 Y 技術維度來看看如何優化應用的性能。
關註「 IT老兵哥 」，賦能程式人生！推薦原創軟技能文章，請點擊鏈接：程式員，怎樣打造個人影響力？
近期熱評系列《 程式員必須懂的架構師入門課 》：
- 架構到底是什麼，你知道嗎？ （閱讀人數：1161）
- 架構都有哪些，我該怎麼選？ （閱讀人數：872）
- 架構師都乾什麼，你知道嗎？ （閱讀人數：1155）
- 練就哪些技能才勝任架構師？ （閱讀人數：1120）
- 怎樣才能搞定上下游的客戶？ （閱讀人數：478）
- 如何從開發崗轉型做架構師？ （閱讀人數：1259）
- 程式員必須懂的架構入門課 （閱讀人數：557）
