微服務下，接口性能優化的一些總結

若是是本身寫的代碼，加上又熟悉業務場景，很容易就知道性能瓶頸點。但若是上來就去優化別人的代碼，甚至是其餘產品線的代碼，仍是有一些挑戰的。最近就在作這事，接手了優化公司一個業務引擎接口的任務，在這兒對優化方法作一些總結。

優化接口總共分兩步，一是找到性能熱點，二是解決熱點。在不熟悉代碼的狀況下，找熱點是最難的，找到後對症下藥就容易多了。先主要說一下如何找性能熱點。

 

1、查調用鏈。

微服務下，調用鏈追蹤能很容易的定位到是鏈路上的哪一個環節出現問題。從而肯定是別人接口把你的拖慢了，仍是本身接口內代碼有問題；且調用鏈反映的是線上真實數據，比跑線下測試數據更有說服力。

這裏以A->B->C舉例，簡單說一下調用鏈經常使用的幾個參數：

• TraceID：一個完整鏈路的惟一ID。本例中，TraceID是在A、B、C中傳遞的，ABC中記錄的鏈路日誌都用這個惟一的TraceID，不會變。
• BindingID：一個線程內的ID。本例中，A記錄的鏈路日誌中，有惟一的BindingIDA，一樣B、C中各有BindingIDB、BindingIDC
• ConversationID：一個會話的ID。本例中，A調用B，A生成一個ConversationID，傳給B，B在返回結果前，記下日誌，A在收到結果後記下日誌。這兩條日誌有惟一的ConversationID。
• VirtualPath：用於標識微服務路徑
• Component：用於標識組件，或者微服務名稱
• CostInMilsecond：記錄一次會話耗時。Client端發起前開始計時，收到後記入日誌、Server端返回前記入日誌。

明白這幾個參數後，再看看具體使用。咱們公司是用Kibana做爲查詢統計工具的。那麼，個人分析步驟有以下幾步：

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

須要用到Kibana的Visualize功能，指定一個Metric爲中位數、一個Metric爲Max，再按照服務路徑聚合便可

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

3. 統計其子鏈路耗時：

用Visualize能夠統計出平均每一個線程中，每一個子鏈路的被調用次數、總耗時。而後看看在主鏈路耗時的佔比狀況。若是佔比比較大，說明鏈路有問題了。好比我最近優化的幾個接口，在鏈路上能看到數據庫存儲過程執行次數多且慢，那麼確定能夠定位是數據訪問的問題。

 若是佔比很少，那就要繼續分析方法內部了。

2、本地分析

1. 使用Dottrace

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

還要注意一點的是，在正式採樣前，先對程序預熱一下，也就是跑一次被測方法，讓該緩存的緩存下來。這樣更能反映線上通常狀況。

 

  

2. 結果解讀

dottrace能夠說是異常的強大了。給你列出了某個方法的被調用次數、耗時、Collection操做耗時、系統函數耗時、用戶函數耗時。基本上看這個圖就知道熱點在什麼地方了。

 

3、優化方法總結

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

1. 循環體內的IO、遠程調用，改成循環外去重後批量執行，避免重複發起調用

2. 數據庫慢查詢，優化SQL、索引

3. 基礎的、頻繁查詢的方法，能夠把執行結果放到緩存

4. 串行的遠程調用能夠改成並行。（慎用，請求高峯期會形成內存暴漲，同時也可能致使上下文丟失）

5. 非主流程的方法，好比發消息通知、增刪會員積分，改成發消息到隊列而後異步消費。

......

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