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

作者 | 顧海洋  攜程框架架構研發部技術專家

> **導讀**：本文整理自作者於 2020 年雲原生微服務大會上的分享《攜程微服務框架實踐及思考》，主要介紹了從攜程自研框架遇到的問題，轉到落地 Dubbo 微服務框架，攜程是如何實踐的，以及實踐過程中遇到的問題；未來轉型 service mesh 的道路上，dubbo 協議存在的問題，我們需要怎麼樣的協議層以及微服務 SDK 的定位。

**阿里巴巴雲原生公眾號後臺回覆 818 即可獲取直播回看地址和大會 PPT 合集。參與文末互動，還有機會得《攜程架構實踐》一書！**

攜程從 .Net 技術棧的時代就已經開始微服務領域的探索，轉入 Java  技術棧之後，更是經歷了自研微服務框架，到現在高效能的 dubbo，目前我們正在 Service Mesh 的道路上探索，希望能夠實現微服務框架的全面標準化、以及雲原生。

# 過去(自研服務框架)

攜程從 .Net 技術棧開始，最開始是基於 ESB 匯流排，雖然解決了內網服務呼叫的治理問題，但是集中式的服務架構，經常會出現單個服務把整個匯流排拖垮的情況，進而導致全網癱瘓的現象。基於註冊中心的 SOA 服務架構，透過分散式的服務呼叫，解決了單點故障帶來的巨大影響。目前，攜程主要是以 Java 技術棧為主，考慮到相容歷史 .Net 技術棧，所以現在的框架以自研為主，但是對比開源的高效能服務框架，自研的框架可能又存在下述提到的幾個問題。

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

# 現在(CDubbo 服務框架)

CDubbo 名字裡的 C 代表攜程的治理，Dubbo 代表阿里開源的 Dubbo SDK。縱觀過去兩年的實踐和探索，從 2018 年 4 月的第一個版本落地，到現在的近萬服務例項，我們大致可以總結為下面的幾個主要里程碑。

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

## 1. 註冊發現

註冊發現是分散式服務框架的核心要素，為了支援現有的服務互通，所以需要接入攜程的註冊中心。

服務註冊支援健康檢測擴充套件機制，業務可以根據業務場景自定義健康檢測擴充套件，例如當依賴的資料庫不可用時不再對外提供服務。服務端透過 5s 一次的心跳保持服務的可用性，當連續 N 次沒有傳送心跳時就會自動通知客戶端。

客戶端發起對服務的訂閱，透過推拉結合的模式，保證節點在客戶端的最終一致性。透過 Dubbo 的擴充套件機制，實現了自定義的路由策略，比如根據方法名指定路由策略，以及根據請求引數決定不同的路由策略，同時也能夠支援就近訪問，優先訪問本機房的服務。

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

## 2. 監控 - CAT

對微服務來說，沒有了監控就好比瞎子一樣，什麼也不清楚。CAT 提供了分散式鏈路追蹤的能力，可以提供很好的報表，以及場景化的問題分析。

有時，需要了解服務總的請求量以及單機的請求分佈和 QPS，或者還要知道服務的執行耗時及 99 線。CAT 的聚合報表可以幫助我們更好的瞭解服務的健康狀況。

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

對於超時，可能需要知道哪個階段變慢，客戶端還是服務端，序列化階段還是服務執行過程太慢。對於異常報錯，可以看到哪個過程出現的異常，同時會列印異常堆疊資訊，幫助問題的定位。

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

## 3. 監控-Metrics

框架人員需要了解公司服務的宏觀情況，比如各機房都有哪些服務，哪些服務使用了 protobuf 序列化格式，哪些服務使用了 SOA 協議等，以及平均執行耗時等情況。業務同事可能也想知道自己服務具體情況，比如有哪些呼叫方，執行緒池是否已經跑滿了。

透過接入攜程的 Dashboard，可以提供全域性的總量、錯誤量、執行緒池統計資訊，也可以根據機房、協議、序列化格式等聚合資料。還能夠自定義告警規則，在問題發生時能夠儘早的介入。

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

## 4. 動態配置

對業務同事來說，有可能會存在依賴的服務突然變慢導致客戶端超時的情況。框架人員可能需要在機房故障時，需要全域性調整 check 為 false，以解決 A B 服務迴圈依賴誰都無法啟動的問題。動態配置提供了配置熱生效的能力，不需要為了一個配置重新發布，成本很高。

服務端的多個方法，可能執行耗時也會有所不同，透過多級別的引數配置，可以設定服務預設超時為 1s，單獨為執行較慢的方法設定獨立的超時時間為 5s。

服務 Owner 可能更清楚自己服務的耗時，透過服務端對客戶端的引數設定，不需要每個呼叫方都設定一次超時，設定的時間也會更合理一些。為了避免配置出錯帶來的損失，我們提供了友好的視覺化介面。

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

## 5. SOA 協議及互通

為了支援現有客戶端遷移到 CDubbo，需要考慮支援現有的 SOA 協議。除了要確保相容 HTTP 1.1 協議不變，其次要保證跟客戶端的序列化器一致。

CDubbo 會透過 Tomcat 埠接收 SOA 協議的請求，利用現有的序列化器執行請求物件的轉換，並保證 Dubbo 內部呼叫和 Filter 鏈路的一致性，確保業務邏輯的統一，也就是業務程式碼不需要改動，就可以啟動兩個協議。

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

## 6. 測試平臺

對於私有的二進位制協議來說，沒有現成的 Postman 等工具可以使用。有時，開發人員需要在本地驗證測試環境的服務，也可能要驗證本地啟動的服務端，每個開發人員都構造一個客戶端顯得成本比較高。

透過 VI(github 開源叫 coreStone)，以及利用 Dubbo 2.7.3 提供的後設資料中心和泛化呼叫能力，我們實現了類似 postman 的呼叫工具。不但可以支援直連，也能夠支援本地測試，同時還可以支援 protobuf 序列化格式。關於 protobuf 序列化的測試方案，已經貢獻到 dubbo 社群，感興趣的同學可以自行了解。

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

## 7. 升級 Dubbo 2.7.3

關於 Dubbo 2.7.3 的詳細升級歷程，可以參考：[https://www.infoq.cn/article/kOxdaV3y9fMZ0Bzs0jb2](https://www.infoq.cn/article/kOxdaV3y9fMZ0Bzs0jb2)

現在回顧下升級的最終結果如何。目前，攜程 99% 的服務已經跑在 dubbo 2.7.3 之上，迄今為止 0 故障，只有一些不相容的小問題，對於不相容的問題也是確保了編譯時提前暴露，執行時沒有任何問題。

在釋出後，也陸續的出現了一些小的問題，比如預熱能力不生效，異常情況下不會回撥 onError 等問題，支援服務端非同步的 Trace 埋點等，這些問題已經在開源版本徹底修復了。

## 8. Threadless

業務同事反饋，需要把執行緒控制在理想的範圍之內。但是，dubbo 的執行緒數量太多，一方面是服務級獨享執行緒池，當呼叫方依賴了 10 個服務，每個服務的 QPS 為 1，lantency 可能只有 10ms 的情況下，由於每個服務獨立執行緒池，至少也需要 10 個執行緒了。如果多服務共享一個執行緒池，由於客戶端預設是 Cached 的執行緒池模式，那麼在這個場景下可能只要 1 個執行緒就足夠了。另一方面，對同步服務來說，dubbo 2.7.5 的 threadless 可以省去 DubboClientHandler 執行緒，Netty IO 執行緒直接把響應交給業務執行緒，從而節省了一次執行緒切換。

透過實踐，業務執行緒數量有了很大程度的下降，在高 QPS 以及依賴服務數量較多的情況下，甚至可以下降 60-70%。

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

## 9. CDubbo 服務體系

現有 CDubbo 的服務體系，同時支援 Dubbo 和 SOA 協議，對於 Dubbo 客戶端能夠支援 TCP 協議的傳輸，對於現有的 SOA 客戶端，能夠相容現有的 SOA 協議。

同時，也能夠支援內網和外網 gateway 的請求，保證了多協議的配置統一，以及相容了 SOA 的序列化格式。

![11.jpg](https://ucc.alicdn.com/pic/developer-ecology/7da342cdf33344088c9aa4e2ebb1d2c4.jpg)

## 10. 效能表現

從協議層面來看，Dubbo 協議的響應較 SOA 協議有所提升，平均耗時從之前的 1ms 降低到了 0.3ms 左右，當然具體提升也要根據服務的報文及請求量有所差異。

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

可能有些人會覺得幾毫秒的效能提升不足以掛齒，但是效能的穩定性對服務來說會很重要。我們觀察了服務流量突增 3-4 倍的情況下，客戶端還能保持 0 異常。長連線的多路複用，提供了很好的抗衝擊能力。

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

## 11. 擴充套件性

微服務框架跟業務程式碼耦合比較重，框架人員主要是用 20% 的時間解決業務 80% 的需求，另外 20% 的需求卻需要 80% 時間的問題，更適合留給業務自己去解決，能夠提供這個能力的唯有擴充套件性，dubbo 無論橫向和縱向的擴充套件能力都很好。

透過實踐，發現業務的確在各個層級都有自己的擴充套件。例如：業務擴充套件了 Router 層，支援自己的路由規則，擴充套件了負載均衡策略，機票同事甚至擴充套件了 Transport 層換成了適合自己的傳輸協議。

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

## 12. 生態

好的生態，可以降低開發成本，例如利用現有的開源 dubbo admin，dubbo go 等元件。另外，也可以降低業務的學習成本，在其他公司學習的 dubbo 框架，到了攜程還可以接著用，不需要重新學習私有的服務框架。技術支援也比較少，很多業務同事甚至比我們還熟悉 dubbo 框架。

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

## 13. Dubbo 協議現有問題 & Dubbo 3.0 規劃

除了前面提到的 Dubbo 框架得到業界廣泛認可的優點，在我們實踐的過程中，也發現了現有的 Dubbo 2.x 版本協議存在的一些不足，比如在雲原生大背景下，協議對閘道器不夠友好，缺乏移動端的輕量級 SDK 等。據我們與 Dubbo 官方維護團隊的深度交流，這些點也都是當前 Dubbo 3.0 在重點突破的方向，如下一代協議、應用級服務發現、雲原生基礎設施支援等，攜程作為 Dubbo 深度使用者也將持續的參與到 Dubbo 3.0 的建設與落地過程中。

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

# 未來(Service Mesh)

網上關於 Service Mesh 的意義講了很多，眾說紛紜，個人認為可能最主要還是以下幾點。

- 標準化意味著更低的成本，比如研發成本低，學習成本也比較低，其他公司學習的微服務框架，到攜程還可以繼續用，省去了學習和踩坑的成本；

- 程式解耦，框架同學可能比較感興趣，中介軟體無法獨立升級的問題一直困擾著框架研發同學，在這個問題上，envoy 可以獨立升級也是值得期待的；

- 透過下沉，複用了雲基礎設施的一些能力，一方面，能夠更好的支援多語言，業務根據自己的場景選擇合適的語言，另一方面，透過下沉也能夠讓 SDK 更簡單，減少Jar依賴的相容性問題；

- 因為更加標準以及下沉，能夠帶來更好的雲部署能力，業務出海時可以根據實際情況部署需要的元件，不再依賴框架全家桶了。

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

## 1. Service Mesh SDK

下圖是 Istio 官網提供的 Service Mesh 架構圖，如果說 Istio 解決了控制平面的標準化，envoy 或者 sofa-mosn 解決了資料平面的標準化，那麼對於 SDK 來說，是否需要有個標準化的元件，或者是否存在適合我們的標準的 SDK 呢？

對於部分中小公司，沒有自己的中介軟體團隊，可能會選擇商業版 SDK。但是，對於攜程這樣的規模，對擴充套件性要求很強，同時已經存在上千 dubbo 服務的公司來說，我們可能更期待 3.0 的標準協議。

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

## 2. 現有協議不適合下沉

現有的 SOA 協議可能不太適合作為標準協議，基於 Http 1.1 的文字協議，跟 TCP 協議相比，建連帶來的成本，很大程度上會導致長尾，影響服務的穩定性。

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

Dubbo 協議由於對閘道器不太友好，同時存在著跨語言和協議穿透性等問題，envoy 本身也可以理解為單機閘道器代理，所以也不太適合作為標準協議。

其次，存在的跨語言和協議穿透性問題，阿里劉軍同學有過分享，感興趣的同學可以參考：[https://www.infoq.cn/article/y5HC2JjtAvMWYILmVILU](https://www.infoq.cn/article/y5HC2JjtAvMWYILmVILU)

## 3. 新協議

既然現有的協議都不太適合，是否可以考慮雲原生的標準協議 gRPC。沒錯，從協議層面來看，這個選擇沒有問題，但是 gRPC 跟 proto 強繫結的問題，需要攜程現有的幾千個服務重寫業務邏輯程式碼，這個成本可是無法被接受的。

我們對於新的協議的期待，應該是能夠基於 POJO 物件，同時還要符合 gRPC 協議規範。一方面，能夠很好的利用雲原生的基礎能力。另一方面，對於小眾語言，也可以利用現有的 gRPC 框架實現與主流 SDK 的互通。

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

對於新的 SDK，不但要有標準的傳輸協議，同時考慮到服務框架與業務的緊密耦合，擴充套件性也是要保留的主要的特性，還需要考慮 API 的標準化，利用統一的監控元件。

## 4. 總結

現在，我們實現了 SDK 的部分標準化。未來，我們一定會在雲原生的道路上走的更快，更穩，更標準。

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

### 有獎互動

9 月 4 日 11:00 前在阿里巴巴公眾號留言區寫下你**關於微服務架構的思考或問題**，點贊前 5 名即可獲得**《攜程架構實踐》圖書一本**！

> “[阿里巴巴雲原生](https://mp.weixin.qq.com/s/T_Sdp_7mEPKMsfbK85hvVw)關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的公眾號。”

近萬服務例項穩定執行 0 故障，攜程微服務架構是如何落地的？

相關文章