微服務下，介面效能優化的一些總結

如果是自己寫的**，加上又熟悉業務場景，很容易就知道效能瓶頸點。但如果上來就去優化別人的**，甚至是其他產品線的**，還是有一些挑戰的。最近就在做這事，接手了優化公司乙個業務引擎介面的任務，在這兒對優化方法做一些總結。

優化介面總共分兩步，一是找到效能熱點，二是解決熱點。在不熟悉**的情況下，找熱點是最難的，找到後對症下藥就容易多了。先主要說一下如何找效能熱點。

搜書

微服務下，呼叫鏈追蹤能很容易的定位到是鏈路上的哪個環節出現問題。從而確定是別人介面把你的拖慢了，還是自己介面內**有問題；且呼叫鏈反映的是線上真實資料，比跑線下測試資料更有說服力。

這裡以a->b->c舉例，簡單說一下呼叫鏈常用的幾個引數：

明白這幾個引數後，再看看具體使用。我們公司是用kibana作為查詢統計工具的。那麼，我的分析步驟有如下幾步：

1. 確定該請求的最長耗時（用於重點優化）、耗時中位數（用於全面優化）：

需要用到kibana的visualize功能，指定乙個metric為中位數、乙個metric為max，再按照服務路徑聚合即可

2. 拿到指定耗時時間附近的多個請求的bindingid

3. 統計其子鏈路耗時：

用visualize可以統計出平均每個執行緒中，每個子鏈路的被呼叫次數、總耗時。然後看看在主鏈路耗時的佔比情況。如果佔比比較大，說明鏈路有問題了。比如我最近優化的幾個介面，在鏈路上能看到資料庫儲存過程執行次數多且慢，那麼肯定可以定位是資料訪問的問題。

如果佔比不多，那就要繼續分析方法內部了。

1. 使用dottrace

方法內部的分析，最主要的是採用合理的引數來驅動被測方法。這裡我會選最耗時的引數來覆蓋被測方法的大多數分支，並且充分暴露問題。

還要注意一點的是，在正式取樣前，先對程式預熱一下，也就是跑一次被測方法，讓該快取的快取下來。這樣更能反映線上一般情況。

2. 結果解讀

dottrace可以說是異常的強大了。給你列出了某個方法的被呼叫次數、耗時、collection操作耗時、系統函式耗時、使用者函式耗時。基本上看這個圖就知道熱點在什麼地方了。

熱點找到了，後面就是對症下藥的優化了。總結一下優化方法也就是：

1. 迴圈體內的io、遠端呼叫，改為迴圈外去重後批量執行，避免重**起呼叫

2. 資料庫慢查詢，優化sql、索引

3. 基礎的、頻繁查詢的方法，可以把執行結果放到快取

4. 序列的遠端呼叫可以改為並行。（慎用，請求高峰期會造成記憶體暴漲，同時也可能導致上下文丟失）

5. 非主流程的方法，比如發訊息通知、增刪會員積分，改為發訊息到佇列然後非同步消費。

先寫到這兒吧。。公司要求嚴、打馬好辛苦