![頭圖.png](https://ucc.alicdn.com/pic/developer-ecology/e5265b1907644c4fb49edc762a6d1b31.png)

作者 | 顏高飛
來源 | [阿里巴巴雲原生公眾號](https://mp.weixin.qq.com/s/FSVcpojF8FI4sGJB5dj6sQ)

Dubbo 是一款輕量級的開源 Java 服務框架，是眾多企業在建設分散式服務架構時的首選。中國工商銀行自 2014 年開始探索分散式架構轉型工作，基於開源 Dubbo 自主研發了分散式服務平臺。

Dubbo 框架在提供方消費方數量較小的服務規模下，執行穩定、效能良好。隨著銀行業務線上化、多樣化、智慧化的需求越來越旺盛，在可預見的未來，會出現一個提供方為數千個、甚至上萬個消費方提供服務的場景。

在如此高負載量下，若服務端程式設計不夠良好，網路服務在處理數以萬計的客戶端連線時、可能會出現效率低下甚至完全癱瘓的情況，即為 C10K 問題。那麼，基於 Dubbo 的分散式服務平臺能否應對複雜的 C10K 場景？為此，我們搭建了大規模連線環境、模擬服務呼叫進行了一系列探索和驗證。

# C10K 場景下 Dubbo 服務呼叫出現大量交易失敗

## 1. 準備環境

使用 Dubbo2.5.9（預設 netty 版本為 3.2.5.Final）版本編寫服務提供方和對應的服務消費方。提供方服務方法中無實際業務邏輯、僅 sleep 100ms；消費方側配置服務超時時間為 5s，每個消費方啟動後每分鐘呼叫1次服務。

準備 1 臺 8C16G 伺服器以容器化方式部署一個服務提供方，準備數百臺 8C16G 伺服器以容器化方式部署 7000 個服務消費方。

啟動 Dubbo 監控中心，以監控服務呼叫情況。

## 2. 定製驗證場景，觀察驗證結果

![1.jpg](https://ucc.alicdn.com/pic/developer-ecology/b7bd7cba06b04f5db766190747f463f0.jpg)

驗證情況不盡如人意。C10K 場景下 Dubbo 服務呼叫存在超時失敗的情況。

如果分散式服務呼叫耗時長，從服務消費方到服務提供方全鏈路節點都會長時間佔用執行緒池資源，增加了額外的效能損耗。而當服務呼叫併發突增時，很容易造成全鏈路節點堵塞，從而影響其他服務的呼叫，並進一步造成整個服務叢集效能下降甚至整體不可用，導致發生雪崩。服務呼叫超時問題不可忽視。因此，針對該 C10K 場景下 Dubbo 服務呼叫超時失敗情況我們進行了詳細分析。

# C10K 場景問題分析

根據服務呼叫交易鏈路，我們首先懷疑交易超時是因為提供方或消費方自身程式卡頓或網路存在延遲導致的。

![2.png](https://ucc.alicdn.com/pic/developer-ecology/36ff6abc74e84af39969cb287f00e14c.png)

因此，我們在存在交易失敗的提供方、消費方伺服器上開啟程式 gc 日誌，多次列印程式 jstack，並在宿主機進行網路抓包。

## 1. 觀察 gc 日誌、jstack

提供方、消費方程式 gc 時長、gc 間隔、記憶體使用情況、執行緒堆疊等無明顯異常，暫時排除 gc 觸發 stop the world 導致超時、或執行緒設計不當導致阻塞而超時等猜想。

## 2. 針對兩種場景下的失敗交易進行觀察

針對以上兩種場景下的失敗交易，分別觀察網路抓包，對應有以下兩種不同的現象：

### **針對場景 1：提供方穩定執行過程中交易超時**

跟蹤網路抓包及提供方、消費方交易日誌。消費方發起服務呼叫請求發起後，在提供方端迅速抓到消費方請求報文，但提供方從收到請求報文到開始處理交易耗時 2s+。

![3.png](https://ucc.alicdn.com/pic/developer-ecology/86ec906af1bc40758d193229a3cc18f7.png)

同時，觀察交易請求響應的資料流。提供方業務方法處理完畢後到向消費方傳送回包之間也耗時 2s+，此後消費方端迅速收到交易返回報文。但此時交易總耗時已超過 5s、超過服務呼叫超時時間，導致丟擲超時異常。

![4.png](https://ucc.alicdn.com/pic/developer-ecology/e544f6a629114aaeb87a85647f4f8435.png)

**由此，判斷導致交易超時的原因不在消費方側，而在提供方側**。

### **針對場景 2：提供方重啟後大量交易超時**

服務呼叫請求發起後，提供方迅速收到消費方的請求報文，但提供方未正常將交易報文遞交給應用層，而是回覆了 RST 報文，該筆交易超時失敗。

![5.png](https://ucc.alicdn.com/pic/developer-ecology/6e531a8b2f4441da9fabbc08190cc0a7.png)

觀察在提供方重啟後 1-2 分鐘內出現大量的 RST 報文。透過部署指令碼，在提供方重啟後每隔 10ms 列印 established 狀態的連線數，發現提供方重啟後連線數未能迅速恢復到 7000，而是經過 1-2 分鐘後連線數才恢復至正常數值。而在此過程中，逐臺消費方上查詢與提供方的連線狀態，均為 established，懷疑提供方存在單邊連線情況。

我們繼續分別分析這兩種異常場景。

### **場景 1：提供方實際交易前後均耗時長、導致交易超時**

細化收集提供方的執行狀態及效能指標：

1. 在提供方伺服器上每隔 3s 收集服務提供方 jstack，觀察到 netty worker 執行緒每 60s 左右頻繁處理心跳。
2. 同時列印 top -H，觀察到佔用 CPU 時間片較多的執行緒排名前 10 中包含 9 個 netty worker 執行緒。因提供方伺服器為 8C，Dubbo 預設 netty worker 執行緒數為 9 個，即所有 9 個 netty worker 執行緒均較忙碌。

![6.png](https://ucc.alicdn.com/pic/developer-ecology/3b464d3941b849389c4825c822fd2a9c.png)

3. 部署伺服器系統效能採集工具 nmon，觀察到 CPU 每隔 60 秒左右產生毛刺；相同時間網路報文數也有毛刺。

![7.png](https://ucc.alicdn.com/pic/developer-ecology/41b099ad998b44d0ae48abc11754e3a5.png)

4. 部署 ss -ntp 連續列印網路接收佇列、傳送佇列中的資料積壓情況。觀察到在耗時長的交易時間點附近佇列堆積較多。

![8.png](https://ucc.alicdn.com/pic/developer-ecology/98b21a2b9c8444318aa382776fe3d643.png)

5. Dubbo 服務框架中提供方和消費方傳送心跳報文（報文長度為 17）的週期為 60s，與以上間隔接近。結合網路抓包，耗時長的交易時間點附近心跳包較多。

![9.png](https://ucc.alicdn.com/pic/developer-ecology/3f41128d6da444d0ad06ec840eb2f295.png)

根據 Dubbo 框架的心跳機制，當消費方數量較大時，提供方傳送心跳報文、需應答的消費方心跳報文將會很密集。因此，懷疑是心跳密集導致 netty 執行緒忙碌，從而影響交易請求的處理，繼而導致交易耗時增加。

![10.png](https://ucc.alicdn.com/pic/developer-ecology/e674b96a7e1246a9b3207555c7fb578e.png)

進一步分析 netty worker 執行緒的執行機制，記錄每個 netty worker 執行緒在處理連線請求、處理寫佇列、處理 selectKeys 這三個關鍵環節的處理耗時。觀察到每間隔 60s 左右（與心跳間隔一致）處理讀取資料包較多、耗時較大，期間存在交易耗時增加的情況。同一時間觀察網路抓包，提供方收到較多的心跳報文。

![11.png](https://ucc.alicdn.com/pic/developer-ecology/5d89c5d01b0d4204ae1746315f630e05.png)

**因此，確認以上懷疑。心跳密集導致 netty worker 執行緒忙碌，從而導致交易耗時增長。**

### **場景 2：單邊連線導致交易超時**

- **分析單邊連線產生的原因**

TCP 建立連線三次握手的過程中，若全連線佇列滿，將導致單邊連線。

![12.png](https://ucc.alicdn.com/pic/developer-ecology/d54b5c475fb4470fb59530abb6a4aad1.png)

全連線佇列大小由系統引數 net.core.somaxconn 及 listen(somaxconn,backlog) 的 backlog 取最小值決定。somaxconn 是 Linux 核心的引數，預設值是 128；backlog 在建立 Socket 時設定，Dubbo2.5.9 中預設 backlog 值是 50。因此，生產環境全連線佇列是 50。透過 ss 命令（Socket Statistics）也查得全連線佇列大小為 50。

![13.png](https://ucc.alicdn.com/pic/developer-ecology/399c94ebf71c48b5977cdfe2e299b607.png)

觀察 TCP 連線佇列情況，證實存在全連線佇列溢位的現象。

![14.png](https://ucc.alicdn.com/pic/developer-ecology/0adf037c2f89451e81b0c1f4aaca983c.png)

**即：全連線佇列容量不足導致大量單邊連線產生**。因在本驗證場景下，訂閱提供方的消費方數量過多，當提供方重啟後，註冊中心向消費方推送提供方上線通知，所有消費方几乎同時與提供方重建連線，導致全連線佇列溢位。

- **分析單邊連線影響範圍**

單邊連線影響範圍多為消費方首筆交易，偶發為首筆開始連續失敗 2-3 筆。

建立為單邊的連線下，交易非必然失敗。三次握手全連線佇列滿後，若半連線佇列空閒，提供方建立定時器向消費方重傳 syn+ack，重傳預設 5 次，重傳間隔以倍數增長，1s..2s..4s.. 共 31s。在重傳次數內，若全連線佇列恢復空閒，消費方應答 ack、連線建立成功。此時交易成功。

![15.png](https://ucc.alicdn.com/pic/developer-ecology/236494ec63b24264877c1b2efc88462c.png)

在重傳次數內，若全連線佇列仍然忙碌，新交易到達超時時間後失敗。

到達重傳次數後，連線被丟棄。此後消費方傳送請求，提供方應答 RST。後交易到達超時時間失敗。

![16.png](https://ucc.alicdn.com/pic/developer-ecology/78d021c772224852a57ca8b307e23408.png)

根據 Dubbo 的服務呼叫模型，提供方傳送RST後，消費方丟擲異常 Connection reset by peer，後斷開與提供方的連線。而消費方無法收到當前交易的響應報文、導致超時異常。同時，消費方定時器每2s檢測與提供方連線，若連線異常，發起重連，連線恢復。此後交易正常。

![17.png](https://ucc.alicdn.com/pic/developer-ecology/d82d8dbd80c14300b9b378bdb07f5073.png)

## 3. C10K 場景問題分析總結

總結以上造成交易超時的原因有兩個：

- **心跳機制導致 netty worker 執行緒忙碌**。在每個心跳任務中，提供方向所有 1 個心跳週期內未收發過報文的消費方傳送心跳；消費方向所有 1 個心跳週期內未收發過報文的提供方傳送心跳。提供方上所連線的消費方較多，導致心跳報文堆積；同時，處理心跳過程消耗較多 CPU，影響了業務報文的處理時效。
- **全連線佇列容量不足**。在提供方重啟後該佇列溢位，導致大量單邊連線產生。單邊連線下首筆交易大機率超時失敗。

## 4. 下一步思考

1. 針對以上場景 1：如何能降低單個 netty worker 執行緒處理心跳的時間，加速 IO 執行緒的執行效率？初步設想了如下幾種方案：

- 降低單個心跳的處理耗時
- 增加 netty worker 執行緒數，降低單個 IO 執行緒的負載
- 打散心跳，避免密集處理

2. 針對以上場景 2：如何規避首筆大量半連線導致的交易失敗？設想了如下方案：

- 增加 TCP 全連線佇列的長度，涉及作業系統、容器、Netty
- 提高服務端 accept 連線的速度

# 交易報文處理效率提升

## 1. 逐層最佳化

基於以上設想，我們從系統層面、Dubbo 框架層面進行了大量的最佳化，以提升 C10K 場景下交易處理效率，提升服務呼叫的效能容量。

最佳化內容包括以下方面：

![18.png](https://ucc.alicdn.com/pic/developer-ecology/eba5634c7f84451f9a3915a46254221b.png)

具體涉及最佳化的框架層如下：

![19.png](https://ucc.alicdn.com/pic/developer-ecology/4870d8a9c90b413281d75077671d5ed9.png)

經對各最佳化內容逐項驗證，各措施均有不同程度的提升，效果分別如下：

![20.jpg](https://ucc.alicdn.com/pic/developer-ecology/e3e0d53cdaa54345b30f3cb8054380b9.jpg)

## 2. 綜合最佳化驗證效果

綜合運用以上最佳化效果最佳。在此 1 個提供方連線 7000 個消費方的驗證場景下，重啟提供方後、長時間執行無交易超時場景。對比最佳化前後，提供方 CPU 峰值下降 30%，消費方與提供方之間處理時差控制在 1ms 以內，P99 交易耗時從 191ms 下降至 125ms。在提升交易成功率的同時，有效減少了消費方等待時間、降低了服務執行資源佔用、提升了系統穩定性。

## 3. 線上實際執行效果

基於以上驗證結果，中國工商銀行在分散式服務平臺中整合了以上最佳化內容。截至發文日期，線上已存在應用一個提供方上連線上萬個消費方的場景。落地該最佳化版本後，在提供方版本升級、及長時間執行下均無異常交易超時情況，實際執行效果符合預期。

# 未來展望

中國工商銀行深度參與 Dubbo 社群建設，在 Dubbo 金融級規模化運用的過程中遇到了諸多技術挑戰，為滿足金融級高敏交易的苛刻執行要求，開展了大規模自主研發，並透過對 Dubbo 框架的擴充套件和定製持續提升服務體系的穩定性，以“源於開源、回饋開源”的理念將通用增強能力不斷貢獻至開源社群。

未來，我們將持續致力於 Dubbo 的金融級規模化應用，協同社群繼續提升 Dubbo 的效能容量和高可用水平，加速金融行業數字化創新和轉型及基礎核心關鍵的全面自主可控。

## 作者簡介

顏高飛，微服務領域架構師，主要從事服務發現、高效能網路通訊等研發工作，擅長 ZooKeeper、Dubbo、RPC 協議等技術方向。

![21.png](https://ucc.alicdn.com/pic/developer-ecology/7ecd33f05e9246c189752c64608673de.png)

**在 PC 端登入 start.aliyun.com 知行動手實驗室，沉浸式體驗線上互動教程。**

工商銀行分散式服務 C10K 場景解決方案

相關文章