作者 | 曹勝利  Apache Dubbo PMC

導讀：Dubbo 作為高性能 Java RPC 框架的刻板印象早已深入人心，在 Cloud Native 的架構選型上，Spring Cloud 或許才是業界的優先選擇，實際上，Dubbo 已經悄然地衍進為 Cloud Native 基礎設施，不僅承襲過去 RPC 時代的榮耀，而且也完善了現有基礎設施的缺失，自從容器和 K8s 登上舞臺之后，給原有的 RPC 領域帶來了很大的挑戰，本文主要講述 RPC 領域遇到的問題，以及 RPC 怎么去擁抱 K8s 的一些思考，

K8s 介紹

Kubernetes 是一個開源的，用于管理云平臺中多個主機上的容器化的應用， Kubernetes 的目標是讓部署容器化的應用簡單并且高效, Kubernetes 提供了應用部署、規劃、更新、維護的一種機制，Kubernetes 簡稱 K8s，

在 Kubernetes 中，最小的管理元素不是一個個獨立的容器，而是 Pod ，Pod 的生命周期需要注意以下幾點：

• 容器和應用可能隨時被殺死；
• Pod Ip 和主機名可能變化 (除非使用 StatefulSet 進行定制)；
• 寫到本地的磁盤的檔案可能消失，如果想不失效，需要用存盤卷，

應用 & 容器 & Pod 的關系

• 應用部署在容器中，一般情況下一個應用只部署在一個容器中；
• 一個 Pod 下可以包含一個或多個容器，一般情況下一個 Pod 只建議部署一個容器，下列場景除外：
  • side car；
  • 一個容器的運行以來與本地另外一個容器，如一個容器下應用負責下載資料，另外一個容器下應用向外提供服務，

Service

如果一些 Pods 提供了一些功能供其它的 Pod 使用，在 Kubernete 集群中是如何實作讓這些前臺能夠持續的追蹤到這些后臺的？答案是：Service ，

Kubernete Service 是一個定義了一組 Pod 的策略抽象，這些被服務標記的 Pod 一般都是通過 label Selector 決定的，Service 抽象了對 Pod 的訪問，

默認的 Service ，通過一個集群 IP 獲取 A Record ，但是有時需要回傳所有滿足條件的 Pod IP 串列，這時候可以直接使用 Headless Services ，

參考：https://kubernetes.io/

推薦書籍：kubernetes in action

RPC 介紹和分析

隨著微服務的普及，應用之間的通信有了足夠多的成熟方案，

• Dubbo 在 2011 年開源之后，被大量的中小型公司采用；
• 在 Spring Boot 推出之后，Spring 逐漸煥發出第二春，隨即 Spring Cloud 面世，逐漸占領市場，在中國市場中，和 Dubbo 分庭抗爭；
• gRPC 是 Google 推出的基于 Http2 的端到端的通信工具，逐漸在 K8s 市場上占據統治地位，如 etcd，Istio 等都采用 gRPC 作為通信工具；
• Service Mesh 從開始概念上就火熱，現在逐漸走向成熟；
• Istio + Envoy (其他 sidecar )逐漸開始走上舞臺，

應用開發者視角

從功能層面來說，對開發者有感知的功能有：

• 服務實作
• 服務暴露(注解或配置)
• 服務呼叫(注解或配置)
• 服務治理等

從選型角度會關注以下幾點：

• 易用性(開發易用性和開箱即用)
• 性能
• 功能
• 擴展性等

框架開發者視角

關鍵流程：

• 服務暴露
• 服務注冊
• 服務發現
• 服務呼叫
• 服務治理

關鍵知識點：

• 序列化
• 網路通信
• 服務路由
• 負載均衡
• 服務限流
• 熔斷
• 降級等服務治理

主流技術實作

Dubbo / HSF

• Dubbo 提供了面向介面的遠程方法呼叫，應用開發者定義介面，撰寫服務并暴露；
• Client 端通過介面進行呼叫；
• Dubbo 注冊服務的維度是介面維度，每個介面會在注冊中心寫入一條資料；
• Dubbo 支持條件路由，腳本路由，Tag 路由等，這些路由規則都是強依賴于 IP 地址，

備注：Dubbo 和 HSF 的大部分機制都是相似的，所以下面都以 Dubbo 作為方案進行討論，

SpringCloud

Spring Cloud 通過 Rest 形式進行網路呼叫，應用開發者可以自己撰寫暴露 Rest 服務，如 springmvc ，

Spring Cloud 里的服務注冊是應用維度( Eureka )，Client 端和 Server 端通過約定的方式進行通信，

Spring Cloud 提供了一套標準 API ，而其中 Netflix 是其中的佼佼者，對這套 API 進行了實作，對大部分開發者來說，可以回直接依賴和使用 Netflix ，所以可以說是 Netflix 提供成了 Spring Cloud 的核心，但是作為商業公司對開源投入往往會多變，如 Eureka 已經體制維護，

gRPC

gRPC 是一個基于 HTTP/2 協議設計的 RPC 框架，它采用了 Protobuf 作為 IDL，gRPC 作為端到端的通信方案，可以解決現在的多語言問題，

gRPC 本身不提供服務注冊，服務治理的功能，但現在可以看到 gRpc 有趨勢往這方面擴展的野心，

K8s

K8s 體系里暫時沒有公允的通信框架，一般推薦 gRPC 作為 RPC 框架，

K8s 體系的默認情況下， Pod 的 IP 是變化的，所以 Pod 和 Pod 之間需要通信的話，有幾種方式：

• Service+DNS：新建一個 Service ，可以通過標簽選擇到一組 Pod 串列，這個 Service 對應一個不變的集群 IP ；Client 端通過 DNS 方式或者直接訪問集群 IP，這個集群 IP ，約等于實作了負載均衡 ( iptable 方式)；
• headless service：headless service 和上面的 service 的區別是，它不提供集群 IP ，通過主機名的形式獲取一組 IP 串列，Client 端自己決定訪問哪個 Pod，

Istio + Envoy

Istio 的控制層會向 K8s 的 Api server 請求并監聽 pod 資訊，service 資訊等資訊，這樣 Istio 中就有了完整的 K8s 集群中的 pod，service 等的完整資訊，如果 K8s 集群中有資訊變更，Istio 中也可以得到通知并更新對應的資訊，

Envoy 作為 Proxy 一個最常見的實作，以 Envoy 作為例子簡單介紹，Envoy 通過查詢檔案或管理服務器來動態發現資源，對應的發現服務及其相應的 Api 被稱作 xDS ，協議內容包括 LDS、RDS、CDS 等等，

參考資料：

Service Mesh 介紹：https://www.infoq.cn/article/pattern-service-meshIstio
路由規則：https://istio.io/docs/tasks/traffic-management/request-routing/

備注：上述知識是通過查閱資料( Istio 官網)，以及和集團 Service Mesh 同學溝通獲得，如有問題，歡迎指正，

小結

遇到的問題和挑戰

Spring Cloud 和 Dubbo 的共生

Dubbo 默認是基于 TCP 通信，Spring Cloud 大部分基于 Rest 請求，在阿里云實施商業化程序中，發現大量公司需要 Spring Cloud 應用和 Dubbo 進行通信，社區主要依靠 Dubbo 上增加一層網關來解決，

是否有方案進行統一服務注冊發現，以及服務呼叫呢？

基礎理論可以參考：

https://yq.aliyun.com/articles/585461

Dubbo 在 K8s 場景下的挑戰

K8s 下 Pod 的 IP 是變化的 (默認)，Dubbo 的服務治理高度依賴 IP ，

K8s 的服務注冊通過 Pod 定義完成，服務發現其實是尋找 Pod 的程序，Pod 和應用有一定的對應關系，和 Dubbo 里的介面維度的服務注冊發現模型不是很匹配，

Dubbo 在 Service Mesh 場景下的生存空間

Dubbo 需要進行支持裁剪，Dubbo 的大部分功能都可以交由 sidecar ( proxy )來完成，

如果公司已經在部署 RPC 框架，這時候如果需要實施 Service Mesh ，有什么好的過渡方案嗎？

問題梳理

服務定義

服務怎么定義呢？需要從應用開發者角度看待怎么定義服務，

服務在功能維度對應某一功能，如查詢已買訂單詳情，在 Dubbo 中，對應某個介面下的方法；在 Spring Cloud 和 gRPC 對應一個 http 請求，

如果從面向函式編程角度，一個服務就是一個 function ，在 Java 語言中，class 是一切編程的基礎，所以將某些服務按照一定的維度進行聚合，放到某個介面中，就成了一個介面包含了很多的服務，

從 Dubbo 角度來解釋下：Dubbo 是面向介面編程的遠程通信，所以 Dubbo 是面向服務集的編程，你如果想呼叫某個服務，必須通過介面的方式引入，然后呼叫介面中的某個服務，Dubbo Ops 中提供的服務查詢功能，其實不是查詢單個服務，而是通過查詢介面(服務集)之后獲得具體的方法(服務)，

而在 Spring Cloud 的世界里，服務提供方會將自己的應用資訊( Ip+port )注冊成應用下的一個實體，服務消費方和服務提供方按照約定的形式進行 Rest 請求，每個請求對應的也是一個服務，

和 K8s 里的 Service 的區別

K8s 里的 Service 其實是對應到一組 pod+port 串列，和 DNS 聯系緊密；用通俗易懂的方式表達：維護了 pod 集合的關系映射，和上面講的服務是屬于不同場景下的兩個概念，

按照這個方式定義服務，服務治理的粒度其實也是按照服務粒度，可以針對每個服務設定超時時間，設定路由規則等等，但是服務注冊的粒度和服務有什么關系呢？

服務注冊粒度

一個應用下包含了很多介面，一個介面下包含了很多服務( Dubbo )；或者一個應用包含了很多的服務( Spring Cloud )，分析下應用維度注冊和介面維度注冊的優缺點，會有一篇獨立的文章來闡述應用維度注冊的方案，

介面維度注冊

優點：

• 服務查詢按照介面維度查詢非常方便，實作難度低；
• 應用拆分或者合并的時候， Client 端(消費者)無需關心，做到了讓用戶無感，

缺點：

• 和 K8s 等主流平臺的模型對應關系不匹配；
• 注冊的資料量非常大，有一定的性能風險，

應用維度

優點：

• 和 K8s，Spring Cloud 等模型對應關系一致；
• 性能上可以得到很大緩解，

缺點：

• 應用拆分或者合并的時候，Client 端需要感知 (如果想做到不感知,需要框架開發者維護一份介面和應用映射關系的存盤)；
• 如果想對用戶保持 Dubbo 原有的介面維度的查詢，需要較多的作業量來保證；
• 對用戶透明度有所減少，需要在 OPS 上提供其他一些工具，如供應用開發者可以查看具體某個 IP 是否提供了某個服務等等，

Dubbo 和 Spring Cloud

目標：

• Dubbo 和 Spring Cloud 的服務發現進行統一；
• Dubbo 和 Spring Cloud 可以互相呼叫，

服務發現統一

Dubbo 改造成應用維度的服務注冊，（具體不展開，后面文章說明）

打通呼叫

Dubbo 實作中，支持將以 Rest 協議進行暴露，并且讓 Spring Cloud 識別，

Dubbo + K8s

在 K8s 已經闡述過，下面的內容也是假設一個應用部署在一個容器里，一個容器部署在一個 pod 里，

接下來方案的討論，互相之間其實是有關聯的，如服務治理可能會影響到服務注冊發現，服務查詢也不能依賴于服務注冊的內容，整個設計的程序是不斷優化的程序，下面所說的內容，以 Dubbo 來舉例說明，

服務治理

Dubbo 原有體系里的服務治理是強依賴于 IP ，當配置了一套服務治理規則的時候，最后都是基于一個或多個 IP 地址，

到 K8s 體系下之后，要考慮的是 Pod 的 IP 不是固定的，所以當前的路由規則不能滿足條件，而且會產生很多規則垃圾資料，K8s 體系下，通過 service 查找 Pod ，是基于 label selector ；通過 deployment 管理 Pod ，其實也是基于 Pod label selector ，所以 pod label selector 是在 K8s 習題中比較通用的解決方案，

以路由規則為例，需要支持一種新的路由規則：label 路由，通過一定條件匹配之后，將結果定位到以 label selector 查詢到的 Pod 串列里，而非原來的 ip 串列，

要支持 label 路由，client 端需要獲取到 client 端自己的 Pod label 資訊，還需要獲取到 server pod 串列中每個 Pod 的 label 資訊，

應用獲取當前 Pod 的資訊方式

• Pod 定義環境變數，應用獲取；Dubbo 提供對環境變數讀取的支持，Pod 中需要按照 Dubbo 定義的環境變數設定具體的 pod 資訊，

• 通過 Downward API 傳遞 Pod 資訊；Dubbo 需要提供對 Downward 的目錄讀取，Pod 中需要定制 downward 的對應配置，

• 通過 API Server 獲取資料；最強大的方式，但是應用需要強依賴于 API Server ，

應用獲取其他 Pod 的資訊方式

• 通過呼叫其他 Pod 的服務獲取；依賴于應用能獲取自身的 Pod 資訊，同時將自身的 Pod 資訊暴露成服務( rest 或 dubbo 協議)，client 端通過呼叫對用的 Pod 獲取到對應 Pod 的完整資訊，

• 通過 Api server 獲取資料；很強大，但增加了對 Api server 的依賴，

服務注冊和發現

K8s 體系下，RPC 服務發現有以下幾種方式:

• 注冊機制：將 IP 寫入注冊中心，用心跳保持連接；當心跳停止，從注冊中心洗掉；

• 利用 Service+DNS ：新建一個 Service ，可以通過標簽選擇到一組 Pod 串列，這個 Service 對應一個不變的集群 IP ；Client 端通過 DNS 方式或者直接訪問集群 IP ，這個集群 IP ，約等于實作了負載均衡 ( iptable 方式)；

• 利用 headless service(DNS) ：headless service 和上面的 service 的區別是，它不提供集群 IP ，通過主機名的形式獲取一組 IP 串列，Client 端自己決定訪問哪個 Pod ；

• api server ：Client 端直接請求 api server ，獲取到 pod 的串列， Client 自己決定訪問 pod 的邏輯，同時獲取的時候增加 watch ，api server 會將 pod 的變化資訊同步 Client ，

通過拿到 Server 端的 IP 或者 host ，Client 端就可以發起  http 或者其他協議的請求，

下面介紹符合 Dubbo 的可行方案：

1. Dubbo + Zookeeper pod cluster (HSF+CS cluster)

這是最簡單的方式，Dubbo 本身不需要做任何改造，帶來的問題是增加了 Zookeeper 的維護，同時這個方案很不云原生，和 K8s 的體系沒有任何關系，

腦暴

上面方案是將 ZooKeeper 作為注冊中心，那么是否可以將 K8s 里 service 作為注冊中心呢？Dubbo 里每個介面去建立一個 service ，每個應用實體啟動程序中去更新 Endpoint 資訊，建立 Service-> Endpoint-> IP 串列的關系，

這種方案中 K8s service 的定義被改造了，而且定義了過多的 service ，service 的維護管理是個難題，

基于 K8s 的場景

在傳統的 RPC 領域，服務分成服務注冊和服務發現，在 K8s 領域 pod 和應用是一對一的關系，K8s 本身就提供了 pod 查找的能力，所以一定程度上服務注冊其實可以不存在，而只需要服務發現，但是這個其實需要一個前提：

Dubbo 需要將服務注冊發現的粒度改造成應用維度，> 在運維層面，將 app=xxx (應用名)寫入到 pod 的 label 中，

2. Dubbo + K8s DNS

如果 K8s service 提供了cluster ip ，那么 Dubbo 只負責呼叫該集群 Ip ，路由和負載均衡的邏輯則交給了 K8s 的 proxy 來完成，此方案削減了 Dubbo 的核心能力，接下來討論 headless service 提供的能力，

通過請求 ..svc..  IN A  的方式發起請求獲取 IP 串列，但是需要輪詢方式不斷獲取更新的 IP 串列，

服務治理相關的功能，需要在上述服務治理部分中獨立支持，

參考：https://github.com/kubernetes/dns/blob/master/docs/specification.md#24---records-for-a-headless-service

3. Dubbo + Api Server

Pod 的容器中部署的 Dubbo 應用，服務注冊流程可以直接洗掉，服務發現功能通過和 Api Server 進行互動，獲取 Pod 和 service 資訊，同時 watch pod 和service 的變更，通過這種方式之后，服務治理相關的資訊也可以通過 Api Server 直接獲取，

4. Dubbo + Istio + Envoy

Dubbo 可以直接使用指定 ip+埠 的方式呼叫同一個 pod 下 Envoy  (也可能是同一個node的Envoy)，Dubbo 將路由規則，負載均衡，熔斷等功能交給 Istio 和 Envoy，Envoy 需要支持 Dubbo 協議的轉發，

所以 Dubbo 需要完成兩個事情：本地 IP 直連(現有功能)， 多余功能裁剪(暫未實作)，

5. Dubbo + Istio

• Dubbo 應用不再依賴 Envoy 作為 sidecar ，而是直接和 Istio 進行互動，把 Istio 作為注冊中心，作為服務治理的配置中心；
• Dubbo 需要提供類似的 xDS 協議，在pilot將service的instance轉換成dubbo的協議格式；
• Dubbo 還需要去適配 istio 的一些功能，如健康檢查，安全相關的邏輯，具體實作可以參考 Envoy 的實作，

6. Dubbo 和 Istio 在 K8s 體系下共存這個可選擇的方案較多，我提供兩種思路，供大家思考：

• 所有的服務注冊通過k8s的機制完成，所有的服務發現通過 Headless service 完成，sidecar 在創建程序中，需要對原有的 K8s service 進行 update；

• Nacos 作為 Dubbo 的注冊中心，并且需要將 K8s 中的資料進行部分中轉，Dubbo 應用，將服務注冊以應用維度注冊到 Nacos ，Istio Pilot 需要識別 Nacos 資料；Istio 的運行機制基本不變，需要將 K8s service instance 的資料寫入到 nacos ，供 Dubbo 呼叫，

7. 云上和云下環境共存 & 云上多集群環境

Istio 提供了跨集群和云上云下的解決方案， kubeFed 作為 K8s 的跨集群解決方案也能起到一定作用，

這個課題的復雜度更加高，心中有了一些答案，期望大家通過上文也有一定的思考，

服務查詢

拋出三種方式，供大家思考，

Dubbo 原有方式

Dubbo 原有的服務查詢是針對介面的查詢，每個介面會有版本號和組別，介面名+版本號+組別確定唯一的服務集合，這個服務集下有對應的服務提供者和服務消費者(介面級依賴)，服務提供者是一組 ip+port 串列，服務消費者也是一組 ip+port 串列，

當做了改造成應用級別的服務注冊或者直接使用 K8s 自帶的 Pod 發現機制的話，需要做一些改造，這部分改造，和前面提到的一樣，放到其他文章里單獨說明，

只支持應用查詢

和 Spring Cloud 類似，支持應用維度的查詢，查詢到具體應用之后，應用詳情下包含了 ip+port 串列，每個 ip+port 其實就是一個應用的實體，點擊開每個應用實體，可以查看每個應用的詳細資訊，詳細資訊包含了該實體提供了哪些服務，

介面+應用查詢均衡

在原來只支持應用查詢的基礎上，增加一步：支持查詢某個介面對應的應用串列，而大部分介面只屬于一個應用，

再點擊應用串列下具體的應用之后，會跳到應用詳情，

總結

上述討論的是開源的方案，所以相對歷史包袱比較少，對一些大公司想從原有的 RPC 方案切換到云原生的支持，需要考慮更多兼容性和性能，需要付出更大的代價，

云原生的趨勢已經勢不可擋，在 RPC 領域究竟哪種方案最終能夠勝出，現在還言之過早，我相信 Service Mesh 和傳統的 RPC  (Dubbo/ gRPC)  都會有自己的一席之地，一切讓時間給我們答案吧，

“ 阿里巴巴云原生微信公眾號（ID：Alicloudnative）關注微服務、Serverless、容器、Service Mesh等技術領域、聚焦云原生流行技術趨勢、云原生大規模的落地實踐，做最懂云原生開發者的技術公眾號，”

標籤：其他

上一篇：Linux Capabilities 入門教程：概念篇

下一篇：Rancher 2.3.2 Stable！Istio UI已經GA！生產可用！