Dubbo-go-Mesh 開啓新一代 Go 微服務形態

一  什麼是 Proxyless Service-Mesh (無代理服務網格) ?

1  Service Mesh 簡析

Istio 是當今最流行的開源服務網格。它由控制平面和數據平面構成，其架構如下（圖片摘自 Istio 官網）。

位於圖中下半部分的控制平面負責配置、服務信息、證書等資源的下發。位於上半部分的數據平面關注業務之間的通信流量；傳統服務網格通過代理的方式攔截所有的業務網絡流量，代理需要感知到控制平面下發的配置資源，從而按照要求控制網絡流量的走向。

在 Istio 環境中，其控制平面是一個名爲 istiod 的進程，網絡代理是 envoy 。istiod 通過監聽 K8S 資源 例如 Service、Endpoint 等，獲取服務信息，並將這些資源統一通過 XDS 協議下發給位於數據平面的網絡代理。envoy 是一個獨立的進程，以 sidecar（邊車）的形式伴隨業務應用 Pod 運行，他與應用進程共用同一個主機網絡，並通過修改路由表的方式，劫持業務應用的網絡流量。

Service Mesh 可以解決微服務場景下的衆多問題，隨着集羣規模的擴大與業務複雜度的增長，基於原生 k8s 的容器編排方案將會難以應付，開發人員不得不面對巨大的服務治理挑戰。而 Service Mesh 很好地解決了這一問題，它將服務治理需求封裝在了控制平面與代理中，業務開發人員只需要關注於業務邏輯。在應用部署之後，只需要運維人員通過修改配置，即可實現例如故障恢復、負載均衡、灰度發佈等功能，這極大地提高了研發和迭代效率。

Istio 的 sidecar 通過容器注入的形式伴隨業務應用進程的整個生命週期，對於業務應用是毫無侵入的，這解決了業務應用可遷移、多語言、基礎架構耦合等問題。但這也帶來了高資源消耗、請求時延增長的問題。

Service 爲服務治理提供了一個很好的思路，將基礎架構與業務邏輯解耦，讓應用開發人員只需關注業務。另一方面，由於 sidecar 的弊端，我們可以考慮使用 sdk 的形式，來替代 sidecar 支撐起數據平面。

2  Proxyless Service-Mesh

無代理服務網格，是 2018 年穀歌提出的一個新的概念，Isito、gRPC、brpc 等開源社區都在這一方向進行了探索和實踐。無代理服務網格框架以 SDK 的形式被業務應用引入，負責服務之間的通信、治理。來自控制平面的配置直接下發至服務框架，由服務框架代替上述 sidecar 的功能。

在無代理服務網格場景下，服務框架（SDK）的主要能力可以概括爲以下三點：

  1. 對接控制平面，監聽配置資源。

  2. 對接應用，爲開發者提供方便的接口。

  3. 對接網絡，根據資源變動，響應流量規則。

3  Proxyless 的優缺點

我認爲優點如下：

當然，缺點也有很多：

總體來講，我認爲 Proxyless 架構以其高性能、高穩定性的特點，更適合與生產環境使用。

二  Dubbo-go 與 Proxyless Service-Mesh

1  Dubbo-go 的能力

Apache/Dubbo-go (github.com/apache/dubbo-go)，是一款分佈式 RPC 框架，是 Apache/Dubbo 的 Go 語言實現。旨在爲開發者提供便利的微服務應用開發體驗。Dubbo-go 生態爲 Go 開發者提供了敏捷的微服務編程接口、配置管理方案、服務治理方案、以及一系列工具與腳手架，開發人員可以使用框架提供的能力快速開發自己的微服務應用。

2  Dubbo-go 在 Proxyless Service-Mesh 場景的設計

服務註冊發現

Dubbo-go 本身擁有可擴展的服務註冊發現能力，我們爲 service mesh 場景適配了註冊中心的實現。開發人員可以將 dubbo-go 應用的信息註冊在 istiod 控制平面上。客戶端應用可以查詢已經註冊的接口數據，完成服務發現過程。

歸因於 Java 的編程習慣，Dubbo-go 生態框架的服務註冊方式都是接口級別的。即客戶端只需要引入接口，即可發起調用，而無需關心下游的應用名、主機名、IP 地址等信息。與之相對的是應用級別的服務註冊發現，主流微服務框架更多這種形式的服務調用方式，例如 gRPC、K8S、Istio，應用級服務發現對應到 mesh 場景下，我認爲叫 “主機級別服務發現” 更合適，這種調用方式需要客戶端在引入接口的同時，還需引入下游的主機名和端口號。熟悉 gRPC-go 的同學一定很清楚，除了引入 pb 接口，還需要在創建客戶端時調用 gRPC.Dial("xxx") 建立網絡連接。而這裏的 xxx 就是下游的主機名和端口號，這種服務發現的類型和用戶編程習慣，導致了 gRPC 較爲輕鬆地實踐了 Proxyless Service Mesh。

關於應用級服務發現與接口級服務發現的區別和 dubbo 生態的解決方案，本文中不多贅述，可以參考劉軍前輩寫的文章文章《Dubbo 邁出雲原生重要一步 應用級服務發現解析》

簡單來說，應用級服務發現需要開發者關心接口之外還要關心應用名，註冊中心的冗餘信息較少；接口級服務發現開發者只需要引入接口名，但註冊中心的冗餘信息較多。

熟悉 Dubbo-go、Dubbo 生態的用戶，不習慣於在編程的過程中指定下游主機名，更希望以接口引入的方式，直接發起 RPC 調用，而不需關心究竟這個接口被哪個應用實現，運行在哪臺主機、哪個虛擬集羣上。

Dubbo-go 爲了融入 Istio 體系，將擴展出來的註冊發現流程進行了特殊改造。在複用 Istio 提供的 EDS、CDS 主機發現的能力之外，增加了接口名到主機名的映射，作爲源數據註冊在了控制平面上。客戶端在發起調用前持有接口名，通過查詢 istiod 上的元數據信息，拿到接口名到主機名到映射，轉換爲主機名；再通過 EDS、CDS 和路由，完成主機名到下游端點實例的轉換。完成服務發現流程。

下面用一個更詳細的例子來說明服務發現過程：

  1. 開發人員使用 dubbogo-cli 工具創建應用模板，發佈 Deployment / Service pair 到集羣中。

  2. 服務端拉取全量 CDS 和 EDS 數據，比對本機 IP，拿到當前應用的的主機名。並將本應用的所有接口名到主機名的映射，註冊在 Istiod 上面。

  3. 客戶端從 istiod 拉取全量接口名到主機名的映射，緩存在本地。當需要發起調用時，查詢本地緩存，將接口名轉換爲主機名，再通過 CDS 和 EDS 拉取到當前 cluster 所對應的全量端點。

  4. 全量端點經過 Dubbo-go 內置的 Mesh Router，篩選出最終的端點子集，並按照配置的負載均衡策略進行請求。

  5. 開發人員或者第三方組件，通過操作 K8S 資源，控制 Dubbo-go 流量。

縱觀這一過程，開發人員全程只需要關注接口即可，完全無需關心主機名和端口信息。即服務端開發者只需要實現 pb 接口，使用框架暴露出來；客戶端開發者只需要引入 pb 接口，直接發起調用即可，可以跟隨本文第四部分的教程來動手實驗一下。

流量治理

Dubbo-go 擁有路由能力，通過 xds 協議客戶端從 istiod 訂閱路由配置，並實時更新至本地路由規則，從而實現服務的管理。Dubbo-go 兼容 Istio 生態的流量治理規則，可以通過配置 Virtual Service 和 Destination Rule，將打標的流量路由至指定子集，也可以在灰度發佈、切流等場景進行更深入地使用。

雲原生腳手架

dubbogo-cli 是 Apach/dubbo-go 生態的子項目，爲開發者提供便利的應用模板創建、工具安裝、接口調試等功能，以提高用戶的研發效率。

可以執行以下指令安裝 dubbogo-cli 至 $GOPATH/bin

go install github.com/dubbogo/dubbogo-cli@latest

dubbogo-cli 支持以下能力

使用應用模板的開發流程

  1. 通過 dubbogo-cli 生成模板

  2. 修改 api/api.proto

  3. make proto-gen

  4. 開發接口

  5. 修改 makefile 內鏡像名和發佈名

  6. 打鏡像並推送

  7. 修改 chart/app/values 內與部署相關的 value 配置

  8. make deploy, 使用 helm 發佈應用。

詳情可以參閱 dubbogo-cli 文檔 1。

三  Dubbo-go-Mesh 的優勢

1  接口級服務發現

前文介紹到了通過接口級服務註冊發現的優勢，即開發人員無需關心下游主機名和端口號，只需要引入接口存根，或實現接口，通過框架啓動即可。

2  高性能

我們在 k8s 集羣內部署 Istio 環境，分別測試了 sidecar 模式的 gRPC 服務調用和 Proxyless 模式的 dubbo-go 應用服務調用。發現 proxyless 在請求耗時方面比 sidecar 模式少一個數量級，即性能提升十倍左右。

3  跨生態

Dubbo-go 是一個橫跨多個生態的服務框架。

四  動手體驗 Dubbo-go-Mesh

Dubbo-go 目前已支持兼容 Istio 的服務治理能力。支持基於 Istio 的接口級服務發現能力，兼容 Istio 生態的流量控制和管理能力，並且提供了腳手架和應用模板以提高 Go 應用開發效率。

您可參考文檔 【Dubbo-go 文檔 - Mesh 任務】2，動手搭建一組 Dubbo-go Mesh 應用。

在這組任務中，開發者會從部署 Istio 環境開始，到創建應用模板、構建應用、發佈應用、實現服務發現和 RPC、到最終完成流量規則動態配置，觀察流量切換。對框架用戶有較高的參考意義。

五  展望

Proxyless Service Mesh 能力將跟隨 Dubbo-go 下一版本發佈，穩定的性能需要社區成員們共同的關注與建設。在此基礎之上，我們還會進一步探索輕量級 sdk + sidecar 的模型；探索基於第三方流量治理組件的金絲雀發佈能力；探索基於 dubbo 服務框架的多語言 sevice mesh、與更豐富的 mesh 生態組件兼容。

Dubbo-go 也將繼續在雲原生的方向前進，繼續發掘雲計算時代技術紅利，與開發者同在。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/cSsnne_kGfUjm1lKZWLiOw

猜你喜歡