李志信（github @laurencelizhixin），dubbo-go 3.0 負責人，Apache Dubbo PMC，來自阿里雲中間件團隊，從事 Go 語言中介軟體的研發和開源工作。
於雨 （github @AlexStocks），dubbo-go 社群負責人，Apache Dubbo PMC，螞蟻集團可信原生部【TNT】基礎設施和中介軟體研發一執行緒序員。工作十一年來陸續參與和改進過 Redis/Pika/Pika-Port/etcd/Muduo/Dubbo/dubbo-go/Sentinel-golang/Seata-golang 等知名專案。
牛學蔚（github @justxuewei），Apache Dubbo Committer，北郵計算機學院二年級研究生，對中介軟體、雲原生領域有著濃厚的興趣。
董劍輝（github @Mulavar），Apache Dubbo Committer，目前主要關注的開源方向為 Dubbo、Flink、Calcite。
Go 語言作為最流行的雲原生語言，近些年擁有很高的熱度，一度備受國內開源生態的關注，據筆者瞭解，眾多企業也在近年來從自身傳統技術棧轉型 Go 語言技術棧。Go 以其開發敏捷、易用性高、入門較為容易的優勢深受廣大開發者青睞。而在 Go 語言生態成日益蓬勃發展之勢下，其生態的完備性，相比於飽經考驗的 Java 生態依然有著很大的 Gap，對中小型企業來說，依然需要類似於 Spring 的 Go 框架來支撐日常業務開發，渴望具備 Dubbo 生態的易用性和穩定性，在這樣的訴求之下，初衷為 “Bridging The Gap Between Java And Go” 的 Dubbo-go 服務框架在 2016 年應運而生，發展至今。
我們在今年下半年的雲計算基礎架構大會上了解到了“基礎架構能力下沉”的重大意義，從單體架構到雲原生架構的一步步發展，都在努力將業務程式碼與中介軟體解耦，儘可能提供統一的程式設計介面，透過AOP的思路將服務呼叫抽象化，將介面標準化，將基礎設施的實現下沉化。而 Dubbo-go 正是在原有保證網路通訊的高可用、穩定性的前提下，整合了一批常用開源元件，提供一致的程式設計介面可供擴充套件和呼叫。在此之上，對齊 Dubbo 生態主流控制面，嘗試與雲原生結合，朝向 Proxyless Service Mesh 方向發展，是我們整個生態專案的一致的願景。
在 3.0 時代，我們的“野心” 不會止步於已有的使用者使用場景和基礎框架能力，我們選擇追求高可用、多語言、跨生態的優點，打造新一代微服務基礎設施，實現 “Bridging The Gap Between X And Go”，在擴充套件 Go 生態的同時，也實現各種基礎設施的雲原生化。
一 Dubbo-go 簡介
Dubbo-go 是常新的，每年都在不斷進化。介紹 Dubbo-go 3.0 工作之前，先回顧其過往 6 年的發展歷程，以明晰未來的方向。
1 什麼是 Dubbo-go
github.com/apache/dubbo-go 是一款高效能 Go 語言微服務 RPC 框架，在 Dubbo 多語言生態中扮演重要角色，是編寫 go 語言微服務的最佳選擇之一。
開發者可以使用 Dubbo-go 框架高效地編寫 RPC 服務，並支援與 Dubbo、gRPC 服務跨語言互通；您可以使用 Dubbo 生態強大的服務治理能力和運維能力，例如服務註冊發現、負載均衡、配置中心、視覺化等功能；您也可以使用 Dubbo-go 生態的 pixiu 閘道器將服務暴露給叢集外部訪問。
Dubbo-go 專案由於雨於 2016 年創立，2018 年開始組建開源社群，2019 年專案正式進入 Apache 軟體基金會，經歷三年多不斷地迭代和最佳化，2021 年底 dubbogo 社群正式推出整合 新通訊協議、新序列化協議、新應用註冊模型、新路由以及新的服務治理能力的 v3.0 版本，該版本在前期研發階段已經擁有了眾多生產使用者的關注和使用。
Dubbo-go 是阿里開源專案中最活躍的開源社群之一，多年的發展使社群積累了眾多熱愛開源的活躍貢獻者、 Apache Committer/PMC 成員。不僅給 Dubbo 以及其他 Dubbo 生態專案示範了透過社群的組織運營幫助專案發展，而且幫助了提升了整個 Dubbo 大社群的活躍度：
-
包括 Apache/Dubbo 與 Apache/Dubbo-go 在內的 Dubbo 生態被評為 2021 年中國 20 大最活躍社群之一，位居阿里所有開源專案第二【第一是螞蟻集團的 AntD】
-
Dubbo-go 已經成功申報中國科學技術協會主辦的「 2021“科創中國”開源創新榜評選 」
-
Dubbo-go 開源社群被 OSCHINA 評為“2021 年度 OSCHINA 優秀開源技術團隊”
2 功能介紹
Dubbo-go 目前已經達成了其初始使命 “Bridging The Gap Between Java And Go” ，具備了強大的互聯互通能力，並在雲原生方向取得了長足的進展。
Dubbo-go 生態覆蓋多種網路協議：Triple、Dubbo、JSONRPC、gRPC、HTTP、HTTP2等。
其中 Triple 協議是 Dubbo3 生態主推的協議，是基於 gRPC 的擴充套件協議，底層為HTTP2，可與 gRPC 服務互通。相當於在 gRPC 可靠的傳輸基礎上，增加了 Dubbo 的服務治理能力。
Dubbo-go 生態整體已經與 Dubbo、gRPC、Spring Cloud 等生態互聯互通，把東西向和南北向資料面流量統一於一體：既可以透過 Dubbo-go 進行東西方向服務呼叫，也可以在 Dubbo-go-pixiu 中進行南北向流量治理。
在服務註冊發現方面，支援 Nacos 、Zookeeper、ETCD、Consul、Polaris-mesh（騰訊開源） 等服務註冊中介軟體，並擁有可擴充套件能力。我們也會根據使用者使用情況，進一步擴展出使用者需要的實現。
在配置中心方面，開發者可以使用Nacos、Apollo（攜程開源）、Zookeeper 進行框架/使用者的配置的釋出和拉取。
在流量控制方面，我們內建實現了固定視窗、滑動視窗等知名的限流演算法，同時也支援與第三方成熟的限流熔斷框架 Hystrix，Sentinel-golang 等整合提供治理功能。
在分散式事務方面，我們支援 Seata-golang，實現了 TCC 模式分散式事務的呼叫。
在鏈路追蹤方面，我們支援基於 Jaeger、ZipKin 的鏈路追蹤能力。
在指標視覺化方面，我們支援使用 Prometheus 收集框架指標和使用者指標。
3 目標使用者
Dubbo-go 從開始即是面向生產環境基於使用者的實際需求構建開發的，其目標使用者如下。
-
如果您是 Go 語言微服務開發者，希望基於輕量級微服務框架快速開發自己的服務，那麼 Dubbo-go 3.0 將是您很好的一個選擇。
-
如果您是 Dubbo 生態使用者，或者在語言切換的過程中面對相容性問題，Dubbo-go 在多協議跨語言互通的場景下會祝您一臂之力。
-
如果您希望在 gRPC 生態中增加服務治理能力，Dubbo-go 可幫助您很容易地從 gRPC 接入 Dubbo 生態，在不改變業務程式碼的情況下提供服務治理能力的支援。
如果你在為公司選擇雲原生解決方案，dubbogo 3.0 提供的 proxyless service mesh 也是一個很好的選擇，它可以幫助你以最低的成本助你從微服務體系接入 istio 控制面。當然，dubbogo 的控制面能力還需要進一步加強，在未來的 3.1 版本中提供 proxyless 和 proxy 兩套 service mesh 方案。
二 Dubbo-go 3.0 有哪些不同
Apache 軟體基金會頂級專案 Dubbo 開源至今已有十年時間，而作為第三個里程碑，也是雲原生時代的全新版本，Dubbo 3.0 的研發工作最早可以追溯到2018年，作為 Dubbo 多語言生態的重要一環，Dubbo-go 社群也在2020年年底，將 3.0 版本作為主推方向。
在官方新特性支援（Triple 協議、應用級服務發現、路由規則、柔性服務等等）的基礎之上，Dubbo-go 社群針對使用友好性，多語言多生態的相容性，使用者程式設計和使用習慣等方面重點進行了最佳化，與其說 Go 社群的 3.0 是一次版本對齊的迭代，不如說是一個富有生命力的新開始。
1 新配置方案
在 3.0 時代，我們更清晰地規範出了應用層級配置和介面層級配置的概念，相比於之前版本，在配置結構上進行了重構和精簡化。例如開發者在微服務場景之下，會關注註冊中心地址、協議、介面名等資訊。只需要在配置檔案中制定好：
dubbo:registries: ZKRegistry: # 註冊中心配置protocol: zookeeper # 註冊中心型別address: 127.0.0.1:2181 # 註冊中心配置protocols:triple: # 協議配置name: tri # 協議名port: 20000 # 服務端監聽埠provider: services:GreeterProvider: # 服務提供者類名interface: com.dubbogo.sample.DemoServiceName # 介面 ID
-
在 Dubbo-go 3.0 中，可以將上述框架配置或使用者配置放置在配置中心內便於管理。在容器內只需要放置配置中心相關資訊即可基於該配置啟動框架。
dubbo:config-center: # 配置中心資訊protocol: nacosaddress: 127.0.0.1:8848data-id: dubbo-go-samples-configcenter-nacos-server
-
開發者可以在程式碼內透過配置 API 生成配置例項結構，程式碼中生成的配置與從檔案內讀取的配置等價。參考於 Java Builder 的設計來自於社群同學們，也代表了開發者對於介面易用性的訴求。
// 1. 透過 Builder 模式建立配置中心的配置configCenterConfig := config.NewConfigCenterConfigBuilder().SetProtocol("nacos").SetAddress("127.0.0.1:8848").SetDataID("dubbo-go-samples-configcenter-nacos-server").SetGroup("dubbogo").Build()// 2. 透過 Builder 模式建立根配置rootConfig := config.NewRootConfigBuilder().SetConfigCenter(configCenterConfig).Build()// 3. 載入配置並啟動框架rootConfig.Load()
2 Triple + PB 協議
Dubbo-go 在上半年首次釋出的 3.0.0-rc1 版本內已經支援 Triple 協議。在此期間，由合作方釘釘部門相關同學提出了較多針對響應時延、穩定性等最佳化建議。時至今日，在效能、使用者使用體驗、泛化呼叫、異常回傳、PB反射等方面都進行了大量的最佳化工作。
-
將舊版本基於 net/http2 的實現切換為基於 grpc 的 http2 層實現方案。增強了底層傳輸的穩定性和效能。經過壓測，4c8g 單機 Provider 可以處理 7萬 tps 的簡單請求。
我們使用了 3 臺相同規格機器，一臺作為Server(執行一個 triple-server），一臺作為Client（執行一個triple-server 和triple client） ，一臺作為施壓機向 Client 發起針對整個鏈路的呼叫施壓，並進行資料記錄，記錄rt、真實 tps 以及client 和 server 的 CPU 佔比資料。
透過壓測結果我們可以看到，我們在多跳鏈路和單機上萬級別tps的實驗環境下，可以保證毫秒級請求時延，並維持合理的 CPU 資源佔用率。
-
Triple 預設開啟 proto 反射，使用者可以使用 grpc_cli 針對 Triple 協議暴露的pb序列化服務進行展示和除錯。
在 proto 反射支援的前提下，dubbo-go-pixiu 提供了閘道器層協議轉換呼叫 triple 服務的支援。
$ grpc_cli ls localhost:20000org.apache.dubbogo.samples.api.Greetergrpc.reflection.v1alpha.ServerReflection
-
使用者程式設計方式
新 PB 編譯外掛，新版本 dubbo-go 推薦 go 使用者使用 proto 檔案定義介面，與 gRPC-go 的使用方式類似。
$ go install github.com/dubbogo/tools/cmd/protoc-gen-go-triple@v1.0.5$ protoc --go_out=. --go-triple_out=. ./helloworld.proto
關於 Triple 協議，最早是阿里雲中間件團隊在 Dubbo3 形成概念的時候就提出的。它相比於上一代 Dubbo 協議，解決了 Dubbo 生態與其他雲原生架構生態不互通的特點，並且使用者很難理解位於傳輸層的上一代二進位制協議。基於 HTTP2 協議的 gRPC 擴充套件協議就很好滴解決了這一問題。第二是點是對 Mesh 等閘道器型元件不夠友好，在 3.0 時代，我們可以直接透過解析協議頭來獲取必要的元資料，並很自然地適配閘道器對於 HTTP 協議的轉發實現。
從我們社群所對接的 Go 語言開發者考慮，PB 序列化更能適配與他們的開發習慣，方便從已有 gRPC 服務遷移業務程式碼，還解決了升級過程中跨協議通訊的相容性問題，而在使用 Triple 協議後，跨語言互通的優勢將進一步體現，從“可互通” 轉變為基於成熟序列化方案的“穩定性互通”，方便使用者業務更廣泛的擴充套件，簡單來說，在 Dubbo 時代，使用者進行跨語言互通需要依賴多語言生態的 Dubbo 協議實現，而在3.0 時代，您可以使用任意語言的 gRPC 實現來與 Dubbo 服務直接進行互通，並共享 gRPC 生態的一系列元件，例如鏈路追蹤、視覺化、cli 工具等等。
因此，我們認為 Triple 的意義並不是一個簡單的擴充套件協議，而是一個跨語言、跨生態概念的實現，也是 Dubbo3 的核心 Feature 所在。
3 柔性服務
大規模分散式系統承載的使用者流量呈指數級增長，需要使用負載均衡演算法將流量均勻地分散到各個機器中，提升叢集的吞吐率和資源利用率。
傳統負載均衡演算法大多是基於消費者視角，它們共同的侷限性是無法根據服務提供者的當前狀態動態調整分流策略，如 RR、hash 等演算法。這些演算法總是以儘可能公平的機率分配流量，但在實踐中公平不等於負載均衡。
-
動態效能評估：使用者不需要事先設定機器權重，框架在執行時自動評估系統性能，效能好的機器承擔更多流量，效能不足的機器承擔更少的流量；
-
故障自愈能力：負載均衡演算法能夠自動摘除故障的節點，並具備故障自愈能力；
柔性服務作為新一代負載均衡策略被引入 Dubbo-go 3.0 中，核心能力包括容量評估和智慧分流。
容量評估是評估當前服務提供者狀態以保持最優請求佇列長度。容量評估關注的兩個核心指標是 TPS 和延遲，TPS 評估系統的每秒處理事物的速度，延遲反映使用者等待時間。在評估服務端容量時，要平衡系統吞吐率和使用者等待時間兩者之間的關係，理想狀態下在系統吞吐率儘可能大的情況下使用者延遲儘可能小。
真實容量受到硬體和下游依賴的限制，一次性預測真實容量難度較高。如上圖所示，TPS 在到達最佳值之前，與請求數呈單調遞增的關係。在 Dubbo-go 3.0.0 版本中，我們引入了爬山演算法（HillClimbing），在呼叫過程中逐步逼近系統的最佳承載量。
HillClimbing 演算法作用於服務提供者，週期性地判定當前是否處於最佳狀態並動態更新系統容量。
探測間隔隨著時間逐步拉長，直至趨向穩定。剛啟動時沒有歷史資料，此時需要頻繁更新容量評估值，保證系統以儘可能快的速度探測到最優容量。我們假定最優容量短時間內不會再強烈波動，且容量評估也會額外消耗資源，因此當趨向穩定的時候，演算法將逐步延長探測週期。
容量更新策略與 TCP 擁塞控制相似。下面公示表示 HillClimbing 演算法預設的兩種增量型別：
其中，lim 表示當前容量，itv 表示當前探測間隔。
在初期採用慢啟動策略，取一個較低水平的值作為容量初始值，但是以較高增量（alpha）向最優容量逼近。如果當前容量已經增長到 TPS 降低的情況，則使用較低增量（beta）以更精準的方式向最優容量移動。
在每次呼叫過程結束後，服務提供者會透過 Dubbo-go 的附件（attachment）特性將最新的預估容量返回給服務消費者，消費者將資訊快取至本地並使用 P2C 演算法實現智慧分流。
P2C（Pick Two Random Choices）演算法作用於服務消費者，它有著更科學的負載均衡策略並廣泛的應用在多個知名開源專案中，如 Linkerd、Rsocket 等。該演算法首先隨機選擇兩個節點，然後對比節點的剩餘容量，選擇其中一個剩餘容量較多的節點作為本次呼叫的服務提供者。
柔性服務將在後續版本中持續最佳化，與 Dubbo 社群共同探索出一套適合微服務場景的柔性服務最佳實踐。
4 Pixiu 閘道器
Dubbo-go-pixiu 閘道器支援呼叫 GO/Java 的 Dubbo 叢集。在 Dubbo-go 3.0 的場景下，我們可以透過 Pixiu 閘道器，在叢集外以 HTTP 協議請求 pixiu 閘道器，在閘道器層進行協議轉換，進一步呼叫叢集內的Dubbo-go 服務。
使用者呼叫 Dubbo-go 服務的 path 為http://$(app_name)/$(service_name)/$(method)。
package org.apache.dubbo.quickstart.samples;service UserProvider {rpc SayHello (HelloRequest) returns (User) {}}message HelloRequest {string name = 1;}
並在dubbo-go 服務啟動時在dubbogo.yml 內配置應用名為my-dubbogo-app:
dubbo:application:name: my-dubbogo-app
pixiu 閘道器即可解析 path 為 my-dubbogo-app/org.apache.dubbo.quickstart.samples.UserProvider/SayHello 的路由，並轉發至對應服務。來自外部HTTP 請求的 body 為 json 序列化的請求引數，例如 {"name":"test"}。
使用者可以在自己的集群裡部署我們的demo，叢集最好擁有暴露 lb 型別 service 的能力，從而可以在公網訪問至叢集內的服務，您也可以直接叢集內進行請求。
$ kubectl apply -f https://raw.githubusercontent.com/dubbogo/triple-pixiu-demo/master/deploy/pixiu-triple-demo.yml
會在 dubbogo-triple-nacos 名稱空間下建立如下資源，包含三個 triple-server，一個pixiu閘道器，一個 nacos server。並透過 Servcie 將服務暴露至公網。
namespace/dubbogo-triple-nacos createdservice/dubbo-go-nacos createddeployment.apps/dubbogo-nacos-deployment createddeployment.apps/pixiu createddeployment.apps/server createdservice/pixiu created
$ kubectl get svc -n dubbogo-triple-nacosNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGEdubbo-go-nacos ClusterIP 192.168.123.204 <none> 8848/TCP 32spixiu LoadBalancer 192.168.156.17530.XXX.XXX.XX 8881:30173/TCP 32s
透過curl 呼叫 demo 服務，並獲得響應結果。
$ curl -X POST -d '{"name":"laurence"}'http://30.XXX.XXX.XX:8881/dubbogoDemoServer/org.apache.dubbo.laurence.samples.UserProvider/SayHello{"name":"Hello laurence","id":"12345","age":21}
5 運維能力與工具
相比於上一版本的 Dubbo-go，本次釋出在原來Dubbo協議的可觀測性的基礎上，提供了基於 Triple 協議可觀測性支援，適配於 Jaeger 的鏈路追蹤展示。對於資料上報，我們在框架中為之提供了介面，方便使用者即時上報業務埋點資料，並預設開啟 promehteus 的拉模式資料收集的支援。
框架對於 RPC呼叫相關資訊，例如請求RT，介面名、方法名等資料，也提供了預設的 metrics 欄位，供使用者收集和統計。
本次發版對日誌模組進行了較大的改變和更新，使用者可以根據需求配置日誌列印的級別、分片、檔案輸出、保留時常等資訊，並支援使用者自定義日誌元件。
Dubbo-go 3.0 會針對命令列工具進行重點開發，目前社群已提供用於發起 Dubbo RPC 呼叫的dubbo-go-cli；用於編譯 pb 檔案的protoc-gen-go-triple 外掛；並且 Dubbo-go 已經適配 grpc_cli 工具的除錯，在未來，我們會在健康檢查、服務資訊獲取、RPC 呼叫除錯、框架程式碼初始化和介面編譯、服務部署等方面，進一步增強命令列工具的能力，以提供更完備的服務治理和運維生態。
三 使用者視角的 Dubbo-go
作為一款站在使用者角度設計的框架，我們更希望給予廣大使用者更簡潔，更直觀，更“約定大於配置”的使用體驗，因此在研發階段，我們重點進行了多輪的配置迭代以及 samples 倉庫的建設和維護，為使用者提供了更為精簡的概念和重點突出的 samples 示例。
1 面向介面和配置的開發
Dubbo-go 3.0 為開發者遮蔽掉了底層實現細節，只需要關注幾個關鍵點即可使用本框架進行開發，以 triple 服務為例。
-
編寫 proto 檔案，並使用提供的 protoc-gen-go-triple 外掛以及官方 protoc-gen-go 外掛進行編譯。
-
介面、實現、配置。是常見 go 微服務的基本依賴元素。Dubbo-go 提供一整套微服務的解決方案，並提供豐富的服務治理能力和可擴充套件能力，從而可以讓使用者容易地接入使用。
2 程式碼示例倉庫 dubbo-go-samples
我們在apache/dubbo-go-samples 倉庫的 master 分支維護了豐富的 dubbo-go 3.0 的程式碼示例。包括多種協議的 rpc 呼叫，多種註冊中心的支援，多種配置中心的使用，以及泛化呼叫、配置API、日誌、資料上報、鏈路追蹤等運維能力的展示，幾乎框架擁有的全部能力都可以在 samples 倉庫中找到對應的常見用例。使用者也可以在1.5分支找到適配與dubbo-go 1.5.x 的示例。
透過 3.0 前期階段對於配置重構和大幅度的使用者友好性最佳化，目前 samples 倉庫內的程式碼和配置都已經高度精簡化，從而突出單個模組的能力。開發者可以下載倉庫後直接按照server 到 client 的順序來玩耍一個啟例模組的服務，即可體驗框架提供的能力。
samples 倉庫在迭代過程中也被賦予了更多的功能，社群開發同學都會熟悉，我們將框架倉庫、samples 倉庫透過 ci 整合測試的方式結合起來，保證框架開發者每次提交的程式碼都能透過所有用例的 e2e 測試，從而保障開發質量，提高迭代的效率。
四 社群協作
作為一個能力功能非常豐富的服務平臺，dubbogo 社群很重視與各大開源社群特別是阿里系開源產品社群以及各個公司的合作。
早期 Dubbo-go 社群就與 Nacos 社群展開密切合作，由多位核心貢獻者參與 Dubbo-go 研發支援中，在 3.0.0 版本中，增加了多位 Nacos 社群成員，在社群迭代中作出了許多建設性的建議和貢獻。
北極星（Polaris）是騰訊開源的服務發現和治理中心，致力於解決分散式或者微服務架構中的服務可見、故障容錯、流量控制和安全問題。在 3.0.0 版本的開發中，Dubbo-go 社群與 Polaris 社群展開合作，實現了把 Polaris 作為 dubbo-go 的註冊中心。
Sentinel 是面向分散式服務架構的流量控制組件，在Sentinel-Golang 首個版本 0.1.0 正式釋出後，Dubbo-go 社群就與 Sentinel-Golang 社群展開密切合作，在功能上支援 Sentinel-Golang 作為流量控制。
從 dubbogo v1.3 開始， 就集成了 seata-golang，實現了 TCC 模式分散式事務的呼叫。
兩個社群現已合作將 TCC 模式 seata-golang 整合到了 dubbo-go-pixiu 中，只需要簡單的配置、就能整合 TCC 模式協調分散式事務的方案，整體流程原理見上圖。為了進一步降低大家使用分散式事務的門檻，seata-golang 社群也在考慮將 AT 模式做到 DB 代理層，屆時在 dubbo-go-pixiu 中使用 seata-golang 會更加方便，敬請期待。
dubbogo 本身是一個有著極高生產環境需求的專案，在發展過程中與阿里等很多公司有過合作。這些合作使得雙方都有收益，dubbogo 的質量得以保證，功能得以拓展，合作方自身的平臺穩定性得到極大提升。
五 展望
前面講到，Dubbo-go 3.0 對我們來說是一個新時代的起點，在未來的迭代中，我們除了繼續維護上述流量排程以及服務治理能力之外，還會基於幾個
1 流量路由規則
Dubbo-go 3.0 在路由規則方面設計與 dubbo 一致，提供了支援 mesh 方式的路由規則策略並接入了 dubbo-admin 這一控制面板。
在 mesh 路由方面，dubbo-go 將路由規則分為 VirtualService 和 DestinationRule 兩部分，其中 DestinationRule 定義了目標地址的規則，透過 subset 和 host 關聯到對應的叢集，而 VirtualService 則定義了具體的路由匹配規則。當客戶端發起一次呼叫時，首先經過 VirtualService 路由到具體的 subset，然後根據 DestinationRule 中對應 subset 的 labels 資訊找到具體的叢集。這種設計方式將路由規則和目標地址進行了解耦，支援 VirtualService 和 DestinationRule 的多種組合，實現了更加靈活的路由策略，也可以更加輕易實現 A/B 測試、金絲雀釋出、藍綠髮布等能力。
關於接入 dubbo-admin 一塊工作，目前 dubbo-go 已經重構了 zookeeper 配置中心的程式碼邏輯，並實現了和 dubbo-admin 互通，即使用者可以在 dubbo-admin 上動態釋出、更新路由來排程叢集內流量（目前僅限 zookeeper），而應用可以立即感知，無需重啟。在不久的未來我們會繼續深入打通這一部分的能力互通，支援 nacos 等其他常用配置中心、註冊中心的互通，徹底實現控制面板與資料面板的分離。
2 統一控制面與服務架構創新
我們將推出相容 Dubbo-admin 的統一控制面，可在控制面中透過路由配置動態排程叢集內流量，將新路由規則以更靈活、更易用的方式落地在生產場景下，運維人員也可以在控制面上一目瞭然地瞭解到叢集內 dubbo-go 應用的即時情況，進一步來講，控制面將會擁有服務測試、灰度釋出、監控、流量排程等一系列運維能力。
我們還會在適配於 pixiu 閘道器協議轉換的基礎之上，進一步發掘閘道器的能力，朝 proxyless service-mesh 的方向探索新的微服務架構。
3 進一步雲原生化
我們將在 dubbo-go 1.5 版本在 k8s 方向探索的基礎之上，進一步支援雲原生能力，計劃包含探針、配置、資源監聽等方面，使得框架在雲原生架構下具有更好的使用體驗，更多樣的服務治理能力。
資料採集系統 Flume 快速入門
