我眼中的dubbo

 我眼中的DUBBO

（微信地址：http://mp.weixin.qq.com/s?__biz=MzIwMTA2MjMxNA==&mid=211696554&idx=1&sn=6f66d1c31fd11f5deee2d4ddd840fcf2&scene=0#rd）

一．    前言

dubbo做爲一款國內開源的優秀分佈式服務框架，深受各互聯網公司的喜好，並且官方文檔介紹很是詳細，上手並不困難。所以，本文主要介紹dubbo在媒資系統中的應用，遇到的問題， dubbo源碼學習的一些心得，詳細使用流程請參見http://dubbo.io,若是有對dubbo感興趣的開發者們能夠申請加入https://github.com/dubbo 一同探討，共同進步。

二．    Dubbo是什麼——what

隨着互聯網的發展，網站應用的規模不斷擴大，常規的垂直應用架構已沒法應對，分佈式服務架構以及流動計算架構勢在必行，亟需一個治理系統確保架構有條不紊的演進。

以上概述是官網文檔的解釋，對於目前個人理解，what is dubbo？

dubbo是一款分佈式服務框架

       －高性能和透明化的RPC遠程服務調用方案

       －SOA服務治理方案

 

dubbo的基本架構圖：（見微信）

進一步剖析，dubbo的基本原理如圖2表示（見微信）

隨着互聯網應用的蓬勃發展，架構依賴愈來愈複雜，做爲一款分佈式服務框架，服務治理是dubbo最須要解決的問題。服務數量的激增，服務間依賴關係的複雜，以及服務調用量所帶來的一系列問題，都是咱們做爲開發人員所要面臨和解決的，這也是dubbo分佈式服務框架造成的最重要緣由。

 

三．    爲何使用Dubbo——why

1.首先介紹下Dubbo的一些主要特性。

一．透明化的遠程方法調用

－ 就像調用本地方法同樣調用遠程方法

－ 只需簡單配置，沒有任何API侵入

二．軟負載均衡及容錯機制

－ 可在內網替代nginx lvs等硬件負載均衡器

三．服務註冊中心自動註冊 & 配置管理

    － 不須要寫死服務提供者地址，註冊中心基於接口名自動查詢提供者ip

－ 使用相似zookeeper等分佈式協調服務做爲服務註冊中心，能夠將絕大部分項目配置移入zookeeper集羣

四．服務接口監控與治理

   － dubbo-admin與dubbo-monitor提供了完善的服務接口管理與監控功能，針對不一樣應用的不一樣接口，能夠進行多版本，多協議，多註冊中心管理。

 

2.Dubbo在媒資系統中的應用。

   透明化的遠程方法調用

 

       使用前，媒資系統內部服務調用主要經過數據庫查詢 和 HTTP接口方式實現。一則查詢效率低，擴展一些搜索框架比較困難，二則解析http請求很是麻煩，不只須要解析消息體，還有一些狀態設置，使程序的複雜性大大提升。

   對於一些複雜查詢場景，like全表遍歷查詢效率低，所以咱們引入了elasticsearch分佈式搜索引擎，構建lucene倒排索引來彌補單純依賴數據庫查詢功能的不足。基於ES構建mms-search做爲服務提供者，將媒資不一樣類型數據的查詢服務以dubbo-rpc遠程調用的形式提供給數據消費方。提供方與消費方只須要簡單配置（如圖3），消費方就能夠像調用本地方法同樣遠程調用接口。

（見微信）

服務接口監控與治理

 

其次搭建了一個zookeeper集羣做爲dubbo的註冊中心，並搭建了一個修改過的dubbo-admin管理後臺，（因爲目前開源dubbo對於admin模塊通過閹割，部分功能沒法使用，須要修改部分源碼來適應項目）如圖4，5，6（見微信）

做爲維護者，咱們能夠很容易得監控到目前所註冊的全部接口的詳細信息，並能夠對每一個接口進行及時處理。

 

 

配置管理

 

       第三，咱們擴展了dubbo-admin的功能，將zookeeper的配置管理功能與dubbo相結合，將原先配置在pom或者每一個項目中的各類properties,xml等文件內容存入zookeeper節點，並經過dubbo-admin上傳修改，大大簡化了複雜系統的配置項，初期咱們將此功能放入mms-webapps（媒資vrs後臺）中操做，實踐發現一旦mms-webapps出現了故障，整個mms系統都會由於缺乏配置文件而崩潰，所以最終將配置管理功能移入dubbo-admin中，單獨部署，不依賴其餘mms模塊，如圖7，8（見微信）

3.後期優化與擴展

 

       前期dubbo在媒資系統局部範圍進行了實踐，運行比較穩定。後期媒資內部服務治理，將全面RPC化；對外提供的媒資接口也會提供一套dubbo RPC 實現，方便JAVA系的消費方調用，實際看下dubbo在高併發應用場景下的表現。隨着更大範圍的推廣使用，將來會更深刻使用到dubbo更多的特性，如負載均衡，集羣容錯，服務降級，優雅停機，服務多版本，分組服務等。

四．Dubbo使用遇到的問題總結

 

           1.目前dubbo在媒資系統運行良好，並無出現很大的問題，有些開發者閱讀完咱們媒資系統的使用確定會問，zookeeper擔負着註冊中心以及項目配置中心雙重任務，若是掛了會怎樣？目前咱們的應對方案是3臺zk服務作集羣，leader選舉的方式，而且在媒資監控模塊中進行以下監控

節點自檢 ：

是指對集羣中每一個IP所在ZK節點上的PATH: /ZK.MONITOR.ALIVE.CHECK 按期進行三次以下流程 節點鏈接 - 數據發佈 - 修改通知 - 獲取數據 - 數據對比, 三次流程均成功視爲該節點處於正常狀態。（有興趣具體zk能夠查詢下資料）

           2.日誌輸出

dubbo默認使用log4j作日誌輸出，若是項目中使用的slf4j+logback，除了拋到外面的異常被本身的框架撲捉，dubbo自己的一些warn，info信息是無法記錄的。

須要在xml中文件增長配置以下   

 <dubbo:application name="mms-webapp" logger="slf4j"/>

 

3.本地緩存注冊中心

dubbo爲了在不讓請求每次都訪問註冊中心，同時在註冊中心掛掉的時候仍然能夠繼續提供服務，會在本地把提供者的列表進行一個文件緩存。

默認不設置緩存文件地址會在當前用戶根目錄下建立文件夾.dubbo，緩存的註冊中心文件會放在這裏。

能夠經過配置指定緩存文件的路徑       

<register file="/letv/dubbo.cache" />

可是這裏必定要注意的是要保證啓動app的用戶要有這個目錄下寫文件的權限，不然會致使這個進程一直循環處理（dubbo內部實現是有異常cache，再次建立），cpu 100%)。

 

4.初期學習完成demo時需注意，若是將provider.xml與consumer.xml在一個工程中使用applicationContext.xml引入會報bean重複。模擬服務器啓動要注意修改協議端口，每臺服務器的協議端口也不相同，不然啓動第二臺服務器的時候就會報com.alibaba.dubbo.remoting.RemotingException: Failed to bind NettyServer錯誤

 

5. 出現RpcException: No provider available for remote service異常怎麼辦？

       除了官方上的一些辦法，咱們在啓動dubbo的時候若是遇到部分接口升級不但願註冊時，可使用

<dubbo:reference 標籤> 配置check屬性爲false

這樣dubbo就能正常啓動了。