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

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

X 維度本身超出了技術範疇，但為了更好地服務業務，技術人也有必要懂得一些基礎的業務優化思路。如果只知道埋頭趕路，不知道抬頭看天，那我們技術人很容易做了費力不討好的事情，例如：某些效能瓶頸是由於業務流程設計不合理導致的，在業務流程優化完善之前，我們僅僅從技術視角去優化改善，極有可能事倍功半。具體說來，哪些業務優化思路是值得我們借鑑實踐的呢？老兵哥我分享幾點個人經驗供大家做引子參考。

讓客戶端分擔部分計算儲存任務。面向公網的網際網路應用最顯著的特點就是使用者基數非常大，每項業務操作本身的計算量可能不大，但是乘上使用者量之後情況就完全不一樣了，為了保障業務正常高效運轉，我們就要投入更多伺服器和頻寬資源。如果資源投入跟不上業務量的增長，那麼系統性能就會變差，使用者操作就會超時或失敗，使用者體驗就會變差，最終導致業務受損。有沒有辦法在不增加資源投入的情況下來改善系統性能呢？如果把使用者的終端（手機或電腦等）也納入到系統範疇，那麼把某些任務放到客戶端計算是緩解服務端資源的有效辦法。

具體有哪些任務適合交給客戶端處理呢？資料合法性的初步驗證、資料的加工轉換、資料呈現形式變換等等，例如在註冊登入過程中，客戶端可以對使用者填寫的資訊做格式層面的校驗，如果不符合要求可以直接給出提示資訊讓使用者重新填寫，這樣就免去了將資訊傳送至伺服器的資源消耗。在現在流行的人臉或聲紋驗證身份的場景下，客戶端可以直接提取照片或聲音的特徵碼發往伺服器端做校驗，而不是把照片或聲音檔案直接傳送過去。還有就是對已呈現資料的排序或展示轉換上，客戶端也完全可以勝任。現在的客戶端計算儲存能力都很強大，關鍵是我們要識別出哪些任務適合在客戶端執行，這是提升效能一個思路方向。

除此之外，優化互動設計是提升效能非常有效的途徑。如果互動設計不合理，那就容易產生許多無效的操作，這就是對資源最大的浪費。舉一個非常普遍的場景為例，不管何種型別的業務，都會存在耗時較長的操作，比如將某批任務分派給許多人，分配時要綜合考慮任務和執行者的匹配度，這個匹配過程的耗時跟任務和執行者的數量成正比，我們習慣性做法就是提交操作指令後阻塞輪詢進度直至完成，而輪詢會導致大量無效的查詢請求，尤其在海量使用者的情況下，這就是一場 DDos 攻擊，很容易自己就把自己給搞死了。

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

關注「 IT老兵哥 」，賦能程式人生！推薦原創軟技能文章，請點選連結：程式設計師，怎樣打造個人影響力？

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

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