愛鋒貝

標(biāo)題: Go 語言體系下的微服務(wù)框架選型：Dubbo-go [打印本頁]
作者: 慧聰師太    時間: 2023-4-12 00:36
標(biāo)題: Go 語言體系下的微服務(wù)框架選型：Dubbo-go
01 Go 微服務(wù)體系發(fā)展與選型

隨著微服務(wù)技術(shù)的快速發(fā)展，其在各個領(lǐng)域都形成了一系列事實(shí)標(biāo)準(zhǔn)，在 Kubernetes 和容器技術(shù)加持下，云原生微服務(wù)已經(jīng)成為了主流解決方案。而 Go 語言作為云原生領(lǐng)域最受歡迎的開發(fā)語言，正被越來越多的企業(yè)作為微服務(wù)開發(fā)的首選語言，其中比較流行的包括 Go-micro、Go-zero、Dubbo-go 等。作為 Dubbo 微服務(wù)體系中多語言實(shí)現(xiàn)的一員，在 2022 年 Dubbo-go 以微服務(wù)領(lǐng)跑者的角色積極擁抱云原生標(biāo)準(zhǔn)，探索了 Proxyless Mesh 形態(tài)，配合適配 Pixiu 云原生網(wǎng)關(guān)，形成了完善的 Dubbo-go 微服務(wù)生態(tài)矩陣。
以 Dubbo-go 為中心的微服務(wù)體系在多個知名企業(yè)中成功落地和實(shí)踐，框架的穩(wěn)定性在實(shí)際場景下經(jīng)受住了考驗(yàn)。截止今年已有 60+ 家企業(yè)在我們的用戶列表中登記，其中較為典型案例請參考文章《小米電商 Apache Dubbo-go 微服務(wù)實(shí)踐》。小米電商選用了 Dubbo-go + Nacos + sidecar + etcd + mirpc 為核心的微服務(wù)體系，除了看中了 Dubbo-go 的互聯(lián)互通和服務(wù)治理能力外，也認(rèn)可 Dubbo-go 在微服務(wù)方向的沉淀和積累。
02 Dubbo-go 簡介

2.1 什么是 Dubbo-go

Apache Dubbo 是一款易用、高性能的 WEB 和 RPC 框架，同時為構(gòu)建企業(yè)級微服務(wù)提供服務(wù)發(fā)現(xiàn)、流量治理、可觀測、認(rèn)證鑒權(quán)等能力、工具與最佳實(shí)踐。Dubbo3 從設(shè)計(jì)上不綁定編程語言，社區(qū)目前提供了 Java、Go、Rust、Node.js 等多語言實(shí)現(xiàn)，在未來，我們計(jì)劃為所有主流語言提供對等的微服務(wù)開發(fā)體驗(yàn)。
Dubbo 框架作為國內(nèi)最具影響力的開源微服務(wù)開發(fā)框架之一，擁有非常高的關(guān)注度和活躍度，在 GitHub 上擁有 3.8 萬+ stars。Dubbo 項(xiàng)目于 2017 年捐贈給 Apache 基金會，在經(jīng)歷了短短 15 個月孵化后順利畢業(yè)，在 Apache 基金會管理的全部項(xiàng)目中關(guān)注度排名第三（前兩名分別是 echarts 和 superset），Dubbo-go 作為 Dubbo 多語言生態(tài)的重要一員，很好的兼容 Dubbo 生態(tài)的同時提供面向 Go 語言體系的微服務(wù)開發(fā)體驗(yàn)。
Dubbo-go（項(xiàng)目地址 http://github.com/apache/dubbo-go）作為 Dubbo 多語言生態(tài)的重要組成部分，目前完全兌現(xiàn)了 Dubbo3 架構(gòu)的核心能力，并且在云原生時代，憑借 Go 語言無需重量級虛擬機(jī)、靜態(tài)編譯以及垃圾回收的特性，獲得了廣泛關(guān)注，其應(yīng)用規(guī)模也逐漸擴(kuò)大。從特性上來說，Dubbo-go 目前支持 HTTP/2、TCP、gRPC 協(xié)議通信、服務(wù)發(fā)現(xiàn)、流量管控、配置管理、全鏈路追、可視化觀測等諸多新特性，Dubbo3 已是眾多用戶生產(chǎn)環(huán)境首選的微服務(wù)框架（用戶列表）；在生態(tài)建設(shè)方面，Dubbo-go 適配了包括 Zookeeper、Nacos、Sentinel、Zipkin、Kubernetes、Prometheus、云原生 API 網(wǎng)關(guān)項(xiàng)目 Dubbo-pixiu、異步網(wǎng)絡(luò)庫 Dubbo-getty、Hessian2 等生態(tài)項(xiàng)目。
2022 年 Dubbo-go 社區(qū)以生態(tài)互聯(lián)、開發(fā)者體驗(yàn)、穩(wěn)定性為切入點(diǎn)，不斷優(yōu)化系統(tǒng)架構(gòu)，社區(qū)榮獲多個開源獎項(xiàng)：
2.2 重要特性

通信協(xié)議：遵循 Dubbo 核心架構(gòu)設(shè)計(jì)，Dubbo-go 在實(shí)現(xiàn)上不綁定通信協(xié)議，目前支持 HTTP/2、TCP (Dubbo2)、JSONRPC、gRPC、HTTP 等多種通信協(xié)議，開發(fā)者可以根據(jù)使用場景靈活的選擇通信協(xié)議。
服務(wù)注冊：支持 Client-based 服務(wù)發(fā)現(xiàn)機(jī)制，支持注冊中心適配如 Nacos、Consul、Zookeeper 等。Dubbo3 的服務(wù)發(fā)現(xiàn)機(jī)制誕生于阿里巴巴超大規(guī)模微服務(wù)電商集群實(shí)踐場景，其在性能、可伸縮性、易用性等方面的表現(xiàn)大幅領(lǐng)先于業(yè)界大多數(shù)主流開源產(chǎn)品。
配置中心：Dubbo 配置中心可實(shí)現(xiàn)應(yīng)用配置的遠(yuǎn)程托管，支持配置變更的實(shí)時感知，目前支持 Nacos、Apollo（攜程開源）、ZooKeeper 等作為配置中心。
負(fù)載均衡：Dubbo 提供了多種負(fù)載均衡策略，如隨機(jī)負(fù)載均衡策略、一致性哈希負(fù)載、基于權(quán)重的輪詢、最小活躍度優(yōu)先、自適應(yīng)負(fù)載均衡 P2C 等。
流量控制：Dubbo 的流量管控規(guī)則可以基于應(yīng)用、服務(wù)、方法、參數(shù)等粒度精準(zhǔn)的控制流量走向，基于此可靈活的實(shí)現(xiàn)超時時間調(diào)整、開啟訪問日志、金絲雀發(fā)布、參數(shù)路由、同區(qū)域優(yōu)先、按比例流量分發(fā)等。除此之外，通過接入 Hystrix、Sentinel 等，Dubbo-go 還支持自適應(yīng)限流、限流熔斷等。
分布式事務(wù)：支持 Seata-golang 分布式事務(wù)框架，實(shí)現(xiàn)了 AT 模式和 TCC 模式分布式事務(wù)的調(diào)用，AT 模式相較 TCC 模式對代碼的入侵性更小、需要開發(fā)的接口更少，但 AT 模式對事務(wù)操作的數(shù)據(jù)持有全局鎖，TCC 模型性能更好。
鏈路追蹤：支持基于 Jaeger、ZipKin 的鏈路追蹤能力。
指標(biāo)可視化：支持使用 Prometheus 收集框架指標(biāo)和用戶指標(biāo)。
可擴(kuò)展性：Dubbo-go 提供了靈活的 extension 擴(kuò)展機(jī)制，用戶可隨時根據(jù)自己的需求靈活擴(kuò)展服務(wù)發(fā)現(xiàn)、負(fù)載均衡、配置中心、流量管控規(guī)則、全鏈路追蹤等中間件。
03 過去一年我們做了什么

3.1 優(yōu)雅上下線

在微服務(wù)場景下，業(yè)務(wù)是以容器的形式對外提供服務(wù)，k8s 能夠方便的對 Pod 進(jìn)行滾動升級，在舊版本被替換的時候應(yīng)該達(dá)到無損下線的效果，即容器不能被銷毀直到?jīng)]有正在處理的請求。如果其不能被正確實(shí)現(xiàn)，對于承載高流量的在線服務(wù)來說，在更新期間可能會導(dǎo)致大量的請求報(bào)錯，甚至可能觸發(fā)報(bào)警，其影響是巨大的。優(yōu)雅上下線功能是 Dubbo-go 3.0 正式版本發(fā)布后的第一個重大增強(qiáng)，王曉偉同學(xué)（GitHub: @XiaoWeiKIN）貢獻(xiàn)了全流程的優(yōu)雅上下線能力。

(, 下載次數(shù): 191)
Dubbo 經(jīng)典的調(diào)用流程如上圖所示，這里面包含了服務(wù)提供者（Provider）、服務(wù)消費(fèi)者（Consumer）以及注冊中心（Registry）三個關(guān)鍵組件，一個服務(wù)能夠被調(diào)用，首先需要提供者準(zhǔn)備服務(wù)并對外暴露端口（步驟 0），然后提供者需要將調(diào)用信息注冊到注冊中心中（步驟 1），消費(fèi)者則會通過異步訂閱的方式獲取最新的提供者數(shù)據(jù)（步驟 2），注冊中心在有新數(shù)據(jù)后會主動推送給消費(fèi)者（步驟 3），此時消費(fèi)者已經(jīng)有本次調(diào)用的全部信息了，最后消費(fèi)者發(fā)送調(diào)用請求（步驟 4），這樣就完成了整個調(diào)用鏈路。
在單體應(yīng)用中，上述邏輯非常清晰和簡單，但是在大規(guī)模微服務(wù)集群中，這個邏輯的每一個細(xì)節(jié)都需要被仔細(xì)推敲后，才能保證上下線的過程中調(diào)用不出錯。

(, 下載次數(shù): 170)
優(yōu)雅上線的目標(biāo)是解決服務(wù)上線調(diào)用報(bào)錯的問題，主要針對微服務(wù)場景下的調(diào)用依賴問題。在 Dubbo 生態(tài)中，Service 表示一個服務(wù)，能夠被暴露并被其他服務(wù)調(diào)用，Reference 表示引用，可以簡單的理解為下游服務(wù)。一個典型調(diào)用結(jié)構(gòu)如上圖所示，該服務(wù)對外暴露一個接口，同時引用了下游的 N 個服務(wù)。該服務(wù)在上線的時候應(yīng)該嚴(yán)格遵循以下流程，首先保證下游服務(wù)的引用被成功初始化，之后再初始化 Service 對外暴露服務(wù)，最后再向注冊中心注冊服務(wù)。優(yōu)雅上線相對來說邏輯比較簡單，只需要嚴(yán)格遵循初始化過程的依賴關(guān)系就能保證上線過程中服務(wù)能夠被正常調(diào)用。
優(yōu)雅下線是優(yōu)雅上下線的難點(diǎn)，涉及到了信號監(jiān)聽、反注冊、等待已有請求完成調(diào)用等邏輯。在需要銷毀容器的時候，kubelet 會向容器發(fā)送 SIGTERM 信號，Dubbo-go 會進(jìn)入優(yōu)雅下線流程，此時容器并不會立刻被銷毀。即將下線的提供者首先會執(zhí)行反注冊，即向注冊中心中刪除自己的信息，消費(fèi)者可以通過訂閱獲得這個信息，這個過程需要一定的時間。換句話說，在消費(fèi)者獲得這個刪除信息之前，流量還是有可能會流向該提供者，此時提供者應(yīng)該拒絕這部分請求。當(dāng)然除了下線期間的新請求外，還有殘留的來自上游的請求以及自己調(diào)用下游的請求，我們分別為這兩種情況設(shè)置一個計(jì)數(shù)器，當(dāng)兩個計(jì)數(shù)器都被清零時，可以認(rèn)為該提供者是“干凈”的。Dubbo-go 的策略是拒絕新請求，等待已放行的舊請求。最后，銷毀協(xié)議并關(guān)閉監(jiān)聽，該容器就能夠被安全的摘除。
在啟動優(yōu)雅上下線后，集群內(nèi)無錯誤請求，成功率保持在100%。

(, 下載次數(shù): 184)
3.2 新一代柔性服務(wù)

在去年發(fā)布 Dubbo-go 3.0 版本的時候，柔性服務(wù)首次作為一個重要特性被提出。時隔一年，我們帶來了全新升級的新一代柔性服務(wù)，在新版本中我們將爬山算法替換為峰值干預(yù)算法，在經(jīng)過多次測試后新算法行為可控性更高、性能更優(yōu)異，這部分工作由來自北京郵電大學(xué)的張業(yè)鵬同學(xué)（GitHub: @CoolIceV）貢獻(xiàn)。
柔性服務(wù)是一種更智能的負(fù)載均衡算法。傳統(tǒng)負(fù)載均衡算法大多是基于消費(fèi)者視角，它們共同的局限性是無法根據(jù)服務(wù)提供者的當(dāng)前狀態(tài)動態(tài)調(diào)整分流策略，如 RR、hash 等算法。這些算法總是以盡可能公平的概率分配流量，但在實(shí)踐中公平不等于負(fù)載均衡。
爬山算法是一種容量預(yù)估的算法，服務(wù)提供者需要將一些關(guān)鍵信息回傳給消費(fèi)者，比如時延、請求排隊(duì)數(shù)量、預(yù)估容量等，消費(fèi)者使用 P2C 算法選擇一個負(fù)載最低的作為本次請求的提供者。這些數(shù)據(jù)實(shí)效性要求非常高，如果這些數(shù)據(jù)是被動傳遞的，那么很難保證實(shí)效性，如果這些數(shù)據(jù)是被主動探測的，那么在一個大型集群下感知成本非常高?；谏鲜鰡栴}，我們選擇了更可控的峰值干預(yù)算法。
消費(fèi)者部分中，我們使用了改良版的 P2C 算法，采集的指標(biāo)包括請求數(shù)（requests）、成功數(shù)（accepts）、請求時延（rtt）。與原實(shí)現(xiàn)方案不同的是，該版本采用了更合理的滑動窗口（SlidingWindowCounter）和指數(shù)移動平均（EMA）兩種帶有時序性的模塊進(jìn)行采集。
SlidingWindowCounter 會保存時長為統(tǒng)計(jì)周期 T 的數(shù)據(jù)，整個周期內(nèi)的數(shù)據(jù)被分割為若干個 Bucket，每個Bucket 保存計(jì)數(shù)時長內(nèi)的數(shù)據(jù)，當(dāng)前所處的 Bucket 會隨著時間前進(jìn)而向后移動。

(, 下載次數(shù): 190)
EMA 利用指數(shù)移動平均算法進(jìn)行平滑、減小抖動，適用于統(tǒng)計(jì)時延型的指標(biāo)，計(jì)算公式：

(, 下載次數(shù): 207)
以下為一個客戶端請求 3 個服務(wù)端的測試結(jié)果，3 個服務(wù)端配置不同，分別為 1 核 1GB、2 核 2GB、3 核 3GB。蘭青色虛線代表開始使用上述負(fù)載均衡算法，可以看到開啟前每個服務(wù)端接收到的請求數(shù)幾乎相同，開啟之后流量會根據(jù)提供者的規(guī)格進(jìn)行智能分流。

(, 下載次數(shù): 183)
提供者基于一個 AutoConcurrencyLimiter 組件限流，在請求到達(dá)時會判斷已接受的請求是否超過最大處理量，如果超過了就會直接返回失敗，限流導(dǎo)致的失敗會影響負(fù)載均衡時的成功率，進(jìn)而影響該實(shí)例被請求的可能性。與常規(guī)限流組件不同的是，該組件會根據(jù)采樣情況自動調(diào)整服務(wù)的最大處理量，不需要手動配置，而且增加了 CPU 負(fù)載作為啟動開關(guān)，可以減少被錯誤限流的數(shù)量。
該組件主要關(guān)注 QPS、無負(fù)載時延（NoLoadLatency）和最大并發(fā)量（maxConcurrency），同時有一個用戶指定的超參數(shù) exploreRatio，表示探索最大并發(fā)量的程度。更新規(guī)則是

(, 下載次數(shù): 184)
最后可以提供給用戶一個可以通過 cgroup v1 進(jìn)行 CPU 限制，當(dāng)當(dāng)前提供者 CPU 負(fù)載過高的時候，會無條件拒絕一切新請求。CPU 限制是一種最壞情況下的兜底策略。
以下為 1 個客戶端請求一個服務(wù)端的測試結(jié)果，該測試隨著時間推移，QPS 會逐步增大，如藍(lán)線所示。可以看到當(dāng)CPU 負(fù)載（橙線）過高時，有請求被限流（黃線），隨后即使 QPS 再增大，CPU 負(fù)載、請求成功數(shù)均已相對穩(wěn)定。

(, 下載次數(shù): 191)
3.3 Dubbo Mesh

今年 Dubbo Go 社區(qū)發(fā)布了 Dubbo Mesh [1] 架構(gòu)的完整實(shí)現(xiàn)，能夠以 Proxyless Mesh 的形式加入 Istio 服務(wù)網(wǎng)格，開啟了 Go 語言體系下的微服務(wù)新形態(tài)。
Istio 在架構(gòu)層面分為控制平面（control plane）和數(shù)據(jù)平面（data plane），其中控制平面是一個名為 istiod 的進(jìn)程，網(wǎng)絡(luò)代理是 envoy 。Istiod 簡體 Kubernetes 資源（resources）獲取服務(wù)信息，比如 Service、Endpoint 等，將這些信息通過 xDS 協(xié)議發(fā)送給位于數(shù)據(jù)平面的 envoy。Envoy 作為一個獨(dú)立代理進(jìn)程以邊車（sidecar）形式運(yùn)行，該進(jìn)程與業(yè)務(wù)進(jìn)程共同加入同一個網(wǎng)絡(luò)，劫持業(yè)務(wù)流量并轉(zhuǎn)發(fā)到正確的位置。
服務(wù)網(wǎng)格能夠屏蔽復(fù)雜的服務(wù)治理細(xì)節(jié)，讓開發(fā)者能夠?qū)Ｗ⒂跇I(yè)務(wù)實(shí)現(xiàn)。Istio 通過邊車的形式實(shí)現(xiàn)了業(yè)務(wù)邏輯的無侵入性，降低了系統(tǒng)之間的耦合性，帶來開發(fā)便利的同時也引入了轉(zhuǎn)發(fā)時延、額外資源消耗的問題。但是 Istio 作為云原生時代的標(biāo)桿產(chǎn)品，其架構(gòu)模式和思路就有非常大的借鑒意義，針對上述提到的 Proxy Mesh 的弊端，我們提出了一套基于 Dubbo-go 的 Proxyless Mesh 微服務(wù)治理模式。
Proxyless Mesh 是無代理服務(wù)網(wǎng)格，由 Google 提出后，多個開源產(chǎn)品在這個方向進(jìn)行了探索和實(shí)踐。其核心思路是用 SDK 代替獨(dú)立代理進(jìn)程，SDK 作為數(shù)據(jù)平面接收來自控制平面的控制信息，負(fù)責(zé)服務(wù)之間的通信和治理工作。
Dubbo-go 為了融入 Istio 體系，將擴(kuò)展出來的注冊發(fā)現(xiàn)流程進(jìn)行了特殊改造。除了復(fù)用 Istio 提供的 EDS、CDS 主機(jī)發(fā)現(xiàn)的能力之外，增加了接口名到主機(jī)名的映射，作為源數(shù)據(jù)注冊在了控制平面上。客戶端在發(fā)起調(diào)用前持有接口名，通過查詢 istiod 上的元數(shù)據(jù)信息，拿到接口名到主機(jī)名到映射，轉(zhuǎn)換為主機(jī)名；再通過 EDS、CDS 和路由，完成主機(jī)名到下游端點(diǎn)實(shí)例的轉(zhuǎn)換。完成服務(wù)發(fā)現(xiàn)流程。
3.4 互聯(lián)互通的新典范：Polaris 和 Dubbo-go 全面對接

Dubbo-go 從發(fā)布伊始，一直非常重視與各個開源產(chǎn)品之間的互聯(lián)互通，今年我們完成了與 Polaris 全面對接，這部分工作由社區(qū)鄧正威同學(xué)（GitHub: @jasondeng1997）和春少同學(xué)（GitHub: @chuntaojun）貢獻(xiàn)。
Polaris 是一款開源的服務(wù)治理平臺，致力于解決分布式和微服務(wù)架構(gòu)中的服務(wù)管理、流量管理、配置管理、故障容錯和可觀測性問題，針對不同的技術(shù)棧和環(huán)境提供服務(wù)治理的標(biāo)準(zhǔn)方案和最佳實(shí)踐。在經(jīng)典 Dubbo-go 使用場景下，用戶需要自行部署注冊中心、可觀測服務(wù)、流量管理等組件，而 Polaris 內(nèi)置了服務(wù)管理、流量管理、故障容錯、配置管理和可觀測性五大功能，能夠幫助用戶快速降低微服務(wù)開發(fā)門檻
Polaris 有統(tǒng)一的控制平面，需要為 Dubbo-go 框架適配相應(yīng)的數(shù)據(jù)平面 SDK，用戶只需要在 Dubbo-go 中開啟 Polaris，框架將自動通過 extension 機(jī)制進(jìn)行注入，開發(fā)者無需其他額外的開發(fā)工作。從用戶數(shù)據(jù)流的維度，當(dāng)用戶在 dubbogo 中啟用 Polaris 的服務(wù)治理能力后，業(yè)務(wù)流量實(shí)際處理流程如下：

(, 下載次數(shù): 208)
當(dāng)前 Polaris 已實(shí)現(xiàn)了 Dubbo-go 原生的服務(wù)注冊擴(kuò)展點(diǎn)，因此原本服務(wù)注冊邏輯不需要進(jìn)行任何調(diào)整，只需要在 dubbogo.yaml 配置文件中新增 polaris 協(xié)議的注冊中心配置即可，如下所示
dubbo:
  registries:
    demo:
      protocol: polaris
      address: {polaris-ip}:8091其中 polaris-ip 表示北極星服務(wù)端 IP 地址，此時 Dubbo-go 框架就接入了 Polaris 服務(wù)治理框架。Polaris 還提供了流量管理、故障容錯等諸多內(nèi)容，礙于篇幅限制這里就不一一展開了，如果有興趣請參閱 《互聯(lián)互通的新典范：Polaris 和 Dubbo-go 全面對接》[2]。
3.5 TLS 安全通信支持

在今年我們?yōu)?Dubbo 協(xié)議、Triple 協(xié)議和 gRPC 協(xié)議實(shí)現(xiàn)了 TLS 安全通信功能，微服務(wù)之間能夠以可信的方式調(diào)用，該部分由社區(qū)張立斌同學(xué)（GitHub: @ZLBer）貢獻(xiàn)。
TLS 的前身是 SSL，被用于通信加密，能夠保證傳輸內(nèi)容不被其他主機(jī)查看和篡改，已經(jīng)被廣泛的應(yīng)用于 HTTPS 等技術(shù)中。在開啟 TLS 之前，需要生成所需要的證書和秘鑰，我們假設(shè)其保存在 x509 目錄中。啟用 TLS 不需要對業(yè)務(wù)邏輯進(jìn)行修改，只需要設(shè)置相應(yīng)的 Dubbo-go 配置文件 dubbogo.yaml 即可。
消費(fèi)者配置文件：
dubbo:
  consumer:
    references:
      UserProvider:
        url: tri://localhost:20000
        protocol: tri
        serialization: json
        interface: com.apache.dubbogo.samples.rpc.extension.UserProvider
  tls_config:
      ca-cert-file: x509/server_ca_cert.pem
      tls-cert-file: x509/client2_cert.pem
      tls-key-file: x509/client2_key.pem
      tls-server-name: dubbogo.test.example.com提供者配置文件：
dubbo:
  protocols:
    triple:
      name: tri
      port: 20000
  provider:
    services:
      UserProvider:
        serialization: json
        interface: com.apache.dubbogo.samples.rpc.extension.UserProvider
  tls_config:
    ca-cert-file: x509/client_ca_cert.pem
    tls-cert-file: x509/server2_cert.pem
    tls-key-file: x509/server2_key.pem
    tls-server-name: dubbogo.test.example.com在正確開啟 TLS 之后，提供者會輸出一條 "Server initialized the TLSConfig configuration" 日志，消費(fèi)者會輸出一條 "Client initialized the TLSConfig configuration" 日志。更詳細(xì)的使用實(shí)例請參考 tls 示例 [3]。
04 展望 2023

2022 年是極不容易的一年，感謝大家的信任，也非常感謝社區(qū)中每位同學(xué)的貢獻(xiàn)。展望 2023 我們將會持續(xù)打磨框架，在優(yōu)先保障穩(wěn)定性的前提下持續(xù)提升易用性，打造一流的 Go 語言微服務(wù)框架。
4.1 Dubbo 開源整體規(guī)劃


(, 下載次數(shù): 174)
4.2 面向 Go 開發(fā)者全面使用體驗(yàn)提升

Dubbo-go 基礎(chǔ)功能建設(shè)已經(jīng)較為完善，同時在最近幾年中我們持續(xù)在 dubbo-go-samples 目錄完善示例代碼 [4]，能夠幫助用戶更加快速的上手項(xiàng)目。與此同時，Dubbo-go 文檔內(nèi)容還較為匱乏，代碼示例只能讓框架跑起來，但是這里面的使用和實(shí)現(xiàn)細(xì)節(jié)還需要在文檔中進(jìn)一步被詳細(xì)闡述，讓用戶知其然，更知其所以然。除了文檔建設(shè)工作外，社區(qū)對開發(fā)者工具的建設(shè)工作高度重視，在 2023 年，我們計(jì)劃在 dubboctl 工具中集成更多命令，為用戶提供快速創(chuàng)建微服務(wù)、支持了 Hessian2 生成器、新建 Dubbo-go 項(xiàng)目等諸多特性。在 2023 年我們將會進(jìn)一步提升文檔和工具的建設(shè)工作，除了強(qiáng)大的功能之外，成為真正面向 Go 開發(fā)者的輕量、易用的框架。
參考鏈接：
1、Dubbo-go-Mesh 開啟新一代 Go 微服務(wù)形態(tài)
2、https://baijiahao.baidu.com/s?id=1751764790109427167&wfr=spider&for=pc
3、https://github.com/apache/dubbo-go-samples/tree/master/tls
4、https://github.com/apache/dubbo-go-samples
作者簡介：牛學(xué)蔚（GitHub: @justxuewei）：Apache Dubbo PMC，對云原生、中間件、容器等領(lǐng)域有濃厚興趣，活躍在 Dubbo 和 Kata containers 兩個開源項(xiàng)目中。
原文鏈接
本文為阿里云原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。

-----------------------------



歡迎光臨 愛鋒貝 (http://m.7gfy2te7.cn/) Powered by Discuz! X3.4