柚子快報(bào)激活碼778899分享：Dubbo運(yùn)行原理

http://yzkb.51969.com/

目錄

Dubbo通訊協(xié)議

Dubbo負(fù)載均衡策略

RPC和HTTP有什么區(qū)別？

讓你設(shè)計(jì)一個(gè)RPC框架，如何考慮數(shù)據(jù)序列化問題？

Dubbo 是一款高性能、輕量級(jí)的開源?RPC（遠(yuǎn)程過程調(diào)用）框架，主要用于構(gòu)建分布式服務(wù)和微服務(wù)架構(gòu)。

要說 Dubbo 運(yùn)行流程就不得不先來了解一下 Dubbo 的核心組件了，因?yàn)?Dubbo 的交互流程是和核心組件息息相關(guān)的。

Dubbo 核心組件有以下幾個(gè)：

服務(wù)提供者（Provider）：暴露服務(wù)的應(yīng)用，通過 Dubbo 框架將自身的服務(wù)接口及實(shí)現(xiàn)注冊(cè)到注冊(cè)中心。 服務(wù)消費(fèi)者（Consumer）：調(diào)用遠(yuǎn)程服務(wù)的應(yīng)用，從注冊(cè)中心訂閱所需的服務(wù)，然后通過遠(yuǎn)程調(diào)用消費(fèi)服務(wù)。 注冊(cè)中心（Registry）：集中管理服務(wù)的地址信息，服務(wù)提供者和服務(wù)消費(fèi)者均在此注冊(cè)或訂閱服務(wù)信息。常見的注冊(cè)中心有 ZooKeeper、Nacos 等。

Dubbo 運(yùn)行流程如下圖所示：

它的執(zhí)行流程如下：

服務(wù)提供者會(huì)將實(shí)例（URL 地址）注冊(cè)到注冊(cè)中心，注冊(cè)中心負(fù)責(zé)對(duì)數(shù)據(jù)進(jìn)行聚合（健康檢測）。 消費(fèi)者從注冊(cè)中心讀取地址列表并訂閱變更，每當(dāng)?shù)刂妨斜戆l(fā)生變化，注冊(cè)中心將最新的列表通知到所有訂閱的消費(fèi)者實(shí)例。 消費(fèi)者得到服務(wù)實(shí)例之后，通過 Dubbo 內(nèi)置的負(fù)載均衡策略，選擇其中的一個(gè)節(jié)點(diǎn)，之后使用 RPC 的方式與服務(wù)提供者建立連接，并進(jìn)行通訊和服務(wù)調(diào)用。

更詳細(xì)的調(diào)用流程如下：

Dubbo通訊協(xié)議

Dubbo 框架提供了自定義的高性能 RPC 通信協(xié)議：基于 HTTP/2 的 Triple 協(xié)議和基于 TCP 的 Dubbo2 協(xié)議。除此之外，Dubbo 框架支持任意第三方通信協(xié)議，如官方支持的 gRPC、Thrift、REST、JsonRPC、Hessian2 等，更多協(xié)議可以通過自定義擴(kuò)展實(shí)現(xiàn)。這對(duì)于微服務(wù)實(shí)踐中經(jīng)常要處理的多協(xié)議通信場景非常有用。Dubbo 框架不綁定任何通信協(xié)議，在實(shí)現(xiàn)上 Dubbo 對(duì)多協(xié)議的支持也非常靈活，它可以讓你在一個(gè)應(yīng)用內(nèi)發(fā)布多個(gè)使用不同協(xié)議的服務(wù)，并且支持用同一個(gè) port 端口對(duì)外發(fā)布所有協(xié)議。

通過 Dubbo 框架的多協(xié)議支持，你可以做到：

將任意通信協(xié)議無縫地接入 Dubbo 服務(wù)治理體系。Dubbo 體系下的所有通信協(xié)議，都可以享受到 Dubbo 的編程模型、服務(wù)發(fā)現(xiàn)、流量管控等優(yōu)勢。比如 gRPC over Dubbo 的模式，服務(wù)治理、編程 API 都能夠零成本接入 Dubbo 體系。 兼容不同技術(shù)棧，業(yè)務(wù)系統(tǒng)混合使用不同的服務(wù)框架、RPC 框架。比如有些服務(wù)使用 gRPC 或者 Spring Cloud 開發(fā)，有些服務(wù)使用 Dubbo 框架開發(fā)，通過 Dubbo 的多協(xié)議支持可以很好的實(shí)現(xiàn)互通。 讓協(xié)議遷移變的更簡單。通過多協(xié)議、注冊(cè)中心的協(xié)調(diào)，可以快速滿足公司內(nèi)協(xié)議遷移的需求。比如如從自研協(xié)議升級(jí)到 Dubbo 協(xié)議，Dubbo 協(xié)議自身升級(jí)，從 Dubbo 協(xié)議遷移到 gRPC，從 HTTP 遷移到 Dubbo 協(xié)議等。

Dubbo負(fù)載均衡策略

目前 Dubbo（3.X）內(nèi)置了如下負(fù)載均衡算法如下：

Weighted Random LoadBalance（加權(quán)隨機(jī)）：默認(rèn)負(fù)載均衡算法，默認(rèn)權(quán)重相同。按權(quán)重設(shè)置隨機(jī)概率。缺點(diǎn)：存在慢的提供者累積請(qǐng)求的問題，比如：第二臺(tái)機(jī)器很慢，但沒掛，當(dāng)請(qǐng)求調(diào)到第二臺(tái)時(shí)就卡在那，久而久之，所有請(qǐng)求都卡在調(diào)到第二臺(tái)上。 RoundRobin LoadBalance（加權(quán)輪詢）：借鑒于 Nginx 的平滑加權(quán)輪詢算法，默認(rèn)權(quán)重相同，按公約后的權(quán)重設(shè)置輪詢比率，循環(huán)調(diào)用節(jié)點(diǎn)。缺點(diǎn)：同樣存在慢的提供者累積請(qǐng)求的問題。 LeastActive LoadBalance（最少活躍優(yōu)先+加權(quán)隨機(jī)）：背后是能者多勞的思想，活躍數(shù)越低，越優(yōu)先調(diào)用，相同活躍數(shù)的進(jìn)行加權(quán)隨機(jī)?；钴S數(shù)指調(diào)用前后計(jì)數(shù)差（針對(duì)特定提供者：請(qǐng)求發(fā)送數(shù) - 響應(yīng)返回?cái)?shù)），表示特定提供者的任務(wù)堆積量，活躍數(shù)越低，代表該提供者處理能力越強(qiáng)。使慢的提供者收到更少請(qǐng)求，因?yàn)樵铰奶峁┱叩恼{(diào)用前后計(jì)數(shù)差會(huì)越大；相對(duì)的，處理能力越強(qiáng)的節(jié)點(diǎn)，處理更多的請(qǐng)求。 Shortest-Response LoadBalance（最短響應(yīng)優(yōu)先+加權(quán)隨機(jī)）：更加關(guān)注響應(yīng)速度，在最近一個(gè)滑動(dòng)窗口中，響應(yīng)時(shí)間越短，越優(yōu)先調(diào)用。相同響應(yīng)時(shí)間的進(jìn)行加權(quán)隨機(jī)。使得響應(yīng)時(shí)間越快的提供者，處理更多的請(qǐng)求。缺點(diǎn)：可能會(huì)造成流量過于集中于高性能節(jié)點(diǎn)的問題。 ConsistentHash LoadBalance（一致性哈希）：確定的入?yún)?，確定的提供者，適用于有狀態(tài)請(qǐng)求。當(dāng)某一臺(tái)提供者掛時(shí)，原本發(fā)往該提供者的請(qǐng)求，基于虛擬節(jié)點(diǎn)，平攤到其它提供者，不會(huì)引起劇烈變動(dòng)。 P2C LoadBalance（隨機(jī)選擇兩個(gè)節(jié)點(diǎn)+連接數(shù)較?。弘S機(jī)選擇兩個(gè)節(jié)點(diǎn)后，繼續(xù)選擇“連接數(shù)”較小的那個(gè)節(jié)點(diǎn)。對(duì)于每次調(diào)用，從可用的 provider 列表中做兩次隨機(jī)選擇，選出兩個(gè)節(jié)點(diǎn) providerA 和 providerB，比較 providerA 和 providerB 兩個(gè)節(jié)點(diǎn)，選擇其“當(dāng)前正在處理的連接數(shù)”較小的那個(gè)節(jié)點(diǎn)。 Adaptive LoadBalance（自適應(yīng)負(fù)載均衡）：在?P2C?算法基礎(chǔ)上，選擇二者中 load 最小的那個(gè)節(jié)點(diǎn)，是一種能根據(jù)后端實(shí)例負(fù)載自動(dòng)調(diào)整流量分布的算法實(shí)現(xiàn)，它總是嘗試將請(qǐng)求轉(zhuǎn)發(fā)到負(fù)載最小的節(jié)點(diǎn)。

RPC和HTTP有什么區(qū)別？

RPC（Remote Procedure Call，遠(yuǎn)程過程調(diào)用）和 HTTP（Hypertext Transfer Protocol，超文本傳輸協(xié)議）都是用于服務(wù)間通訊的，它們主要區(qū)別如下：

概念和使用場景不同：

RPC：RPC 是一種通信模式，允許一個(gè)程序在另一個(gè)地址空間上執(zhí)行遠(yuǎn)程計(jì)算過程，使得客戶端調(diào)用遠(yuǎn)程服務(wù)就像調(diào)用本地方法一樣。 HTTP：HTTP 是一個(gè)應(yīng)用層協(xié)議，用于在客戶端和服務(wù)器之間傳輸文本、圖像、視頻等超媒體資源，通常用于 Web 應(yīng)用之間的通信。 傳輸數(shù)據(jù)不同：

RPC：RPC 通?；诙M(jìn)制數(shù)據(jù)傳輸，可以使用更高效的序列化方式（如 Protobuf、Thrift）進(jìn)行數(shù)據(jù)交換。 HTTP：HTTP 使用文本協(xié)議，請(qǐng)求和響應(yīng)數(shù)據(jù)通常是基于文本格式（如 JSON、XML）進(jìn)行傳輸。 傳輸效率與性能不同：

RPC：因?yàn)?RPC 通常使用更高效的二進(jìn)制序列化（如 Protobuf、Thrift），減少了數(shù)據(jù)傳輸?shù)捏w積，且由于其針對(duì)性的設(shè)計(jì)，往往在性能上更為優(yōu)越，特別是在大量小數(shù)據(jù)包的傳輸場景。 HTTP：傳統(tǒng)上使用文本格式如 JSON 進(jìn)行數(shù)據(jù)交換，這可能導(dǎo)致更大的數(shù)據(jù)包和更多的序列化/反序列化開銷，但在 HTTP/2 中引入了頭部壓縮和多路復(fù)用，提升了效率。

讓你設(shè)計(jì)一個(gè)RPC框架，如何考慮數(shù)據(jù)序列化問題？

數(shù)據(jù)序列化需要考慮的以下問題：

性能問題：選擇高性能的序列化庫至關(guān)重要。二進(jìn)制序列化（如 Protocol Buffers, Apache Thrift, FlatBuffers）通常比文本格式（如 JSON、XML）更高效，因?yàn)樗鼈冋加玫目臻g小，序列化和反序列化的速度更快。對(duì)于高性能要求的場景，應(yīng)優(yōu)先考慮這些二進(jìn)制格式。 安全性：在序列化過程中，應(yīng)考慮數(shù)據(jù)的安全性，避免敏感信息的泄露?？梢圆捎眉用苄蛄谢瘍?nèi)容、過濾敏感字段或使用安全的傳輸層協(xié)議（如 TLS/SSL）來增加安全性。 兼容性：良好的版本兼容性是長期維護(hù) RPC 框架的關(guān)鍵。設(shè)計(jì)時(shí)要考慮向前和向后兼容，即新老版本的序列化庫應(yīng)能互相理解和處理對(duì)方生成的數(shù)據(jù)格式。可以采用預(yù)留字段、版本標(biāo)識(shí)符等機(jī)制來支持這一點(diǎn)。 跨語言支持：RPC 框架往往需要支持多種編程語言，因此選擇一種跨語言的序列化方案是必要的。Protocol Buffers、Apache Thrift、Avro 等都是很好的選擇，它們提供了多種語言的編解碼庫。 可擴(kuò)展性：設(shè)計(jì)時(shí)應(yīng)考慮到未來可能增加的數(shù)據(jù)結(jié)構(gòu)和字段，序列化方案應(yīng)易于擴(kuò)展，支持動(dòng)態(tài)字段、自定義類型等特性。 可配置性：允許用戶根據(jù)實(shí)際需求選擇或切換序列化策略。例如，對(duì)于對(duì)性能要求極高的場景，用戶可以選擇最高效的序列化方式；而對(duì)于調(diào)試或日志記錄，可能會(huì)偏好人類可讀性更好的格式。 異常處理：在序列化或反序列化過程中可能會(huì)遇到錯(cuò)誤（如數(shù)據(jù)損壞、不兼容的版本等）?？蚣軕?yīng)能優(yōu)雅地處理這些異常，并提供清晰的錯(cuò)誤信息，幫助開發(fā)者診斷問題。

柚子快報(bào)激活碼778899分享：Dubbo運(yùn)行原理

http://yzkb.51969.com/

相關(guān)文章