dubbo基礎學習

2021-10-22 18:26:47 字數 2047 閱讀 2179

dubbo是乙個分布式服務框架,致力於提供高效能和透明化的rpc遠端服務呼叫方案,以及soa服務治理方案。

其核心部分包含:

遠端通訊: 提供對多種基於長連線的nio框架抽象封裝,包括多種執行緒模型,序列化,以及「請求-響應」模式的資訊交換方式。

集群容錯: 提供基於介面方法的透明遠端過程呼叫,包括多協議支援,以及軟負載均衡,失敗容錯,位址路由,動態配置等集群支援。

自動發現: 基於註冊中心目錄服務,使服務消費方能動態的查詢服務提供方,使位址透明,使服務提供方可以平滑增加或減少機器。

dubbo系統分為五個部分:遠端服務執行容器(container),遠端服務提供方(provider)、註冊中心(register)、遠端服務呼叫者(consumer)、監控中心(monitor)。

dubbo服務呼叫過程:

服務提供方(provider)所在的應用在容器中啟動並執行(這個容器可以說是該應用部署的tomcat)。

服務提供方(provider)將自己要發布的服務註冊到註冊中心(registry)。

服務呼叫方(consumer)啟動後向註冊中心訂閱它想要呼叫的服務。

註冊中心(registry)儲存著provider註冊的遠端服務,並將其所管理的服務列表通知給服務呼叫方(consumer),且註冊中心和提供方和呼叫方之間均保持長連線,

可以獲取provider發布的服務的變化情況,並將最新的服務列表推送給consumer。

consumer根據從註冊中心獲得的服務列表,根據軟負載均衡演算法選擇乙個服務提供者(provider)進行遠端服務呼叫,如果呼叫失敗則選擇另一台進行呼叫。

(consumer會快取服務列表,即使註冊中心宕機也不妨礙進行遠端服務呼叫)。

監控中心(monitor)對服務的發布和訂閱進行監控和統計服務消費者和提供者,在記憶體中累計呼叫次數和呼叫時間,定時每分鐘傳送一次統計資料到監控中心(monitor);

monitor可以選擇zookeeper、redis或者multiast註冊中心等。

dubbo可以用zookeeper作為註冊中心,儲存註冊中心provider註冊的遠端服務資訊。

服務提供方通過dubbo建立service這個服務,並且到zookeeper上面註冊,填寫對應的zookeeper服務所在的ip及埠號。

服務呼叫者需要來呼叫service介面,由於在不同的工程中,它是無法直接找到service介面的,我們使用dubbo再來引用註冊進入的dubbo服務。

先填寫zookeeper服務所在的ip及埠號,再填寫我們需要呼叫的介面名字。這樣,就能實現呼叫。

dubbo不僅可選zookeeper作為註冊中心,還有其他幾種型別。dubbo提供的註冊中心有:zookeeper註冊中心,redis註冊中心,multicast註冊中心,******註冊中心

>

>

com.101tecgroupid

>

>

zkclientartifactid

>

>

0.3version

>

dependency

>

>

>

org.apache.zookeepergroupid

>

>

zookeeperartifactid

>

>

3.5.6version

>

dependency

>

>

>

com.alibabagroupid

>

>

dubboartifactid

>

>

2.5.3version

>

>

>

>

org.springframeworkgroupid

>

>

springartifactid

>

exclusion

>

exclusions

>

dependency

>

Dubbo實戰 基礎學習篇(一)

dubbo是阿里巴巴soa服務化治理方案的核心框架,每天為2,000多個服務提供30多億次訪問量支援,並被廣泛應用於阿里巴巴集團的各成員站點。dubbo是乙個分布式服務框架,致力於提供高效能和透明化的rpc遠端服務呼叫方案,以及soa服務治理方案。1 當服務越來越多時,服務url配置管理變得非常困難...

Dubbo基礎學習筆記 可供面試

dubbox 是乙個分布式服務框架,致力於提供高效能和透明化的rpc遠端服務呼叫方案,以及soa服務治理方案。其前身是阿里巴巴開源專案dubbo 後期當當網便在dubbo基礎上進行優化,並繼續維護,為了與原有的dubbo區分,故將其命名dubbox。兩者是一樣的。簡單的說,dubbox就是個遠端服務...

Dubbo基礎認識

分布式架構主要存在的問題 遠端服務呼叫是實現分布式的關鍵因素.1.1.需要考慮底層網路通訊協議的處理 1.2.需要考慮序列化和反序列化的處理 大規模服務化對於服務治理的要求。2.1.服務鏈路變長,需要對服務鏈路跟蹤和監控 2.2.服務的大規模集群使得服務之間需要依賴第三方註冊中心來解決服務的發現和服...