建站
咨詢
售后
建站咨詢
新聞中心
一、什么是 Proxyless Service-Mesh (無代理服務網格) ?
1.Service Mesh 簡析
Istio 是當今最流行的開源服務網格。它由控制平面和數據平面構成，其架構如下(圖片摘自 Istio官網)。
位于圖中下半部分的控制平面負責配置、服務信息、證書等資源的下發(fā)。位于上半部分的數據平面關注業(yè)務之間的通信流量;傳統(tǒng)服務網格通過代理的方式攔截所有的業(yè)務網絡流量，代理需要感知到控制平面下發(fā)的配置資源，從而按照要求控制網絡流量的走向。
在 Istio 環(huán)境中，其控制平面是一個名為 istiod 的進程，網絡代理是 envoy 。istiod 通過監(jiān)聽 K8S 資源 例如Service、Endpoint 等，獲取服務信息，并將這些資源統(tǒng)一通過 XDS 協(xié)議下發(fā)給位于數據平面的網絡代理。envoy 是一個獨立的進程，以 sidecar(邊車)的形式伴隨業(yè)務應用 Pod 運行，他與應用進程共用同一個主機網絡，并通過修改路由表的方式，劫持業(yè)務應用的網絡流量。
Service Mesh 可以解決微服務場景下的眾多問題，隨著集群規(guī)模的擴大與業(yè)務復雜度的增長，基于原生 k8s 的容器編排方案將會難以應付，開發(fā)人員不得不面對巨大的服務治理挑戰(zhàn)。而 Service Mesh 很好地解決了這一問題，它將服務治理需求封裝在了控制平面與代理中，業(yè)務開發(fā)人員只需要關注于業(yè)務邏輯。在應用部署之后，只需要運維人員通過修改配置，即可實現(xiàn)例如故障恢復、負載均衡、灰度發(fā)布等功能，這極大地提高了研發(fā)和迭代效率。
Istio 的 sidecar 通過容器注入的形式伴隨業(yè)務應用進程的整個生命周期，對于業(yè)務應用是毫無侵入的，這解決了業(yè)務應用可遷移、多語言、基礎架構耦合等問題。但這也帶來了高資源消耗、請求時延增長的問題。
Service 為服務治理提供了一個很好的思路，將基礎架構與業(yè)務邏輯解耦，讓應用開發(fā)人員只需關注業(yè)務。另一方面，由于 sidecar 的弊端，我們可以考慮使用 sdk 的形式，來替代 sidecar 支撐起數據平面。
2.Proxyless Service-Mesh
無代理服務網格，是2018年谷歌提出的一個新的概念，Isito、gRPC、brpc 等開源社區(qū)都在這一方向進行了探索和實踐。無代理服務網格框架以 SDK 的形式被業(yè)務應用引入，負責服務之間的通信、治理。來自控制平面的配置直接下發(fā)至服務框架，由服務框架代替上述 sidecar 的功能。
在無代理服務網格場景下，服務框架(SDK)的主要能力可以概括為以下三點：
- 對接控制平面，監(jiān)聽配置資源。
- 對接應用，為開發(fā)者提供方便的接口。
- 對接網絡，根據資源變動，響應流量規(guī)則。
3.Proxyless 的優(yōu)缺點
我認為優(yōu)點如下：
- 性能：無代理模式的網絡調用為點對點的直接通信，網絡時延會比代理模式小很多。
- 穩(wěn)定性：proxyless 的模式是單進程，拓撲簡單，便于調試，穩(wěn)定性高。
- 框架集成：市面上已有眾多 sdk 模式的服務框架，切換至 mesh 后便于復用框架已有能力
- 資源消耗：沒有 sidecar，資源消耗低。
當然，缺點也有很多：
- 語言綁定：需要開發(fā)多種語言的 sdk
- 可遷移性低：無法通過切換 sidecar 的形式來無侵入地升級基礎設施。
總體來講，我認為 Proxyless 架構以其高性能、高穩(wěn)定性的特點，更適合與生產環(huán)境使用。
二、Dubbo-go 與 Proxyless Service-Mesh
1.Dubbo-go 的能力
Apache/Dubbo-go (github.com/apache/dubbo-go)，是一款分布式 RPC 框架，是 Apache/Dubbo 的 Go 語言實現(xiàn)。旨在為開發(fā)者提供便利的微服務應用開發(fā)體驗。Dubbo-go 生態(tài)為 Go 開發(fā)者提供了敏捷的微服務編程接口、配置管理方案、服務治理方案、以及一系列工具與腳手架，開發(fā)人員可以使用框架提供的能力快速開發(fā)自己的微服務應用。
2.Dubbo-go 在 Proxyless Service-Mesh 場景的設計
服務注冊發(fā)現(xiàn)
Dubbo-go 本身擁有可擴展的服務注冊發(fā)現(xiàn)能力，我們?yōu)?service mesh 場景適配了注冊中心的實現(xiàn)。開發(fā)人員可以將 dubbo-go 應用的信息注冊在 istiod 控制平面上?？蛻舳藨每梢圆樵円呀涀缘慕涌跀祿瓿煞瞻l(fā)現(xiàn)過程。
歸因于 Java 的編程習慣，Dubbo-go 生態(tài)框架的服務注冊方式都是接口級別的。即客戶端只需要引入接口，即可發(fā)起調用，而無需關心下游的應用名、主機名、IP 地址等信息。與之相對的是應用級別的服務注冊發(fā)現(xiàn)，主流微服務框架更多這種形式的服務調用方式，例如 gRPC、K8S、Istio，應用級服務發(fā)現(xiàn)對應到 mesh 場景下，我認為叫 “主機級別服務發(fā)現(xiàn)”更合適，這種調用方式需要客戶端在引入接口的同時，還需引入下游的主機名和端口號。熟悉 gRPC-go 的同學一定很清楚，除了引入 pb 接口，還需要在創(chuàng)建客戶端時調用 gRPC.Dial("xxx") 建立網絡連接。而這里的 xxx 就是下游的主機名和端口號，這種服務發(fā)現(xiàn)的類型和用戶編程習慣，導致了 gRPC 較為輕松地實踐了 Proxyless Service Mesh。
關于應用級服務發(fā)現(xiàn)與接口級服務發(fā)現(xiàn)的區(qū)別和 dubbo 生態(tài)的解決方案，本文中不多贅述，可以參考劉軍前輩寫的文章文章《Dubbo 邁出云原生重要一步 應用級服務發(fā)現(xiàn)解析》簡單來說，應用級服務發(fā)現(xiàn)需要開發(fā)者關心接口之外還要關心應用名，注冊中心的冗余信息較少;接口級服務發(fā)現(xiàn)開發(fā)者只需要引入接口名，但注冊中心的冗余信息較多。
熟悉 Dubbo-go、Dubbo 生態(tài)的用戶，不習慣于在編程的過程中指定下游主機名，更希望以接口引入的方式，直接發(fā)起 RPC 調用，而不需關心究竟這個接口被哪個應用實現(xiàn)，運行在哪臺主機、哪個虛擬集群上。
Dubbo-go 為了融入 Istio 體系，將擴展出來的注冊發(fā)現(xiàn)流程進行了特殊改造。在復用 Istio 提供的 EDS、CDS 主機發(fā)現(xiàn)的能力之外，增加了接口名到主機名的映射，作為源數據注冊在了控制平面上?？蛻舳嗽诎l(fā)起調用前持有接口名，通過查詢istiod 上的元數據信息，拿到接口名到主機名到映射，轉換為主機名;再通過EDS、CDS和路由，完成主機名到下游端點實例的轉換。完成服務發(fā)現(xiàn)流程。
下面用一個更詳細的例子來說明服務發(fā)現(xiàn)過程：
- 開發(fā)人員使用 dubbogo-cli 工具創(chuàng)建應用模板，發(fā)布 Deployment / Service pair 到集群中。
- 服務端拉取全量 CDS 和 EDS 數據，比對本機 IP，拿到當前應用的的主機名。并將本應用的所有接口名到主機名的映射，注冊在 Istiod 上面。
- 客戶端從 istiod 拉取全量接口名到主機名的映射，緩存在本地。當需要發(fā)起調用時，查詢本地緩存，將接口名轉換為主機名，再通過CDS 和 EDS 拉取到當前 cluster 所對應的全量端點。
- 全量端點經過 Dubbo-go 內置的 Mesh Router，篩選出最終的端點子集，并按照配置的負載均衡策略進行請求。
- 開發(fā)人員或者第三方組件，通過操作 K8S 資源，控制 Dubbo-go 流量。
縱觀這一過程，開發(fā)人員全程只需要關注接口即可，完全無需關心主機名和端口信息。即服務端開發(fā)者只需要實現(xiàn)pb接口，使用框架暴露出來;客戶端開發(fā)者只需要引入pb接口，直接發(fā)起調用即可，可以跟隨本文第四部分的教程來動手實驗一下。
流量治理
Dubbo-go 擁有路由能力，通過 xds 協(xié)議客戶端從 istiod 訂閱路由配置，并實時更新至本地路由規(guī)則，從而實現(xiàn)服務的管理。Dubbo-go 兼容 Istio 生態(tài)的流量治理規(guī)則，可以通過配置 Virtual Service 和 Destination Rule，將打標的流量路由至指定子集，也可以在灰度發(fā)布、切流等場景進行更深入地使用。
云原生腳手架
dubbogo-cli 是 Apach/dubbo-go 生態(tài)的子項目，為開發(fā)者提供便利的應用模板創(chuàng)建、工具安裝、接口調試等功能，以提高用戶的研發(fā)效率。
可以執(zhí)行以下指令安裝dubbogo-cli 至 $GOPATH/bin
go install github.com/dubbogo/dubbogo-cli@latest
dubbogo-cli 支持以下能力：
- 應用模板創(chuàng)建
- Demo 創(chuàng)建
- 編譯、調試工具安裝
- 查看 dubbo-go 應用注冊信息
- 調試 dubbo-go 應用接口
- 使用應用模板的開發(fā)流程
- 通過 dubbogo-cli 生成模板
- 修改api/api.proto
- make proto-gen
- 開發(fā)接口
- 修改 makefile 內鏡像名和發(fā)布名
- 打鏡像并推送
- 修改chart/app/values 內與部署相關的value配置
- make deploy, 使用 helm 發(fā)布應用。
詳情可以參閱 dubbogo-cli 文檔[1]。
三、Dubbo-go-Mesh 的優(yōu)勢
1.接口級服務發(fā)現(xiàn)
前文介紹到了通過接口級服務注冊發(fā)現(xiàn)的優(yōu)勢，即開發(fā)人員無需關心下游主機名和端口號，只需要引入接口存根，或實現(xiàn)接口，通過框架啟動即可。
2.高性能
我們在 k8s 集群內部署 Istio 環(huán)境，分別測試了 sidecar 模式的 gRPC 服務調用和 Proxyless 模式的 dubbo-go 應用服務調用。發(fā)現(xiàn) proxyless 在請求耗時方面比 sidecar 模式少一個數量級，即性能提升十倍左右。
3.跨生態(tài)
Dubbo-go 是一個橫跨多個生態(tài)的服務框架。
mesh 生態(tài)開發(fā)人員可以使用 Dubbo-go 進行應用開發(fā)的同時，使用 Istio 生態(tài)所提供的強大能力。
- gRPC 生態(tài)
Dubbo-go 支持與 gRPC 服務互通，HTTP2 協(xié)議棧。
Dubbo-go 默認使用 pb 序列化方式，高性能。
- Dubbo 生態(tài)
多語言優(yōu)勢，可以實現(xiàn) go-java 應用互通。
兼容 pixiu 網關，方便地進行服務的暴露和協(xié)議轉換。
使用 Dubbo-go 生態(tài)組件。
四、動手體驗 Dubbo-go-Mesh
Dubbo-go 目前已支持兼容 Istio 的服務治理能力。支持基于 Istio 的接口級服務發(fā)現(xiàn)能力，兼容 Istio 生態(tài)的流量控制和管理能力，并且提供了腳手架和應用模板以提高 Go 應用開發(fā)效率。
您可參考文檔 【Dubbo-go 文檔 - Mesh 任務】[2]，動手搭建一組 Dubbo-go Mesh 應用。
在這組任務中，開發(fā)者會從部署 Istio 環(huán)境開始，到創(chuàng)建應用模板、構建應用、發(fā)布應用、實現(xiàn)服務發(fā)現(xiàn)和 RPC、到最終完成流量規(guī)則動態(tài)配置，觀察流量切換。對框架用戶有較高的參考意義。
五、展望
Proxyless Service Mesh 能力將跟隨 Dubbo-go 下一版本發(fā)布，穩(wěn)定的性能需要社區(qū)成員們共同的關注與建設。在此基礎之上，我們還會進一步探索輕量級 sdk + sidecar的模型;探索基于第三方流量治理組件的金絲雀發(fā)布能力;探索基于 dubbo 服務框架的多語言 sevice mesh、與更豐富的 mesh 生態(tài)組件兼容。
Dubbo-go 也將繼續(xù)在云原生的方向前進，繼續(xù)發(fā)掘云計算時代技術紅利，與開發(fā)者同在。
[1]:https://dubbogo.github.io/zh-cn/docs/user/refer/use_dubbogo_cli.html[2]:https://dubbogo.github.io/zh-cn/docs/user/tasks/mesh/app.html
當前文章：Dubbo-go-Mesh開啟新一代Go微服務形態(tài)
分享鏈接：http://www.dlmjj.cn/article/cdssiid.html
