Dubbo-簡單入門及使用

這是一張dubbo的調用圖

調用關係說明以下:

1) 服務容器啓動、加載和運行服務提供者；
2) 服務提供者在啓動時，向註冊中心註冊本身提供的服務；
3) 服務消費者在啓動時，向註冊中心訂閱本身所需的服務；
4) 註冊中心返回服務提供者地址列表給消費者，若是有變動，註冊中心將基於長鏈接推送變動給消費者；
5) 服務消費者從地址列表中，基於軟負載均衡算法選一臺服務提供者進行調用，若是調用失敗再選另外一臺；
6) 服務消費者和服務提供者在內存中累計調用次數和調用時間，定時每分鐘發送一次統計數據到監控中心。
複製代碼

節點角色說明

節點	角色說明
Container	服務運行容器
Provider	暴露服務的服務提供者
Consumer	調用遠程服務的服務消費者
Registry	服務註冊與發現的註冊中心
Monitor	統計服務的調用此處和調用時間的監控中心

Dubbo 服務器註冊與發現的流程？

• Provider（提供者）綁定指定端口並啓動服務。
• 提供者鏈接註冊中心，併發本機 IP、端口、應用信息和提供服務信息發送至註冊中心存儲。
• Consumer（消費者），鏈接註冊中心 ，併發送應用信息、所求服務信息至註冊中心。
• 註冊中心根據消費者所求服務信息匹配對應的提供者列表發送至 Consumer 應用緩存。
• Consumer 在發起遠程調用時基於緩存的消費者列表擇其一發起調用。
• Provider 狀態變動會實時通知註冊中心、在由註冊中心實時推送至 Consumer。

一.那麼,爲何要用dubbo呢?

2.1 爲何要作服務

技術爲業務而生，架構也爲業務而出現。隨着業務的發展、用戶量的增加，系統數量增多，調用依賴關係也變得複雜，爲了確保系統高可用、高併發的要求，系統的架構也從單體時代慢慢遷移至服務SOA時代，根據不一樣服務對系統資源的要求不一樣，咱們能夠更合理的配置系統資源，使系統資源利用率最大化。

1. 單一應用架構 當網站流量很小時，只需一個應用，將全部功能都部署在一塊兒，以減小部署節點和成本。 此時，用於簡化增刪改查工做量的 數據訪問框架(ORM) 是關鍵。
2. 垂直應用架構 當訪問量逐漸增大，單一應用增長機器帶來的加速度愈來愈小，將應用拆成互不相干的幾個應用，以提高效率。 此時，用於加速前端頁面開發的 Web框架(MVC) 是關鍵。
3. 分佈式服務架構 當垂直應用愈來愈多，應用之間交互不可避免，將核心業務抽取出來，做爲獨立的服務，逐漸造成穩定的服務中心，使前端應用能更快速的響應多變的市場需求。 此時，用於提升業務複用及整合的 分佈式服務框架(RPC) 是關鍵。
4. 流動計算架構 當服務愈來愈多，容量的評估，小服務資源的浪費等問題逐漸顯現，此時需增長一個調度中心基於訪問壓力實時管理集羣容量，提升集羣利用率。 此時，用於提升機器利用率的 資源調度和治理中心(SOA) 是關鍵。

平臺隨着業務的發展 從 All in One 環境 就能夠知足業務需求（以Java來講，可能只是一兩個war包就解決了）；發展到需 要拆分多個應用，而且採用MVC的方式 分離先後端，加快開發效率；在發展到服務愈來愈多，不得不將 一些核心或共用的服務拆分出來，提供實時流動監控計算等，其實發展到此階段，若是服務拆分的足夠精細，而且獨立運行，這個時候至少能夠 理解爲SOA架構 了。

2.2 服務帶來的挑戰

當迎來服務SOA時代，咱們面臨要解決的問題會不少，好比：系統的複雜度上升、服務依賴關係、服務性能監控、全鏈路日誌、容災、斷路器、限流等。那麼面對這些問題爲何還要作分佈式服務呢？由於在將來只有砥礪前行，才能走的更高更遠。不過看到這些問題不要氣餒，先無論這些問題，讓咱們一步步來梳理下現存有什麼問題，咱們要完成什麼目標，問題天然會迎刃而解。

根據如今團隊的業務系統狀況，首先咱們要梳理出現存的問題是什麼：

1. 多種調用傳輸方式：HTTP方式、WebService方式；
2. 服務調用依賴關係：人工記錄，查看代碼分析；
3. 服務調用性能監控：日誌記錄，人工查看時間；
4. 服務與應用緊耦合：服務掛掉，應用沒法可用；
5. 服務集羣負載配置：Nginx配置，存在單點問題；

在去選擇技術框架時，技術框架最基本要解決上面現存問題，同時咱們也要確認出咱們的指望，要達到的目標是什麼：

1. 支持當前業務需求，這是最最基本的條件；
2. 服務避免單點問題，去中心化；
3. 服務高可用、高併發，解耦服務依賴；
4. 服務通用化，支持異構系統調用服務；
5. 服務依賴關係自維護，可視化；
6. 服務性能監控自統計，可視化；
7. 服務需自帶註冊、發現、健康檢查、負載均衡等特性；
8. 開發人員關注度高，上手快，簡單輕量，低侵入；

還有最重要一點，這也是每每不少技術人員進入的誤區，「對於技術，不要爲了使用而使用，用最簡單合適的技術實現解決問題纔是正道」。架構是服務於業務的，能快速方便的知足業務需求的架構纔是好的架構。

二.dubbo怎麼使用?

Dubbo 採用全 Spring 配置方式，透明化接入應用，對應用沒有任何 API 入侵，只需用 Spring 加載 Dubbo 配置便可。

# 3.1 安裝註冊中心

官方推薦使用 Zookeeper 做爲註冊中心，所以本次測試使用 Zookeeper，將其放置在 ip 爲 192.168.1.1 的虛擬機上。

# 解壓和轉移目錄
tar -zxvf zookeeper-3.4.8.tar.gz -C /usr/
cd /usr
mv zookeeper-3.4.8 zookeeper

# 設置配置文件
cd /usr/zookeeper/conf
cp zoo_sample.cfg zoo.cfg

# 啓動 zookeeper
/usr/zookeeper/bin/zkServer.sh start

# 查看 zookeeper 運行狀態，若是出現 Mode: standalone 說明運行成功
/usr/zookeeper/bin/zkServer.sh status
複製代碼

# 3.2 服務提供者

建立一個 Maven 項目（名爲 dubbo-service 的 web 項目）。

pom.xml 配置：

web.xml 配置：

接口：

實現類：

applicationContext-dubbo.xml 配置：

//提供方應用信息,計算依賴關係
    <dubbo:application name="hello-demo"/>
    //使用廣播註冊中心暴露服務地址
    <dubbo:registry address="zookeeper://192.168.1.1:2181"/>
    //用dubbo協議在20880端口暴露服務
    <dubbo:protocol name="dubbo" port="20880"/>
    //聲明須要暴露服務的服務接口
    <dubbo:service interface="com.light.dubbo.service.HelloService" ref="helloService"/>
    
    <bean id="helloService" class="com.light.dubbo.service.impl.HelloServiceImpl"/>
複製代碼

# 3.3 服務消費者

建立一個 Maven 項目（名爲 dubbo-consumer 的 web 項目）。

pom.xml 配置：

web.xml 配置：

將 dubbo-service 項目中的 HelloService 接口複製到該項目（dubbo-consumer）中。

控制層：

@Controller
public class HelloController {

    @Autowired
    private HelloService helloService;
    
    @RequestMapping("hello")
    @ResponseBody
    public String hello(String name) {
        return this.helloService.sayHello(name);
    }
}
複製代碼

applicationContext-dubbo.xml 配置：

<dubbo:application name="hello-demo"/>
       
    <dubbo:registry address="zookeeper://192.168.2.14:2181"/>
    
    <dubbo:protocol name="dubbo" port="20880"/>
    
    <dubbo:reference interface="com.light.dubbo.service.HelloService"/>

複製代碼

springmvc.xml 配置：

先啓動服務提供者的項目（8080），再啓動服務消費者的項目（8081）。打開瀏覽器訪問http://localhost:8081/hello?name=jack,結果以下圖：

三.dubbo其餘點

Dubbo 有哪些註冊中心？

• Zookeeper 註冊中心：基於分佈式協調系統 Zookeeper 實現，採用 Zookeeper 的 watch 機制實現數據變動。

Dubbo 的註冊中心集羣掛掉，發佈者和訂閱者之間還能通訊麼？

能夠通信。啓動 Dubbo 時，消費者會從 Zookeeper 拉取註冊的生產者的地址接口等數據，緩存在本地。每次調用時，按照本地存儲的地址進行調用。