互聯網的發展,網站應用的規模不斷擴大,常規的垂直應用架構已無法應對,分佈式服務架構以及流動計算架構勢在必行,Dubbo是一個分佈式服務框架,在這種情況下誕生的。現在覈心業務抽取出來,作爲獨立的服務,使前端應用能更快速和穩定的響應。
第一:介紹Dubbo背景
大規模服務化之前,應用可能只是通過RMI或Hessian等工具,簡單的暴露和引用遠程服務,通過配置服務的URL地址進行調用,通過F5等硬件進行負載均衡。
(1) 當服務越來越多時,服務URL配置管理變得非常困難,F5硬件負載均衡器的單點壓力也越來越大。
此時需要一個服務註冊中心,動態的註冊和發現服務,使服務的位置透明。
並通過在消費方獲取服務提供方地址列表,實現軟負載均衡和Failover,降低對F5硬件負載均衡器的依賴,也能減少部分成本。
(2) 當進一步發展,服務間依賴關係變得錯蹤複雜,甚至分不清哪個應用要在哪個應用之前啓動,架構師都不能完整的描述應用的架構關係。
這時,需要自動畫出應用間的依賴關係圖,以幫助架構師理清理關係。
(3) 接着,服務的調用量越來越大,服務的容量問題就暴露出來,這個服務需要多少機器支撐?什麼時候該加機器?
爲了解決這些問題,第一步,要將服務現在每天的調用量,響應時間,都統計出來,作爲容量規劃的參考指標。
其次,要可以動態調整權重,在線上,將某臺機器的權重一直加大,並在加大的過程中記錄響應時間的變化,直到響應時間到達閥值,記錄此時的訪問量,再以此訪問量乘以機器數反推總容量。
第二:Dubbo的簡介
Dubbo是一個分佈式服務框架,解決了上面的所面對的問題,Dubbo的架構如圖所示:
節點角色說明:
Provider: 暴露服務的服務提供方。
Consumer: 調用遠程服務的服務消費方。
Registry: 服務註冊與發現的註冊中心。
Monitor: 統計服務的調用次調和調用時間的監控中心。
Container: 服務運行容器。
調用關係說明:
0. 服務容器負責啓動,加載,運行服務提供者。
1. 服務提供者在啓動時,向註冊中心註冊自己提供的服務。
2. 服務消費者在啓動時,向註冊中心訂閱自己所需的服務。
3. 註冊中心返回服務提供者地址列表給消費者,如果有變更,註冊中心將基於長連接推送變更數據給消費者。
4. 服務消費者,從提供者地址列表中,基於軟負載均衡算法,選一臺提供者進行調用,如果調用失敗,再選另一臺調用。
5. 服務消費者和提供者,在內存中累計調用次數和調用時間,定時每分鐘發送一次統計數據到監控中心。
Dubbo提供了很多協議,Dubbo協議、RMI協議、Hessian協議,我們查看Dubbo源代碼,有各種協議的實現,如圖所示:
我們之前沒用Dubbo之前時,大部分都使用Hessian來使用我們服務的暴露和調用,利用HessianProxyFactory調用遠程接口。
上面是參考了Dubbo官方網介紹,接下來我們來介紹SpringMVC、Dubbo、Zookeeper整合使用。
第三:Dubbo與Zookeeper、SpringMVC整合使用
第一步:在Linux上安裝Zookeeper
Zookeeper作爲Dubbo服務的註冊中心,Dubbo原先基於數據庫的註冊中心,沒采用Zookeeper,Zookeeper一個分佈式的服務框架,是樹型的目錄服務的數據存儲,能做到集羣管理數據 ,這裏能很好的作爲Dubbo服務的註冊中心,Dubbo能與Zookeeper做到集羣部署,當提供者出現斷電等異常停機時,Zookeeper註冊中心能自動刪除提供者信息,當提供者重啓時,能自動恢復註冊數據,以及訂閱請求。我們先在linux上安裝Zookeeper,我們安裝最簡單的單點,集羣比較麻煩。
(1)下載Zookeeper-3.4.6.tar.gz 地址http://www.apache.org/dist/zookeeper/
(2) 我們放到Linux下的一個文件夾,然後解壓:
#tar zxvf zookeeper-3.4.6.tar.gz
(3)然後在對應的zookeeper-3.4.6/conf 下有一個文件zoo_sample.cfg的這個文件裏面配置了監聽客戶端連接的端口等一些信息,Zookeeper 在啓動時會找zoo.cfg這個文件作爲默認配置文件,所以我們複製一個名稱爲zoo.cfg的文件,如圖所示:
我們查看一下這個文件的裏面的一些配置信息,如圖所示:
獲取【下載地址】 最主流的Java後臺 SSM 框架 springmvc spring mybatis 項目源碼
說明:
clientPort:監聽客戶端連接的端口。
tickTime:基本事件單元,以毫秒爲單位。它用來控制心跳和超時,默認情況下最小的會話超時時間爲兩倍的 tickTime。
我們可以對配置文件的端口等或者進行高級配置和集羣配置例如:maxClientCnxns:限制連接到 ZooKeeper 的客戶端的數量等
(4)啓動Zookeeper 的服務,如圖所示:
到這邊Zookeeper的安裝和配置完成
第二步:配置dubbo-admin的管理頁面,方便我們管理頁面
(1)下載dubbo-admin-2.4.1.war包,在Linux的tomcat部署,先把dubbo-admin-2.4.1放在tomcat的webapps/ROOT下,然後進行解壓:
#jar -xvf dubbo-admin-2.4.1.war
(2)然後到webapps/ROOT/WEB-INF下,有一個dubbo.properties文件,裏面指向Zookeeper ,使用的是Zookeeper 的註冊中心,如圖所示:
(3)然後啓動tomcat服務,用戶名和密碼:root,並訪問服務,顯示登陸頁面,說明dubbo-admin部署成功,如圖所示:
第三步:SpringMVC與Dubbo的整合,這邊使用的Maven的管理項目
第一:我們先開發服務註冊的,就是提供服務,項目結構如圖所示:
(1)test-maven-api項目加入了一個服務接口,代碼如下:
(2)test-maven-console在pom.xml加入Dubbo和Zookeeper的jar包、引用test-maven-api的jar包,代碼如下:
(3)test-maven-console實現具體的服務,代碼如下:
(4)我們服務以及實現好了,這時要暴露服務,代碼如下:
說明:
dubbo:registry 標籤一些屬性的說明:
1)register是否向此註冊中心註冊服務,如果設爲false,將只訂閱,不註冊。
2)check註冊中心不存在時,是否報錯。
3)subscribe是否向此註冊中心訂閱服務,如果設爲false,將只註冊,不訂閱。
4)timeout註冊中心請求超時時間(毫秒)。
5)address可以Zookeeper集羣配置,地址可以多個以逗號隔開等。
dubbo:service標籤的一些屬性說明:
1)interface服務接口的路徑
2)ref引用對應的實現類的Bean的ID
3)registry向指定註冊中心註冊,在多個註冊中心時使用,值爲<dubbo:registry>的id屬性,多個註冊中心ID用逗號分隔,如果不想將該服務註冊到任何registry,可將值設爲N/A
4)register 默認true ,該協議的服務是否註冊到註冊中心。
(5)啓動項目,然後我們在Dubbo管理頁面上顯示,已經暴露的服務,但顯示還沒有消費者,因爲我們還沒實現消費者服務,如圖所示:
第二:我們在開發服務消費者,就是調用服務,我們在新建一個新的消費者項目結構如圖所示:
(1)test-maven-server-console的pom.xml引入Dubbo和Zookeeper的jar包、test-maven-api的jar包,因爲引入test-maven-api的jar包,我們在項目中調用像在本地調用一樣。代碼如下:
(2)test-maven-server-console項目的具體實現,代碼如下:
(3)我們要引用的地址,代碼如下:
說明:
dubbo:reference 的一些屬性的說明:
1)interface調用的服務接口
2)check 啓動時檢查提供者是否存在,true報錯,false忽略
3)registry 從指定註冊中心註冊獲取服務列表,在多個註冊中心時使用,值爲<dubbo:registry>的id屬性,多個註冊中心ID用逗號分隔
4)loadbalance 負載均衡策略,可選值:random,roundrobin,leastactive,分別表示:隨機,輪循,最少活躍調用
(4)項目啓動,Dubbo管理頁面,能看到消費者,如圖所示:
(5)然後訪問消費者項目,Controller層能像調用本地一樣調用服務的具體實現,如圖所示:
Dubbo提供了多種容錯方案,包括負載均衡這些,如圖所示: