此Spring Cloud 項目採用的技術棧爲
- 註冊中心 Spring Cloud Eureka
- 配置中心 Spring Cloud Config
- 鏈路追蹤 Zipkin
- 分佈式事務TxLcn
- 一些其他組件
硬件條件
- CPU AMD Ryzen 7 2700 3.20GHz
- 內存16GB
在實際中測試登錄接口，併發量爲250TPS左右（每秒處理250個請求）
同樣一臺電腦Redis的吞吐量爲7W左右，差距太大，接下來分析問題產生的原因
發現問題
編寫一個無業務邏輯接口，排除數據庫的影響，直接返回請求成功的結果，代碼如下
@RestController
public class TestController implements BaseRestController {
@RequestMapping("/test")
public RestResponse<TestSpeedResult> test(){
TestSpeedResult result = new TestSpeedResult();
return this.createReponse(result);
}
}
對此接口進行Jmeter壓力測試，線程數爲500，無限制循環調用，產生的結果如下圖
發現兩個問題
- 吞吐量爲375左右，非常慢，要知道，這個接口無任何處理請求。
- 最大處理時間達到的驚人的31秒（測試進行了32秒），說明有請求一直處於阻塞狀態。
問題分析
從這種情況可以看出，問題和數據庫無關，純返回數據的接口的速度都非常慢
拿出我的絕手好活 VisualVm，Java自帶的強大神器，擁有監控內存，監控CPU的性能，追蹤等各種插件。
使用CPU抽樣，查看是哪些方法花費太多時間
可以看到，有個名爲
findFirstNonLoopbackAddress的函數居然佔據了CPU百分之97.7的時間
我們以debug模式啓動應用，在函數頭下斷點，開啓Jmeter，函數成功斷下來，我們看下調用棧
從第二條數據可以看出，該方法是由zipkin調用，大概查看了下源碼，是用來上報Trace信息所調用的。上報追蹤信息是影響性能的主要因素。
解決及驗證
修改配置文件，關閉鏈路追蹤
設置spring.zipkin.enabled 爲false。
重新使用Jmeter進行吞吐量測試
可以看到吞吐量已經道道11660左右。
吞吐量提高了31倍，恢復了正常水準。
總結
Zipkin會拖慢系統速度，建議在生產環境關閉，在開發環境開啓。避免影響整個系統性能。
另外， 通過Zipkin配置調整優化應該也能解決這個問題，這個就需要小夥伴們自己去探索了~