目錄
Dubbo服務治理易用性的原理：
URL地址數(shù)據(jù)劃分：
Dubbo接口級服務發(fā)現(xiàn)---易用性的代價
Proposal，適應云原生、更大規(guī)模集群的服務發(fā)現(xiàn)類型。
Dubbo3應用級服務發(fā)現(xiàn)---基本原理
Dubbo負載均衡機制
常規(guī)負載均衡算法
負載均衡策略：
Weighted Random
RoundRobin
LeastActive
ShortestResponse
配置方式：
自適應負載均衡與服務柔性
整體介紹：
P2C算法原理介紹：
Dubbo服務治理易用性的原理：
- 地址發(fā)現(xiàn)聚合Key==RPC粒度服務
- 注冊中心同步的地址包含地址、元數(shù)據(jù)與配置
- 得益于1與2，Dubbo可以支持應用、RPC、方法粒度的服務治理
URL地址數(shù)據(jù)劃分：
- 首先是實例可訪問地址，主要信息包含ip port，是消費端將基于這條數(shù)據(jù)生成tcp網(wǎng)絡連接，作為后續(xù)RPC數(shù)據(jù)的傳輸載體
- 其次是RPC元數(shù)據(jù)，元數(shù)據(jù)用于定義和描述一次RPC請求，一方面表明這條地址數(shù)據(jù)是與某條具體的RPC服務有關的，它的版本號，分組以及方法相關信息，另一方面表明。
- 下一部分是RPC配置數(shù)據(jù)，部分配置用于控制RPC調(diào)用的行為，還有一部分配置用于同步Provider進程實例的狀態(tài)，典型的如超時時間，數(shù)據(jù)編碼的序列化方式等。
- 最后一部分是自定義的元數(shù)據(jù)，這部分內(nèi)容區(qū)別于以上框架預定義的各項配置，給了用戶更大的靈活性，用戶可任意擴展并添加自定義元數(shù)據(jù)，以進一步豐富實例狀態(tài)。
以上就是Dubbo2在易用性、服務治理功能性、可擴展性上強于很多服務框架的真正原因。
Dubbo接口級服務發(fā)現(xiàn)---易用性的代價
一個事物總是有其兩面性，Dubbo2地址模型帶來易用性和強大功能的同時，也給整個架構(gòu)的水平可擴展性帶來了一些限制。這個問題在普通規(guī)模的微服務集群下是完全感知不到的，而隨著集群規(guī)模的增長，當整個集群內(nèi)應用、機器達到一定數(shù)量時，整個集群內(nèi)的各個組件才開始遇到規(guī)模瓶頸。在總結(jié) 包括阿里巴巴、工商銀行等多個大廠用戶在生產(chǎn)環(huán)境特點后，我們總結(jié)出以下兩點突出問題。
- 首先，注冊中心集群容量達到上限閾值。由于所有的URL地址數(shù)據(jù)都被發(fā)送到注冊中心，注冊中心的存儲容量達到上限，推送效率也隨著下降。
- 而在消費端這一側(cè)，Dubbo2框架常駐內(nèi)存已超40%，每次地址推送帶來的CPU等資源消耗率也非常高 ，影響正常的業(yè)務調(diào)用。
- 青色部分，假設這里有一個普通的Dubbo Provider應用，該應用內(nèi)部定義有10個RPC Service，應用被部署在100個機器實例上，這個應用在集群中產(chǎn)生的數(shù)據(jù)量將會是“Service數(shù)*機器實例數(shù)”，也就是10*100=1000條，數(shù)據(jù)被從兩個維度放大了。
-
- 從地址角度：100條唯一的實例地址，被放大了10倍
- 從服務角度：10條唯一的服務元數(shù)據(jù)，被放大100倍
Proposal，適應云原生、更大規(guī)模集群的服務發(fā)現(xiàn)類型。
問題點：
- 如何重新組織數(shù)據(jù)（地址、RPC元數(shù)據(jù)、RPC配置），避免冗余數(shù)據(jù)的出現(xiàn)
- 如何在保留易用性的同時，在地址發(fā)現(xiàn)層面（注冊中心數(shù)據(jù)格式）與其他微服務體系打通
Dubbo3應用級服務發(fā)現(xiàn)---基本原理
Dubbo3的應用級服務發(fā)現(xiàn)方案設計本質(zhì)上就是圍繞以上兩個問題展開。其基本思路是：地址發(fā)現(xiàn)鏈路上的聚合元素也就是我們之前提到的key由服務調(diào)整為應用，這也是其名稱叫做應用級服務發(fā)現(xiàn)的由來；另外，通過注冊中心同步的數(shù)據(jù)內(nèi)容上做了大幅精簡，只保留最核心的IP、port地址數(shù)據(jù)。
升級后的變化：
首先：在Provider實例這一側(cè)，相比于之前每個RPC Service注冊一條地址數(shù)據(jù)，一個Provider實例只會注冊一條地址到注冊中心。
其次，在注冊中心這一側(cè)，地址以應用名為粒度做聚合，應用名節(jié)點下是精簡過后的Provider實例地址。
Dubbo3引入了一個內(nèi)置MetadataService元數(shù)據(jù)服務，由中心化推送為Customer到Provider的點對點拉取，在這個模式下，元數(shù)據(jù)傳輸?shù)臄?shù)據(jù)量將不在一個問題，因此可以在元數(shù)據(jù)中擴展出更多的參數(shù)，暴露出更多的治理數(shù)據(jù)。
消費端Cusumer的地址訂閱行為，消費端從分兩步讀取地址數(shù)據(jù)，首先是從注冊中心收到精簡后的地址，隨后通過調(diào)用MetadataService元數(shù)據(jù)服務，讀取對端的元數(shù)據(jù)信息、在收到這兩部分數(shù)據(jù)之后，消費端會完成地址數(shù)據(jù)的聚合，最終在運行態(tài)還原出類似Dubbo2的URL地址格式，因此從最終結(jié)果而言，應用級地址模型同時兼顧了地址傳輸層面的性能與運行層面的功能性。
Dubbo負載均衡機制
常規(guī)負載均衡算法
在集群負載均衡時，Dubbo提供了多種均衡策略，缺省為weighted random基于權(quán)重的隨機負載均衡策略。
具體實現(xiàn)上，Dubbo提供的是客戶端負載均衡，即由Consumer通過負載均衡算法得出需要將請求提交到那個Provider實例。
負載均衡策略：
目前Dubbo內(nèi)置如下負載均衡算法，可通過調(diào)整配置項進行啟用
Weighted Random
加權(quán)機制，按權(quán)重設置隨機概率。
在一個截面上碰撞概率高，但是調(diào)用量越大分布越均勻，而且按概率使用權(quán)重后也比較均勻，有利于動態(tài)調(diào)整提供者權(quán)重。
缺點：存在慢的提供者累計請求的問題，比如：第二臺機器很慢，但是沒有宕機，當前請求調(diào)用到第二臺時就卡了。時間長了之后，所有的請求都卡在第二臺機器上面了。
RoundRobin
加權(quán)輪詢，按公約后的權(quán)重設置輪詢比例，循環(huán)調(diào)用節(jié)點。
缺點：同樣存在慢的提供者累計請求的問題
加權(quán)輪詢過程中，如果某節(jié)點權(quán)重過大，會存在某段時間內(nèi)調(diào)用過于集中的問題。
LeastActive
加權(quán)最少活躍調(diào)用優(yōu)先，活躍數(shù)越低，越優(yōu)先調(diào)用，相同活躍數(shù)的進行加權(quán)隨機處理?；钴S數(shù)指調(diào)用前后技術(shù)差（針對特定提供者，請求發(fā)送數(shù)-響應返回數(shù)），表示特定提供者的任務堆積量，活躍數(shù)越低，代表提供者處理能力越強。
慢的提供者收到更少請求，因為越慢的提供者的調(diào)用前后計數(shù)差會越大，相對的，處理能力越強的節(jié)點，處理更多的請求。
ShortestResponse
加權(quán)最短響應優(yōu)先，在最近一個滑動窗口中，響應時間越短，越優(yōu)先調(diào)用，相同響應時間的進行加權(quán)隨機。
使得響應時間越快的提供者，處理更多的請求
缺點：可能會造成流量過于集中于高性能節(jié)點的問題
這里的響應時間=某個提供者在窗口時間內(nèi)的平均響應時間，窗口時間默認是30s
ConsistentHash
一致性Hash，相同參數(shù)的請求總是發(fā)到同一提供者
當某一臺提供者宕機時，原本提供者的請求，基于虛擬節(jié)點，平攤到其他提供者，不會引起劇烈變動。
缺省只對第一個參數(shù)Hash，如果要修改，需要配置：<dubbo:parameter
key="hash.arguments" value="0,1" />
缺省用160份虛擬節(jié)點，如果要修改，請配置置 <dubbo:parameter
key="hash.nodes" value="320" />
配置方式：
Dubbo支持在服務提供者一側(cè)配置默認的負載均衡，這樣所有消費者都默認使用提供者指定的負載均衡策略，消費者可以自己配置要使用的負載均衡策略，如果沒有任何配置，則默認使用隨機負載均衡策略。
同一個應用內(nèi)支持配置不同的服務使用不同的負載均衡策略，支持同一服務的不同方法配置不同的負載均衡策略。文章來源：http://www.zghlxwxcb.cn/news/detail-514021.html
自適應負載均衡與服務柔性
整體介紹：
所謂的“柔性服務”主要是指consumer端的負載均衡和provider端的限流兩個功能，在這之前dubbo版本中，負載均衡部分更多的考慮是公平性原則，即consumer端盡可能平等的從provider中做出選擇，在某些情況下表現(xiàn)并不夠理想。而限流部分只提供了靜態(tài)的限流方案，需要用戶對provider端設置靜態(tài)的最大并發(fā)值，然而該值的合理選取對用戶來講并不容易。文章來源地址http://www.zghlxwxcb.cn/news/detail-514021.html
P2C算法原理介紹：
- 對于每次調(diào)用，從可用的Provider列表中做兩次隨機選擇，選出兩個節(jié)點providerA和providerB.
- 比較providerA和providerB兩個節(jié)點，選擇其“當前正在 處理的連接數(shù)”較小的那個節(jié)點。
到了這里，關于Dubbo接口級服務發(fā)現(xiàn)-數(shù)據(jù)結(jié)構(gòu)的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關文章，希望大家以后多多支持TOY模板網(wǎng)！
