從零開始的高併發（九）--- 初識dubbo

前言

前情概要

上一篇咱們簡單實現了一個本身的RPC框架，主要依託咱們上兩篇所提到的這個RPC的流程分析

1.客戶端處理過程當中調用client stub（就像調用本地方法同樣），傳入參數

2.Client stub將參數編組爲消息，而後經過系統調用向服務端發送消息

3.客戶端本地操做系統將消息從客戶端機器發送到服務端機器

4.服務端操做系統將接收到的數據包傳遞給client stub

5.server stub解組消息爲參數

6.server stub再調用服務端的過程，過程執行結果以反方向的相同步驟響應給客戶端
複製代碼

stub：分佈式計算中的存根是一段代碼，它轉換在遠程過程調用期間Client和server之間傳遞的參數

咱們還經過發現者的引入，對協議支持和網絡層的提取進行了一些小的優化，結構以下：

PS:紫色表明客戶端代理部分，淺綠色屬於服務發現，淺藍色屬於協議部分

各個小塊的代碼基本已經給出，相信即便是本身須要跑一下的話也無需進行過多的代碼填充工做了

以往連接

從零開始的高併發（一）--- Zookeeper的基礎概念

從零開始的高併發（二）--- Zookeeper實現分佈式鎖

從零開始的高併發（三）--- Zookeeper集羣的搭建和leader選舉

從零開始的高併發（四）--- Zookeeper的分佈式隊列

從零開始的高併發（五）--- Zookeeper的配置中心應用

從零開始的高併發（六）--- Zookeeper的Master選舉及官網小覽

從零開始的高併發（七）--- RPC的介紹，協議及框架

從零開始的高併發（八）--- RPC框架的簡單實現

dubbo概述

① dubbo的簡介

和zookeeper相似，網址只須要記住，首先這個項目叫dubbo，而後它是屬於apache下的，而後開源是非營利性組織，也就是org，因此網址就是：

dubbo.apache.org/

可能小夥伴們要是留意這張圖片的話，會發現一開始的時候，它的這張圖片右上方是帶有Incubating這個英文的，有這個英文說明當時的dubbo仍是一個孵化項目，並且由於它是中國人開發的，因此對於中文的翻譯支持很是全面，因此對於咱們來講學起來應該算是最便利的

Apache Dubbo是一款高性能，輕量級的開源java RPC框架，提供了3大核心能力，面向接口的遠程方法調用，智能容錯和負載均衡，服務自動註冊及發現。

這樣一對比，好像咱們上一篇寫出來的小樣就弱爆了哈哈哈

② dubbo能作什麼

③ dubbo的架構

Provider：服務提供者，咱們的service，實際執行業務邏輯的服務層
Consumer：服務消費者，對service進行調用，不關注service的具體實現的應用層
Register：註冊中心，存儲Provider，Consumer信息的中介
Monitor：監控中心，dubbo負責收集服務調用信息的監控中心
複製代碼

若是事先有了解過應該在官網上應該看過了，init是初始化，async是異步，sync是同步。咱們不難發現全部的RPC框架都脫離不了三個基本要素，就是服務消費者和服務提供者，還有把這些角色們組合起來的網絡，缺乏一個都談不上是一個完整的RPC了。

第一步就是咱們的服務提供者經過初始化動做，把它的服務信息暴露給註冊中心，好比端口號，協議，版本，參數，接口，方法或返回值等基本信息，註冊中心register就能夠視爲一個媒人，服務提供者看做相親對象女方，這些對象要把它們的基本信息給到媒人以便讓服務消費者（男方）認識，此時咱們男方是在這個中介所下了單的，讓中介所幫忙留意他喜歡的女生，符合要求就通知他，因此subscribe訂閱，就是男方讓媒人幫忙留意合適的女方的動做

但是姑娘的狀態信息不是一成不變的，因此男方也須要異步得到女方的動態，而這個動態也是媒人Registry來notify告知的，那這個機制在這裏也是不難猜到，是使用zookeeper的watch機制來實現的，invoke就相似於他們交往溝通的過程了

Monitor就相似於國家的315消費者協議，此次的服務是個什麼效果，來作個調研

④ dubbo的調用過程

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

2.服務提供者在啓動時，向註冊中心註冊本身提供的服務

3.服務消費者在啓動時，向註冊中心訂閱本身所需的服務

4.註冊中心返回服務提供者地址列表給消費者，若是有變動，註冊中心將基於長鏈接推送變動數據給消費者

5.服務消費者從提供者地址列表中，基於軟負載均衡算法，選一臺提供者進行調用，若是調用失敗，再選擇另外一臺調用

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

⑤ dubbo的架構特色

dubbo分別具備如下特色，連通性，健壯性，伸縮性和升級性

連通性：剛剛也提到異步操做主要是兩個，一個是訂閱服務地址的變化，另外一個是監控中心的執行是異步的，這說明了一點，在咱們程序運行過程當中，註冊中心或者監控中心掛掉，是不會對咱們的程序流程形成影響的，就比如男方已經獲取到女方的電話了，這樣男方就天然能夠和女方取得聯繫，而無所謂女方忽然變胖一兩斤或者感冒發燒。而監控中心掛掉只會影響咱們的一些採集數據，也不會對程序形成影響

健壯性：這個在以前的zookeeper中已經無數次地被提到了，節點掛掉不影響集羣其餘節點的工做

升級性：就是一個服務治理方面的想法，達到自動增長服務器去消費忽然增加的請求數的一個功能

⑥ dubbo的依賴

必須：JDK1.6+,理論上dubbo能夠只依賴JDK，不依賴其餘第三方庫運行，須要配置JDK相關實現策略

缺省：

⑦ dubbo的使用方式

服務提供端：
    1.獨立的服務（普通的java程序形式）
    2.集成在應用中（在應用中增長遠程服務能力）
消費客戶端
    1.在應用中調用遠程服務
    2.在服務1提供者中調用遠程服務
複製代碼

⑧ dubbo的三種配置方式

1.使用dubbo註解

使用相對簡單，不過有侵入性，須要實現類中依賴dubbo提供的註解

2.集成Spring XML（使用較多）

使用相對麻煩，能夠無侵入，方便之後改用其餘RPC框架

3.使用原生API的方式

編程過程十分麻煩，通常僅用於測試，開放API的場景

⑨ dubbo的使用步驟

1.引入dubbo相關依賴

2.配置dubbo框架（也就是 ⑧ 提到的3個方式）

3.服務的開發與配置

4.啓動和調用

<dependency>
  <groupId>io.netty</groupId>
  <artifactId>netty-all</artifactId>
  <version>4.1.32.Final</version>
</dependency>
<dependency>
    <groupId>com.alibaba</groupId>
    <artifactId>dubbo</artifactId>
    <version>2.6.6</version>
</dependency>
複製代碼

finally

也是有小夥伴反映我貼代碼貼的有點太多，也是由於此次的小樣比較無關緊要吧，因此就省事了。篇幅的問題你們詬病已久，更加詳細的內容也是留下一篇再扯扯吧（不少代碼···）

下一篇：dubbo的核心功能詳解與配置