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

作者 | 李志信  於雨
來源|[阿里巴巴雲原生公眾號](https://mp.weixin.qq.com/s/O1eD9DDJ-hLBAmjIc0xPXA)

自從 2011 年 Dubbo 開源之後，被大量中小公司採用，一直是國內最受歡迎的 RPC 框架。2014 年，由於阿里內部組織架構調整，Dubbo 暫停維護了一段時間，之後隨著 Spring Cloud 的面世，兩個體系在融合中一起助推了微服務的火熱。

不過這世界變化快，自從以 docker 為代表的的容器技術和以 K8s 為代表的容器編排技術登上舞臺之後，雲原生時代到來了。在雲原生時代，不可變的基礎設施給原有的中介軟體帶來了不可變的中介軟體基礎設施：gRPC 統一了底層通訊層；protobuf 統一了序列化協議；以 envoy + istio 為代表的 service mesh 逐漸統一了服務的控制面與資料面。

dubbogo 的天然使命是：Bridging the gap between Java and Go。保持 Go 應用與 Java 應用互聯互通的同時，藉助 Go 語言（事實上的第一雲原生語言）的優勢擁抱雲原生時代。dubbogo 社群 2020 年勠力打造三支箭：

- 已經發布的對齊 dubbo 2.7 的 dubbogo v1.5 版本；

- 近期將要釋出的 sidecar 形態的 dubbo-go-proxy 專案；

- 以及處於進行時的 dubbogo 3.0。

用一句話概括 dubbogo 3.0 即是：新通訊協議、新序列化協議、新應用註冊模型以及新的服務治理能力！本文主要著重討論 dubbogo 3.0 的新通訊協議和應用級服務註冊發現模型。

# dubbogo 3.0 vs gRPC

知己知彼，方能進步。dubbogo 3.0 的通訊層改進主要借鑑了 gRPC。

[gRPC 協議](https://github.com/grpc/grpc/blob/master/doc/PROTOCOL-HTTP2.md)，簡單來說就是 http2 協議的基礎之上，增加了特定的協議 header：“grpc-” 開頭的 header 欄位，採用特定的打解包工具（protobuf）對資料進行序列化，從而實現 RPC 呼叫。

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

眾所周知，gRPC 幾乎沒有服務治理能力，而阿里雲現有 dubbo 框架兼具 RPC 和服務治理能力，整體實力不遜於 gRPC。但在“大家都用 gRPC” 這樣的背景之下，dubbogo 3.0 的新通訊協議就必須**完美相容 gRPC**，對開發者已部署的服務完全相容，並在此基礎之上延續已有 dubbo 協議和服務治理能力，進而推出一系列新策略：比如 mesh 支援、應用級服務註冊等。

# dubbogo 3.0 vs dubbogo 1.5

目前已有的 dubbo 2.7 協議已經儘可能實現了 gRPC 的支援。開發者可以透過 protoc-gen-dubbo 工具將 pb IDL 協議轉換為框架支援的 stub，再借助底層 gRPC conn 的 RPC 過程，將已有的服務治理能力自上而下傳遞給 gRPC，因此實現了 gRPC 服務的支援。

dubbo-go v1.5.x 也支援 gRPC 的 Stream 呼叫。和 unary RPC 類似，透過產生框架支援的 stub，在底層 gRPC stream 呼叫的基礎之上，將流式 RPC 的能力和併入框架。但由於 dubbo v2.7.x / dubbo-go v1.5.x 本身並不支援流式呼叫，所以沒有對 gRPC stream 呼叫的進行上層服務治理支援。

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

開發者所面臨的問題就是：我們在使用 dubbo-go2.7 進行 grpc 協議傳輸的時候，或多或少不是那麼放心。

而即將推出的 dubbo-go 3.0 協議將從根源解決這個問題。

# 協議相容的三種層次

筆者認為，一款服務框架對於第三方協議的支援可分為三個程度：應用層次、協議層次、傳輸層次。

一款框架如果在一個協議的 sdk 之上封裝介面，可以認為它處於應用層次支援，這樣的框架需要遵循下層 sdk 的介面，可擴充套件性較差。

處於協議層次的框架，從配置層到服務治理層均由本框架提供，而在此之下的協議層到網路傳輸層均使用某個固定的通訊協議，這樣的框架可以解決服務治理的問題，但框架本身無法與第三方協議完全適配，如果不適配就會出現對第三方協議支援的削弱，比如上面說到的 dubbo-go 1.5 對 stream rpc 支援的缺陷。

如果想進一步支援更多的第三方協議，需要從傳輸層下手，真正瞭解第三方協議的具體欄位、所依賴的底層協議（比如 HTTP2）的幀模型和資料流，再開發出與第三方協議完全一致的資料互動模組，作為本框架的底層。這樣做的好處是最大程度賦予了協議的可擴充套件性，可以在相容已有協議的基礎之上，可選地增加開發者需要的欄位，從而實現已有協議無法實現的功能，就比如 dubbogo 3.0 將支援的反壓策略。

# 基於 HTTP2 的通訊流程

gRPC 一次基於 HTTP2 的 unary rpc 呼叫傳輸主要流程如下：

- client 傳送 Magic 資訊：
PRI * HTTP/2.0\r\n\r\nSM\r\n\r\n；

- server 收到並檢查是否正確；

- client 和 server 互相傳送 setting 幀，收到後傳送 ACK 確認；

- client 傳送 Header 幀，包含 gRPC 協議欄位，以 End Headers 作為 Header 結束標誌；

- client 緊接著傳送 Data 幀，包含 RPC 呼叫的 request 資訊，以 End Stream 作為 Data 結束標誌；

- server 呼叫函式獲得結果；

- server 傳送 Header 幀，包含 gRPC 協議欄位，以 End Headers 作為 Header 結束標誌；

- server 緊接著傳送 Data 幀，包含 RPC 呼叫回傳的 response 資訊；

- server 緊接著再次傳送 Header 幀，包含 RPC 狀態和 message 資訊，以 End Stream 作為本次 RPC 呼叫結束標誌。

其中包含 gRPC 呼叫資訊的 HTTP2 Header 幀如下圖：

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

另外，在 gRPC 的 stream 呼叫中，可在 server 端回傳的過程中傳送多次 Data，呼叫結束後再傳送 Header 終止 RPC 過程，並彙報狀態資訊。

dubbogo 3.0 的通訊層將在 HTTP2 通訊協議之上採用同樣的通訊流程，以保證與 gRPC 的底層通訊溝通能力。

# dubbogo 3.0 預期通訊架構

除了通訊協議採用 HTTP2 外，dubbogo 3.0 將採用基於 google protobuf 的 triple 協議【下面稱為 dubbo3 協議】作為 dubbogo 3.0 的序列化協議，為 dubbo 將來支援更多的程式語言打下通訊協議層面的基礎。

目前設計的 dubbogo 3.0 傳輸模型如下：

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

- 為保證同時支援 unary RPC 和 stream RPC，在 server 端和 client 端增加資料流結構，以非同步呼叫的形式完成資料傳遞；

- 繼續支援原有的 TCP 通訊能力；

- 在 HTTP2 的通訊協議之上支援 dubbo3 協議，decode 過程相容 gRPC 使用的 protobuf，保證與 gRPC 服務打通。

# 應用級服務註冊發現

## 1. 應用級服務註冊發現介紹

dubbogo 3.0 使用的新一代服務註冊發現體系，將摒棄舊版的“介面級註冊發現”，使用“應用級別註冊發現”。

簡單地說，介面級別註冊發現，在註冊中心中以 RPC 服務為 key，以例項列表作為 value 來組織資料的，而我們新引入的“應用粒度的服務發現”，它以應用名（Application）作為 key，以這個應用部署的一組例項（Instance）列表作為 value。這帶來兩點不同：

- 資料對映關係變了，從 RPC Service -> Instance 變為 Application -> Instance；

- 資料變少了，註冊中心沒有了 RPC Service 及其相關配置資訊。

可以認為，基於應用粒度的模型所儲存和推送的資料量是和應用、例項數成正比的，只有當我們的應用數增多或應用的例項數增長時，地址推送壓力才會上漲。

而對於基於介面粒度的模型，資料量是和介面數量正相關的，鑑於一個應用通常釋出多個介面的現狀，其數量級一般是比應用粒度的數十倍。另外一個關鍵點在於，介面的定義更多的是業務側的內部行為，介面粒度導致的叢集規模評估的不透明，而例項、應用增長都通常是在運維側的規劃之中，可控性較好。

工商銀行曾經對這兩個模型進行生產測算：應用級服務註冊模型可以讓註冊中心上的資料量變成原來的 1.68%，新模型可以讓 zookeeper 輕鬆至成 10 萬級別的服務量和 10 萬級別的節點量。

## 2. 後設資料中心同步機制的引入

資料中心的資料量變少所造成的結果，是 RPC 服務相關的資料在註冊中心消失了，只有 application - instance  這兩個層級的資料。為了保證這部分缺少的 RPC 服務資料仍然能被 Consumer 端正確的感知，我們在 Consumer 和 Provider  間建立了一條單獨的通訊通道，目前針對後設資料同步有兩種具體的可選方案，分別是：

- 內建 MetadataService；

- 獨立的後設資料中心，透過中細化的後設資料叢集協調資料。

## 3. 相容舊版本 dubbo-go

為了使整個開發流程對老的 dubbo-go 使用者更透明，同時避免指定 provider 對可擴充套件性帶來的影響），我們設計了一套 RPC服務到應用名的對映關係，以嘗試在 consumer 自動完成 RPC 服務到 provider 應用名的轉換。

![5.jpg](https://ucc.alicdn.com/pic/developer-ecology/48509d9bd2e8465d92aae91e23beb8be.jpg)

這套設計可以讓 dubbogo 3.0 中同時保持對 dubbo v2.6.x、dubbo v2.7.x 和 dubbo v3.0.x 三個大版的互聯互通。

# 統一路由的支援

路由在概念上可以理解為從已有的所有 IP 地址列表中，根據特定的路由規則，挑選出需要的 ip 地址子集。路由的過程需要根據配置好的路由規則進行篩選，最終取所有路由規則的交集獲得結果。多個路由如同流水線一樣，形成一條路由鏈，從所有的地址表中篩選出最終目的地址集合，再透過負載均衡策略選擇訪問的地址。

## 1. 路由鏈

![6.jpg](https://ucc.alicdn.com/pic/developer-ecology/86cb51596daf4e7ca22708ba3c393aa9.jpg)

可以把路由鏈的邏輯簡單理解為 target = rn(...r3(r2(r1(src))))。對於每一個 router 內部的邏輯，可以抽象為輸入地址 addrs-in 與 router 中按全量地址 addrs-all 實現切分好的 n 個**互不相交**的地址池 addrs-pool-1 ... addrs-pool-n 按實現定義好的規則取交集作為輸出地址。以此類推，完成整個路由鏈的計算。

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

## 2. failover

在路由規則配置檔案中可以配置 failover 欄位。在尋找地址失敗時可以 failover， 選擇其他 subset，並且順序執行下來，直到找到地址，否則最後報地址找不到異常。

## 3. 兜底路由

在的路由規則配置中，可以配置一個沒有任何條件的 match, 最終的結果是至少會有一個 subset 被選到，以達到地址空保護的作用。

作為 2020 年 dubbogo 社群打造並將在 2021 年初亮出的的三支箭之一，dubbogo 3.0 將帶來不同平常且煥然一新的開發體驗，敬請廣大開發者期待！

如果你有任何疑問，歡迎釘釘搜尋群號加入交流群：釘釘群號 31363295。

dubbogo 3.0 目前是社群和 dubbo 官方團隊-- 阿里中介軟體團隊共同合作開發。

阿里雲-中介軟體團隊招募對 dubbo3 (java & go)、dapr、arthas 有興趣的開發者。可以釘釘聯絡 northlatitude，或者傳送郵件至 beiwei.ly@alibaba-inc.com。

## 作者簡介

**李志信** (GitHubID LaurenceLiZhixin)，阿里云云原生中介軟體團隊開發工程師，dubbogo 社群開發者，中山大學軟體工程專業在校學生，擅長使用 Go 語言，專注於雲原生和微服務等技術方向。

**於雨**(github @AlexStocks)，dubbo-go 專案和社群負責人，一個有十多年服務端做著基礎架構研發一線工作經驗的程式設計師，陸續參與改進過 Muduo/Pika/Dubbo/Sentinel-go 等知名專案，目前在螞蟻金服可信原生部從事容器編排和 service mesh 工作。

dubbogo 3.0：牽手 gRPC 走向雲原生時代

相關文章