如果是自己寫的代碼，加上又熟悉業(yè)務(wù)場景，很容易就知道性能瓶頸點。但如果上來就去優(yōu)化別人的代碼，甚至是其他產(chǎn)品線的代碼，還是有一些挑戰(zhàn)的。最近就在做這事，接手了優(yōu)化公司一個業(yè)務(wù)引擎接口的任務(wù)，在這兒對優(yōu)化方法做一些總結(jié)。

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

[[383412]]

一、查調(diào)用鏈

微服務(wù)下，調(diào)用鏈追蹤能很容易的定位到是鏈路上的哪個環(huán)節(jié)出現(xiàn)問題。從而確定是別人接口把你的拖慢了，還是自己接口內(nèi)代碼有問題；且調(diào)用鏈反映的是線上真實數(shù)據(jù)，比跑線下測試數(shù)據(jù)更有說服力。

這里以A->B->C舉例，簡單說一下調(diào)用鏈常用的幾個參數(shù)：

• TraceID ：一個完整鏈路的唯一ID。本例中，TraceID是在A、B、C中傳遞的，ABC中記錄的鏈路日志都用這個唯一的TraceID，不會變。
• BindingID ：一個線程內(nèi)的ID。本例中，A記錄的鏈路日志中，有唯一的BindingIDA，同樣B、C中各有BindingIDB、BindingIDC
• ConversationID ：一個會話的ID。本例中，A調(diào)用B，A生成一個ConversationID，傳給B，B在返回結(jié)果前，記下日志，A在收到結(jié)果后記下日志。這兩條日志有唯一的ConversationID。
• VirtualPath ：用于標識微服務(wù)路徑
• Component ：用于標識組件，或者微服務(wù)名稱
• CostInMilsecond ：記錄一次會話耗時。Client端發(fā)起前開始計時，收到后記入日志、Server端返回前記入日志。

明白這幾個參數(shù)后，再看看具體使用。我們公司是用Kibana作為查詢統(tǒng)計工具的。那么，我的分析步驟有如下幾步：

1. 確定該請求的最長耗時（用于重點優(yōu)化）、耗時中位數(shù)（用于全面優(yōu)化）：

需要用到Kibana的Visualize功能，指定一個Metric為中位數(shù)、一個Metric為Max，再按照服務(wù)路徑聚合即可

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

3. 統(tǒng)計其子鏈路耗時：

用Visualize可以統(tǒng)計出平均每個線程中，每個子鏈路的被調(diào)用次數(shù)、總耗時。然后看看在主鏈路耗時的占比情況。如果占比比較大，說明鏈路有問題了。比如我最近優(yōu)化的幾個接口，在鏈路上能看到數(shù)據(jù)庫存儲過程執(zhí)行次數(shù)多且慢，那么肯定可以定位是數(shù)據(jù)訪問的問題。

如果占比不多，那就要繼續(xù)分析方法內(nèi)部了。

二、本地分析

1. 使用Dottrace

方法內(nèi)部的分析，最主要的是采用合理的參數(shù)來驅(qū)動被測方法。這里我會選最耗時的參數(shù)來覆蓋被測方法的大多數(shù)分支，并且充分暴露問題。

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

2. 結(jié)果解讀

dottrace可以說是異常的強大了。給你列出了某個方法的被調(diào)用次數(shù)、耗時、Collection操作耗時、系統(tǒng)函數(shù)耗時、用戶函數(shù)耗時?；旧峡催@個圖就知道熱點在什么地方了。

三、優(yōu)化方法總結(jié)

熱點找到了，后面就是對癥下藥的優(yōu)化了?？偨Y(jié)一下優(yōu)化方法也就是：

1. 循環(huán)體內(nèi)的IO、遠程調(diào)用，改為循環(huán)外去重后批量執(zhí)行，避免重復(fù)發(fā)起調(diào)用

2. 數(shù)據(jù)庫慢查詢，優(yōu)化SQL、索引

3. 基礎(chǔ)的、頻繁查詢的方法，可以把執(zhí)行結(jié)果放到緩存

4. 串行的遠程調(diào)用可以改為并行。（慎用，請求高峰期會造成內(nèi)存暴漲，同時也可能導(dǎo)致上下文丟失）

5. 非主流程的方法，比如發(fā)消息通知、增刪會員積分，改為發(fā)消息到隊列然后異步消費。