Dubbo基礎知識點有哪些

本篇內容主要講解“Dubbo基礎知識點有哪些”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“Dubbo基礎知識點有哪些”吧!

Dubbo是一個分布式服務框架，以及SOA處理方案。其功能主要包括：高性能NIO通訊以及協議集成，服務動態尋址與路由，轉負載均衡與容錯，依賴分析與降級。它有5個節點，分別是provider,Consumer，Registry,Monitor,container。其中  provider是服務提供者  consumer是服務消費者 Registry是服務進行注冊和被發現的注冊中心。Monitor是統計服務調用次數和調用時間的監控中心，Container是服務運行容器。

consumer負責啟動  然后運行provider。provider在啟動時向注冊中心注冊自己提供的服務，consumer在啟動時向注冊中心訂閱自己需要的服務，此時Registry會基于長連接推送變更數據給consumer。consumer會基于轉負載均衡算法選一臺服務器進行調用，如果調用失敗，則再選一臺。provider和consumer在內存中累計調用次數和調用時間，定時每分鐘發送一次數據到monitor。

Dubbo有四個特點 即連通性 健壯性 伸縮性 以及向未來架構的升級性。聯通性說明他們存在著聯系 比如 provider  consumer和registry三者之間是長連接的，而provider和consumer向registry注冊服務以及訂閱服務的時間都得向monitor匯報。而健壯性則說明具有穩定性，比如書注冊中心對等集群中任意一臺服務器宕掉后，將自動切換到另一臺。就算注冊中心全部宕掉  服務者和消費者仍可以通過本地緩存進行通訊。而伸縮性就是可以通過增加繼器部署實例進行添加新的注冊中心和服務提供者。升級性是提到的對未來架構的設想，比起目前架構它的特點是還可以實現自動部署服務的本地代理及可以通過訪問壓力來自動增減服務提供者。

服務節點關系的調用

1 服務容器負責啟動 ，加載  運行服務提供者

2 服務提供者在啟動時  向注冊中心注冊自己提供的服務

3 服務消費者在啟動時 向注冊中心訂閱自己所需要的服務。

4 注冊中心返回服務提供者地址列表給消費者，如果有變更，注冊中心將基于長連接推送變更數據給消費者。

5 服務消費者 從提供地址列表中 基于轉負載均衡算法，選一臺提供者進行調用，如果調用失敗  再選一臺進行調用。

6 服務調用者和消費者 在內存中累計調用次數和調用時間，定時每分鐘發送一次統計數據到監控中心。

當zookeeper作為dubbo的注冊中心時，是怎樣工作的？

zookeeper作為dubbo的注冊中心時，服務提供者在初始化啟動時，會在zookeeper下的dubbo節點下的服務節點下的provider節點下的節點創建一個子節點并寫入URL 路徑類似于/dubbo/servicename/providers/,該路徑下的所有子節點均為服務提供者。此時所有節點均為臨時節點，因為臨時節點的生命周期與客戶端會話相關，所以一旦提供者所在的機器出現故障無法提供服務，該臨時節點會自動從zookeeper中消除。此時因為消費者  服務者  注冊中心是長連接，注冊中心能感知服務者宕機，它會告訴消費者。而監控中心是Dubbo服務治理體系中重要的一部分，它需要知道所有的服務者和提供者的變化，所以它在啟動時會在服務節點上注冊一個watcher來監聽子節點的變化，路徑為/dubbo/servicename，所以它也能感知服務提供者的宕機。服務消費者節點的創建過程和提供者是一樣的而且也是臨時節點。還有一個特性就是zookeeper的節點結構設計，它以服務名和類型，也就是/dubbo/servie為節點路徑，符合Dubbo訂閱和通知的需求，保證了以服務為力度的變更通知，通知范圍易于控制。所以即使消費者和提供者頻繁變更，對zookeeper的性能也不會造成多大影響。

什么是Dubbo?

Dubbo是一款高性輕量級的開源Java  RPC框架，它提供了三大核心功能：面向接口的遠程方法調用，只能容錯和負載均衡，以及服務自動注冊和發現。簡單來說Dubbo是一個分布式服務框架，致力于提高性能和透明化的RPC遠程調用方案，以及SOA服務治理方案。

什么是RPC  RPC 的原理是什么？

RPC是一種遠程調用，它是一種通過網絡從計算機程序上請求服務，而不需要了解底層網絡技術的協議。比如兩個不同的服務A B ，部署在兩臺不同的機器上，如果服務A想調用服務B中的某個方法怎么辦，使用HTTP請求，當然可以，但是會比較慢而且一些優化做的并不好。RPC的出現正是為了解決這個問題。

RPC原理是什么？

為（）什么要用Dubbo?

Dubbo的誕生和SOA分布式架構有很大的關系。SOA面向服務的架構，也就是把工程按照業務邏輯分成服務表現層兩個工程。服務層中包含業務邏輯，只需要對外提供服務即可。表現層只需要處理和頁面的交互，業務邏輯都是調用服務層的服務來實現的。SOA架構中主要有兩個角色：服務提供者（provider）和服務使用者（Cosumer）。

如果要開發分布式程序，可以直接用HTTP接口進行通信，為什么還要用Dubbo呢？

可以從Dubbo提供的四點特性來說明為什么要用Dubbo？
1 負載均衡  -----同一個服務部署在不同的服務器時刻該調用哪一臺機器上的服務。

2 服務調用鏈路生成  -----隨著系統的發展，服務越來越多，服務之間的依賴關系變得錯綜復雜，甚至分不清哪個應用在哪個應用之前啟動，架構師也不能完整的描述架構關系。Dubbo可以為我們解決服務之間如何調用的問題。

3 服務訪問壓力及時長統計、資源調整和力度------基于訪問壓力時管理集群容量，提高集群利用率。

4 服務降級------某個服務掛掉之后調用備用服務。

什么是分布式？

分布式或者說SOA分布式重要的是面向服務，說簡單的分布式就是我們將整個系統拆分成不同的服務然后將這些服務放在不同的服務器上減輕單體服務的壓力提高并發量和性能。比如電商系統可以拆分成訂單系統、 商品系統、登陸系統。拆分之后每個系統可以部署在不同的服務器上，如果一個服務的訪問量比較大的話也可以將這個服務同時部署在多臺機器上。

為什么要用分布式？

從開發的角度來講單體的應用代碼都集中在一起，而分布式系統的代碼根據業務被拆分。所以每個團隊可以負責一個服務的開發，這樣就提升了開發效率。另外  代碼根據業務拆分之后更加便于維護和發展。

Dubbo的負載均衡策略·

先解釋一下什么是負載均衡？

維基百科對負載均衡的定義：

比如系統中的某個服務訪問量很大，我們將這個服務上部署在多臺服務器上，當客戶端發起請求的時候，多臺服務器就可以處理這個請求。那么如何正確選擇處理該請求的服務器就很關鍵。假如  就要一臺服務器來處理這些請求，那該服務部署在多臺服務器的意義就不大了。負載均衡就是為了避免單個服務器響應同一請求，容易造成服務宕機、崩潰等問題。

Dubbo的負載均衡策略

1 Random   LoadBalance（默認，基于權重的隨機負載均衡機制）

隨機  按權重設置隨機概率       在一個截面上碰撞的概率高，但調用量越大分布越均勻，有利于動態調整提供者權重。

2 RoundRobin  LoadBalance （不推薦，基于權重的輪詢負載均衡機制）

輪詢 ，按照公約后的權重設置輪詢比率。

存在慢的提供者積累請求的問題：比如 第二臺機器很慢，但沒掛，當請求調到第二臺機器時就卡在那，久而久之，所有請求都調到第二臺上。

3  LeastActive  LoadBalance

* 最少活躍調用數，相同活躍數的隨機，活躍數指調用前后計數差

* 使慢的提供者收到更少的請求，因為越慢的提供者的調用前后計數差越大。

4 ConsistentHash    LoadBalance

一致性Hash，相同參數的請求總是發送到同一提供者。

到此，相信大家對“Dubbo基礎知識點有哪些”有了更深的了解，不妨來實際操作一番吧！這里是億速云網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續學習！