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 的功能。
- 對接控制平面，監聽配置資源。
- 對接應用，為開發者提供方便的介面。
- 對接網路，根據資源變動，響應流量規則。
3 Proxyless 的優缺點
我認為優點如下：
- 效能：無代理模式的網路呼叫為點對點的直接通訊，網路時延會比代理模式小很多。
- 穩定性：proxyless 的模式是單程序，拓撲簡單，便於除錯，穩定性高。
- 框架整合：市面上已有眾多 sdk 模式的服務框架，切換至 mesh 後便於複用框架已有能力
- 資源消耗：沒有 sidecar，資源消耗低。
當然，缺點也有很多：
- 語言繫結：需要開發多種語言的 sdk
- 可遷移性低：無法通過切換 sidecar 的形式來無侵入地升級基礎設施。
總體來講，我認為 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和路由，完成主機名到下游端點例項的轉換。完成服務發現流程。
下面用一個更詳細的例子來說明服務發現過程：
- 開發人員使用 dubbogo-cli 工具建立應用模板，釋出 Deployment / Service pair 到叢集中。
- 服務端拉取全量 CDS 和 EDS 資料，比對本機 IP，拿到當前應用的的主機名。並將本應用的所有介面名到主機名的對映，註冊在 Istiod 上面。
- 客戶端從 istiod 拉取全量介面名到主機名的對映，快取在本地。當需要發起呼叫時，查詢本地快取，將介面名轉換為主機名，再通過CDS 和 EDS 拉取到當前 cluster 所對應的全量端點。
- 全量端點經過 Dubbo-go 內建的 Mesh Router，篩選出最終的端點子集，並按照配置的負載均衡策略進行請求。
- 開發人員或者第三方元件，通過操作 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 支援以下能力
- 應用模板建立
- Demo 建立
- 編譯、除錯工具安裝
- 檢視 dubbo-go 應用註冊資訊
- 除錯 dubbo-go 應用介面
使用應用模板的開發流程
- 通過 dubbogo-cli 生成模板
- 修改api/api.proto
- make proto-gen
- 開發介面
- 修改 makefile 內映象名和釋出名
- 打映象並推送
- 修改chart/app/values 內與部署相關的value配置
- make deploy, 使用 helm 釋出應用。
詳情可以參閱 dubbogo-cli 文件[1]。
三 Dubbo-go-Mesh 的優勢
1 介面級服務發現
前文介紹到了通過介面級服務註冊發現的優勢，即開發人員無需關心下游主機名和埠號，只需要引入介面存根，或實現介面，通過框架啟動即可。
2 高效能
我們在 k8s 叢集內部署 Istio 環境，分別測試了 sidecar 模式的 gRPC 服務呼叫和 Proxyless 模式的 dubbo-go 應用服務呼叫。發現 proxyless 在請求耗時方面比 sidecar 模式少一個數量級，即效能提升十倍左右。
3 跨生態
Dubbo-go 是一個橫跨多個生態的服務框架。
-
mesh 生態
- 開發人員可以使用 Dubbo-go 進行應用開發的同時，使用 Istio 生態所提供的強大能力。
-
gRPC 生態
- Dubbo-go 支援與 gRPC 服務互通，HTTP2 協議棧。
- Dubbo-go 預設使用 pb 序列化方式，高效能。
-
Dubbo 生態
- 多語言優勢，可以實現 go-java 應用互通。
- 相容 pixiu 閘道器，方便地進行服務的暴露和協議轉換。
- 使用 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 也將繼續在雲原生的方向前進，繼續發掘雲端計算時代技術紅利，與開發者同在。
本文為阿里雲原創內容，未經允許不得轉載。