本文介紹了Go 微服務體系發展與選型，過去一年Dubbo-go 社區的飛速發展以及對未來的展望，
隨著微服務技術的快速發展，其在各個領域都形成了一系列事實標準，在 Kubernetes 和容器技術加持下，云原生微服務已經成為了主流解決方案，而 Go 語言作為云原生領域最受歡迎的開發語言，正被越來越多的企業作為微服務開發的首選語言，其中比較流行的包括 Go-micro、Go-zero、Dubbo-go 等，作為 Dubbo 微服務體系中多語言實作的一員，在 2022 年 Dubbo-go 以微服務領跑者的角色積極擁抱云原生標準，探索了 Proxyless Mesh 形態，配合適配 Pixiu 云原生網關，形成了完善的 Dubbo-go 微服務生態矩陣，
以 Dubbo-go 為中心的微服務體系在多個知名企業中成功落地和實踐，框架的穩定性在實際場景下經受住了考驗，截止今年已有 60+ 家企業在我們的用戶串列中登記，其中較為典型案例請參考文章《小米電商 Apache Dubbo-go 微服務實踐》，小米電商選用了 Dubbo-go + Nacos + sidecar + etcd + mirpc 為核心的微服務體系，除了看中了 Dubbo-go 的互聯互通和服務治理能力外，也認可 Dubbo-go 在微服務方向的沉淀和積累，
Apache Dubbo 是一款易用、高性能的 WEB 和 RPC 框架，同時為構建企業級微服務提供服務發現、流量治理、可觀測、認證鑒權等能力、工具與最佳實踐，Dubbo3 從設計上不系結編程語言，社區目前提供了 Java、Go、Rust、Node.js 等多語言實作，在未來，我們計劃為所有主流語言提供對等的微服務開發體驗，
Dubbo 框架作為國內最具影響力的開源微服務開發框架之一，擁有非常高的關注度和活躍度，在 GitHub 上擁有 3.8 萬+ stars，Dubbo 專案于 2017 年捐贈給 Apache 基金會，在經歷了短短 15 個月范訓后順利畢業，在 Apache 基金會管理的全部專案中關注度排名第三（前兩名分別是 echarts 和 superset），Dubbo-go 作為 Dubbo 多語言生態的重要一員，很好的兼容 Dubbo 生態的同時提供面向 Go 語言體系的微服務開發體驗，
Dubbo-go（專案地址 github.com/apache/dubbo-go）作為 Dubbo 多語言生態的重要組成部分，目前完全兌現了 Dubbo3 架構的核心能力，并且在云原生時代，憑借 Go 語言無需重量級虛擬機、靜態編譯以及垃圾回收的特性，獲得了廣泛關注，其應用規模也逐漸擴大，從特性上來說，Dubbo-go 目前支持 HTTP/2、TCP、gRPC 協議通信、服務發現、流量管控、配置管理、全鏈路追、可視化觀測等諸多新特性，Dubbo3 已是眾多用戶生產環境首選的微服務框架（用戶串列）；在生態建設方面，Dubbo-go 適配了包括 Zookeeper、Nacos、Sentinel、Zipkin、Kubernetes、Prometheus、云原生 API 網關專案 Dubbo-pixiu、異步網路庫 Dubbo-getty、Hessian2 等生態專案，
2022 年 Dubbo-go 社區以生態互聯、開發者體驗、穩定性為切入點，不斷優化系統架構，社區榮獲多個開源獎項：
通信協議：遵循 Dubbo 核心架構設計，Dubbo-go 在實作上不系結通信協議，目前支持 HTTP/2、TCP (Dubbo2)、JSONRPC、gRPC、HTTP 等多種通信協議，開發者可以根據使用場景靈活的選擇通信協議，
服務注冊：支持 Client-based 服務發現機制，支持注冊中心適配如 Nacos、Consul、Zookeeper 等，Dubbo3 的服務發現機制誕生于阿里巴巴超大規模微服務電商集群實踐場景，其在性能、可伸縮性、易用性等方面的表現大幅領先于業界大多數主流開源產品，
配置中心：Dubbo 配置中心可實作應用配置的遠程托管，支持配置變更的實時感知，目前支持 Nacos、Apollo（攜程開源）、ZooKeeper 等作為配置中心，
負載均衡：Dubbo 提供了多種負載均衡策略，如隨機負載均衡策略、一致性哈希負載、基于權重的輪詢、最小活躍度優先、自適應負載均衡 P2C 等，
流量控制：Dubbo 的流量管控規則可以基于應用、服務、方法、引數等粒度精準的控制流量走向，基于此可靈活的實作超時時間調整、開啟訪問日志、金絲雀發布、引數路由、同區域優先、按比例流量分發等，除此之外，通過接入 Hystrix、Sentinel 等，Dubbo-go 還支持自適應限流、限流熔斷等，
分布式事務：支持 Seata-golang 分布式事務框架，實作了 AT 模式和 TCC 模式分布式事務的呼叫，AT 模式相較 TCC 模式對代碼的入侵性更小、需要開發的介面更少，但 AT 模式對事務操作的資料持有全域鎖，TCC 模型性能更好，
鏈路追蹤：支持基于 Jaeger、ZipKin 的鏈路追蹤能力，
指標可視化：支持使用 Prometheus 收集框架指標和用戶指標，
可擴展性：Dubbo-go 提供了靈活的 extension 擴展機制，用戶可隨時根據自己的需求靈活擴展服務發現、負載均衡、配置中心、流量管控規則、全鏈路追蹤等中間件，
在微服務場景下，業務是以容器的形式對外提供服務，k8s 能夠方便的對 Pod 進行滾動升級，在舊版本被替換的時候應該達到無損下線的效果，即容器不能被銷毀直到沒有正在處理的請求，如果其不能被正確實作，對于承載高流量的在線服務來說，在更新期間可能會導致大量的請求報錯，甚至可能觸發報警，其影響是巨大的，優雅上下線功能是 Dubbo-go 3.0 正式版本發布后的第一個重大增強，王曉偉同學（GitHub: @XiaoWeiKIN）貢獻了全流程的優雅上下線能力，
Dubbo 經典的呼叫流程如上圖所示，這里面包含了服務提供者（Provider）、服務消費者（Consumer）以及注冊中心（Registry）三個關鍵組件，一個服務能夠被呼叫，首先需要提供者準備服務并對外暴露埠（步驟 0），然后提供者需要將呼叫資訊注冊到注冊中心中（步驟 1），消費者則會通過異步訂閱的方式獲取最新的提供者資料（步驟 2），注冊中心在有新資料后會主動推送給消費者（步驟 3），此時消費者已經有本次呼叫的全部資訊了，最后消費者發送呼叫請求（步驟 4），這樣就完成了整個呼叫鏈路，
在單體應用中，上述邏輯非常清晰和簡單，但是在大規模微服務集群中，這個邏輯的每一個細節都需要被仔細推敲后，才能保證上下線的程序中呼叫不出錯，
優雅上線的目標是解決服務上線呼叫報錯的問題，主要針對微服務場景下的呼叫依賴問題，在 Dubbo 生態中，Service 表示一個服務，能夠被暴露并被其他服務呼叫，Reference 表示參考，可以簡單的理解為下游服務，一個典型呼叫結構如上圖所示，該服務對外暴露一個介面，同時參考了下游的 N 個服務，該服務在上線的時候應該嚴格遵循以下流程，首先保證下游服務的參考被成功初始化，之后再初始化 Service 對外暴露服務，最后再向注冊中心注冊服務，優雅上線相對來說邏輯比較簡單，只需要嚴格遵循初始化程序的依賴關系就能保證上執行緒序中服務能夠被正常呼叫，
優雅下線是優雅上下線的難點，涉及到了信號監聽、反注冊、等待已有請求完成呼叫等邏輯，在需要銷毀容器的時候，kubelet 會向容器發送 SIGTERM 信號，Dubbo-go 會進入優雅下線流程，此時容器并不會立刻被銷毀，即將下線的提供者首先會執行反注冊，即向注冊中心中洗掉自己的資訊，消費者可以通過訂閱獲得這個資訊，這個程序需要一定的時間，換句話說，在消費者獲得這個洗掉資訊之前，流量還是有可能會流向該提供者，此時提供者應該拒絕這部分請求，當然除了下線期間的新請求外，還有殘留的來自上游的請求以及自己呼叫下游的請求，我們分別為這兩種情況設定一個計數器，當兩個計數器都被清零時，可以認為該提供者是“干凈”的，Dubbo-go 的策略是拒絕新請求，等待已放行的舊請求，最后，銷毀協議并關閉監聽，該容器就能夠被安全的摘除，
在啟動優雅上下線后，集群內無錯誤請求，成功率保持在100%，
在去年發布 Dubbo-go 3.0 版本的時候，柔性服務首次作為一個重要特性被提出，時隔一年，我們帶來了全新升級的新一代柔性服務，在新版本中我們將爬山演算法替換為峰值干預演算法，在經過多次測驗后新演算法行為可控性更高、性能更優異，這部分作業由來自北京郵電大學的張業鵬同學（GitHub: @CoolIceV）貢獻，
柔性服務是一種更智能的負載均衡演算法，傳統負載均衡演算法大多是基于消費者視角，它們共同的局限性是無法根據服務提供者的當前狀態動態調整分流策略，如 RR、hash 等演算法，這些演算法總是以盡可能公平的概率分配流量，但在實踐中公平不等于負載均衡，
爬山演算法是一種容量預估的演算法，服務提供者需要將一些關鍵資訊回傳給消費者，比如時延、請求排隊數量、預估容量等，消費者使用 P2C 演算法選擇一個負載最低的作為本次請求的提供者，這些資料實效性要求非常高，如果這些資料是被動傳遞的，那么很難保證實效性，如果這些資料是被主動探測的，那么在一個大型集群下感知成本非常高，基于上述問題，我們選擇了更可控的峰值干預演算法，
消費者部分中，我們使用了改良版的 P2C 演算法，采集的指標包括請求數（requests）、成功數（accepts）、請求時延（rtt），與原實作方案不同的是，該版本采用了更合理的滑動視窗（SlidingWindowCounter）和指數移動平均（EMA）兩種帶有時序性的模塊進行采集，
SlidingWindowCounter 會保存時長為統計周期 T 的資料，整個周期內的資料被分割為若干個 Bucket，每個Bucket 保存計數時長內的資料，當前所處的 Bucket 會隨著時間前進而向后移動，
EMA 利用指數移動平均演算法進行平滑、減小抖動，適用于統計時延型的指標，計算公式：
以下為一個客戶端請求 3 個服務端的測驗結果，3 個服務端配置不同，分別為 1 核 1GB、2 核 2GB、3 核 3GB，蘭青色虛線代表開始使用上述負載均衡演算法，可以看到開啟前每個服務端接收到的請求數幾乎相同，開啟之后流量會根據提供者的規格進行智能分流，
提供者基于一個 AutoConcurrencyLimiter 組件限流，在請求到達時會判斷已接受的請求是否超過最大處理量，如果超過了就會直接回傳失敗，限流導致的失敗會影響負載均衡時的成功率，進而影響該實體被請求的可能性，與常規限流組件不同的是，該組件會根據采樣情況自動調整服務的最大處理量，不需要手動配置，而且增加了 CPU 負載作為啟動開關，可以減少被錯誤限流的數量，
該組件主要關注 QPS、無負載時延（NoLoadLatency）和最大并發量（maxConcurrency），同時有一個用戶指定的超引數 exploreRatio，表示探索最大并發量的程度，更新規則是
-
使用總請求數（包含未被采樣的資料）計算 QPS，新 QPS 更大時直接替換，更小則使用指數移動平均進行平滑處理，
-
使用采樣資料計算平均處理時延來估算 NoLoadLatency，平均時延變小才會更新，并使用指數移動平均進行平滑處理，
-
增加探索因子啟發式計算 maxConcurrency, 在采樣時延或 QPS 在探索允許的范圍之內時會逐步增大 exploreRatio，否則用指數移動平均的方式進行平滑處理
最后可以提供給用戶一個可以通過 cgroup v1 進行 CPU 限制，當當前提供者 CPU 負載過高的時候，會無條件拒絕一切新請求，CPU 限制是一種最壞情況下的兜底策略，
以下為 1 個客戶端請求一個服務端的測驗結果，該測驗隨著時間推移，QPS 會逐步增大，如藍線所示，可以看到當CPU 負載（橙線）過高時，有請求被限流（黃線），隨后即使 QPS 再增大，CPU 負載、請求成功數均已相對穩定，
今年 Dubbo Go 社區發布了 Dubbo Mesh [1] 架構的完整實作，能夠以 Proxyless Mesh 的形式加入 Istio 服務網格，開啟了 Go 語言體系下的微服務新形態，
Istio 在架構層面分為控制平面（control plane）和資料平面（data plane），其中控制平面是一個名為 istiod 的行程，網路代理是 envoy ，Istiod 簡體 Kubernetes 資源（resources）獲取服務資訊，比如 Service、Endpoint 等，將這些資訊通過 xDS 協議發送給位于資料平面的 envoy，Envoy 作為一個獨立代理行程以邊車（sidecar）形式運行，該行程與業務行程共同加入同一個網路，劫持業務流量并轉發到正確的位置，
服務網格能夠屏蔽復雜的服務治理細節，讓開發者能夠專注于業務實作，Istio 通過邊車的形式實作了業務邏輯的無侵入性，降低了系統之間的耦合性，帶來開發便利的同時也引入了轉發時延、額外資源消耗的問題，但是 Istio 作為云原生時代的標桿產品，其架構模式和思路就有非常大的借鑒意義，針對上述提到的 Proxy Mesh 的弊端，我們提出了一套基于 Dubbo-go 的 Proxyless Mesh 微服務治理模式，
Proxyless Mesh 是無代理服務網格，由 Google 提出后，多個開源產品在這個方向進行了探索和實踐，其核心思路是用 SDK 代替獨立代理行程，SDK 作為資料平面接收來自控制平面的控制資訊，負責服務之間的通信和治理作業，
Dubbo-go 為了融入 Istio 體系，將擴展出來的注冊發現流程進行了特殊改造，除了復用 Istio 提供的 EDS、CDS 主機發現的能力之外，增加了介面名到主機名的映射，作為源資料注冊在了控制平面上，客戶端在發起呼叫前持有介面名，通過查詢 istiod 上的元資料資訊，拿到介面名到主機名到映射，轉換為主機名；再通過 EDS、CDS 和路由，完成主機名到下游端點實體的轉換，完成服務發現流程，
3.4 互聯互通的新典范：Polaris 和 Dubbo-go 全面對接
Dubbo-go 從發布伊始，一直非常重視與各個開源產品之間的互聯互通，今年我們完成了與 Polaris 全面對接，這部分作業由社區鄧正威同學（GitHub: @jasondeng1997）和春少同學（GitHub: @chuntaojun）貢獻，
Polaris 是一款開源的服務治理平臺，致力于解決分布式和微服務架構中的服務管理、流量管理、配置管理、故障容錯和可觀測性問題，針對不同的技術堆疊和環境提供服務治理的標準方案和最佳實踐，在經典 Dubbo-go 使用場景下，用戶需要自行部署注冊中心、可觀測服務、流量管理等組件，而 Polaris 內置了服務管理、流量管理、故障容錯、配置管理和可觀測性五大功能，能夠幫助用戶快速降低微服務開發門檻，
Polaris 有統一的控制平面，需要為 Dubbo-go 框架適配相應的資料平面 SDK，用戶只需要在 Dubbo-go 中開啟 Polaris，框架將自動通過 extension 機制進行注入，開發者無需其他額外的開發作業，從用戶資料流的維度，當用戶在 dubbogo 中啟用 Polaris 的服務治理能力后，業務流量實際處理流程如下：
當前 Polaris 已實作了 Dubbo-go 原生的服務注冊擴展點，因此原本服務注冊邏輯不需要進行任何調整，只需要在 dubbogo.yaml 組態檔中新增 polaris 協議的注冊中心配置即可，如下所示，
dubbo:
registries:
demo:
protocol: polaris
address: {polaris-ip}:8091
其中 polaris-ip 表示北極星服務端 IP 地址，此時 Dubbo-go 框架就接入了 Polaris 服務治理框架，Polaris 還提供了流量管理、故障容錯等諸多內容，礙于篇幅限制這里就不一一展開了，如果有興趣請參閱 《互聯互通的新典范：Polaris 和 Dubbo-go 全面對接》[2]，
在今年我們為 Dubbo 協議、Triple 協議和 gRPC 協議實作了 TLS 安全通信功能，微服務之間能夠以可信的方式呼叫，該部分由社區張立斌同學（GitHub: @ZLBer）貢獻，
TLS 的前身是 SSL，被用于通信加密，能夠保證傳輸內容不被其他主機查看和篡改，已經被廣泛的應用于 HTTPS 等技術中，在開啟 TLS 之前，需要生成所需要的證書和秘鑰，我們假設其保存在 x509 目錄中，啟用 TLS 不需要對業務邏輯進行修改，只需要設定相應的 Dubbo-go 組態檔 dubbogo.yaml 即可，
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" 日志，消費者會輸出一條 "Client initialized the TLSConfig configuration" 日志，更詳細的使用實體請參考 tls 示例 [3]，
2022 年是極不容易的一年，感謝大家的信任，也非常感謝社區中每位同學的貢獻，展望 2023 我們將會持續打磨框架，在優先保障穩定性的前提下持續提升易用性，打造一流的 Go 語言微服務框架，
Dubbo-go 基礎功能建設已經較為完善，同時在最近幾年中我們持續在 dubbo-go-samples 目錄完善示例代碼 [4]，能夠幫助用戶更加快速的上手專案，與此同時，Dubbo-go 檔案內容還較為匱乏，代碼示例只能讓框架跑起來，但是這里面的使用和實作細節還需要在檔案中進一步被詳細闡述，讓用戶知其然，更知其所以然，除了檔案建設作業外，社區對開發者工具的建設作業高度重視，在 2023 年，我們計劃在 dubboctl 工具中集成更多命令，為用戶提供快速創建微服務、支持了 Hessian2 生成器、新建 Dubbo-go 專案等諸多特性，在 2023 年我們將會進一步提升檔案和工具的建設作業，除了強大的功能之外，成為真正面向 Go 開發者的輕量、易用的框架，
參考鏈接：
1、Dubbo-go-Mesh 開啟新一代 Go 微服務形態
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
本文來自博客園，作者：古道輕風，轉載請注明原文鏈接：https://www.cnblogs.com/88223100/p/Selection-of-Microservice-Framework-under-Go-Language-System-Dubbo-go.html
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/549598.html
標籤：Go
上一篇：【manim影片教程】-- 坐標系
下一篇：Go 語言體系下的微服務框架選型: Dubbo-go
