Dubbo（一） 開始認識Dubbo，分佈式服務框架

引言：

之前的車馬很慢，一輩子只夠愛一我的
之前的網站人不多，一個單應用服務着一我的
————————————————————
如今，動不動就談什麼高併發，千萬級訪問。單應用？BOOM！分分鐘爆炸。因而，技術隨着業務的需求誕生了新的產物。

框架演變：

• 單一應用架構 :全部的功能部署在一個應用中。

• 垂直應用架構 ：將應用拆成互不相干的幾個應用，以提高效率。

• 分佈式服務架構 ：當垂直應用愈來愈多，應用之間交互不可避免，此時，用於提升業務複用及整合的 分佈式服務框架(RPC) 是關鍵。
  

OK！到此爲止，咱們今天的主要目標就是分佈式服務架構之Dubbo。

在瞭解Dubbo以前，咱們先了解兩個概念：

什麼是服務框架？
服務框架就是提供服務的，服務框架是基於業務對應SaaS分發模式的服務進行整合，以產生新的應用。服務框架中，與業務相關，但與業務功能的整合無關的組件之外部服務形式引入（也就是說把一些業務分離出來，變成一種服務，供其餘人調用該服務）。

什麼是RPC？
RPC全拼是（Remote Procedure CallProtocol）遠程過程調用協議，它是一種經過網絡從遠程計算機程序上請求服務，而不須要了解底層網絡技術的協議。RPC使得開發包括網絡分佈式多程序在內的應用程序更加容易。（理解：遠程調用協議，爲Dubbo實現遠程接口調用作支持）

Dubbo是什麼

Dubbo，阿里巴巴的開源框架-分佈式框架，致力於提供高性能和透明化的RPC遠程服務調用方案，以及SOA服務治理方案。
簡單的說，就是把一個應用分紅幾份，他負責各份應用之間的通訊以及管理。
難道你不知道springCloud嗎？
emmm！sprigcloud，I know，spring家族的一大分佈式神器，在近兩年隨着微服務的風靡，他也是一大潮流。可是論目前使用度，springcloud還遠遠不如老牌的dubbo，並且最近阿里從新開始瘋狂維護Dubbo，誰知道他到後面的發展不會比spring好呢？在都是找工做的壓力下，仍是會點dubbo沒毛病吧。

既然你提到了springCloud，那咱們也順便來對比下二者之間的區別吧。

Name	Dubbo	Spring-cloud
OpenSource	Yes	Yes
Source	alibaba,目前已貢獻給apache	Spring
Reputation	國內知名度高	國內知名度不高，但依託Sping強大技術體系
文檔	完善	完善
社區活躍度	更新慢	比較活躍
架構性	只提供服務治理	提供微服務架構的方方面面功能
分佈式配置	可使用淘寶的diamond、百度的disconf來實現分佈式配置管理	pring Cloud中的Config組件除了提供配置管理以外，因爲其存儲可使用git，所以它自然的實現了配置內容的版本管理，能夠完美的與應用版本管理整合起來
服務跟蹤	可使用京東開源的Hydra
批量任務	可使用噹噹開源的Elastic-Job
通信	主RPC，Dubbox支持REST	REST
使用Dubbo的RPC來實現服務間調用的一些痛點	服務提供方與調用方接口依賴方式太強：咱們爲每一個微服務定義了各自的service抽象接口，並經過持續集成發佈到私有倉庫中，調用方應用對微服務提供的抽象接口存在強依賴關係，所以不論開發、測試、集成環境都須要嚴格的管理版本依賴，纔不會出現服務方與調用方的不一致致使應用沒法編譯成功等一系列問題，以及這也會直接影響本地開發的環境要求，每每一個依賴不少服務的上層應用，天天都要更新不少代碼並install以後才能進行後續的開發。若沒有嚴格的版本管理制度或開發一些自動化工具，這樣的依賴關係會成爲開發團隊的一大噩夢。而REST接口相比RPC更爲輕量化，服務提供方和調用方的依賴只是依靠一紙契約，不存在代碼級別的強依賴，固然REST接口也有痛點，由於接口定義太輕，很容易致使定義文檔與實際實現不一致致使服務集成時的問題，可是該問題很好解決，只須要經過每一個服務整合swagger，讓每一個服務的代碼與文檔一體化，就能解決。因此在分佈式環境下，REST方式的服務依賴要比RPC方式的依賴更爲靈活。
	服務對平臺敏感，難以簡單複用：一般咱們在提供對外服務時，都會以REST的方式提供出去，這樣能夠實現跨平臺的特色，任何一個語言的調用方均可以根據接口定義來實現。那麼在Dubbo中咱們要提供REST接口時，不得不實現一層代理，用來將RPC接口轉換成REST接口進行對外發布。若咱們每一個服務自己就以REST接口方式存在，當要對外提供服務時，主要在API網關中配置映射關係和權限控制就可實現服務的複用了
一、Dubbo實現了服務治理的基礎，可是要完成一個完備的微服務架構，還須要在各環節去擴展和完善以保證集羣的健康，以減輕開發、測試以及運維各個環節上增長出來的壓力，這樣才能讓各環節人員真正的專一於業務邏輯。                     二、而Spring Cloud依然發揚了Spring Source整合一切的做風，以標準化的姿態將一些微服務架構的成熟產品與框架揉爲一體，並繼承了Spring Boot簡單配置、快速開發、輕鬆部署的特色，讓本來複雜的架構工做變得相對容易上手一些          三、因此，若是選擇Dubbo請務必在各個環節作好整套解決方案的準備，否則極可能隨着服務數量的增加，整個團隊都將疲於應付各類架構上不足引發的困難。而若是選擇Spring Cloud，相對來講每一個環節都已經有了對應的組件支持，可能有些也不必定能知足你全部的需求，可是其活躍的社區與高速的迭代進度也會是你能夠依靠的強大後盾。

上圖看得出，dubbo就是對應用作了管理，而springcloud繼承了spring一如既往的特色，整合萬物。一句話，沒有我不整合，只有你用不到的。 固然啦，dubbo那些沒有的功能就不能實現嗎？NO！只是要本身結合第三方去實現而已。
因此說一句公道話，如今springcloud更具技術表明性，在大部分公司用springcloud的狀況下，須要什麼也能簡單的實現，而dubbo，還得看阿里團隊之後的努力。固然！技術流弊的，這些沒什麼大不了。

Dubbo通訊協議

Dubbo這麼強大的一個框架，通訊協議也確定十分強大，他支持多種協議，例如：

• Dubbo協議【默認協議】
• Hessian協議
• HTTP協議
• RMI協議
• WebService協議
• Thrift協議
• Memcached協議
• Redis協議

在通訊過程當中，不一樣的服務等級通常對應着不一樣的服務質量，那麼選擇合適的協議即是一件很是重要的事情。你能夠根據你應用的建立來選擇。例如，使用RMI協議，通常會受到防火牆的限制，因此對於外部與內部進行通訊的場景，就不要使用RMI協議，而是基於HTTP協議或者Hessian協議。
關於協議的選擇，在後面的文章會有講到，或者參考文章→dubbo多協議選擇

Dubbo幾大核心要點

1. 服務定義：消費者消費服務者提供的服務。

2. 服務註冊：消費者和服務者都須要公開本身的身份，方便被尋找。經常使用zookeeper註冊。

3. 服務監控：對服務狀態實時監控，方便改進質量。

4. 遠程通訊與信息交換：服務者和消費者之間的交流，經過通訊協議。

5. 服務調用：消費者從zookeeper上找對服務者，而後享受他的服務。

6. 註冊/註銷服務：服務者上班，和下班的狀態。

7. 服務訂閱/取消：消費者按摩和不按摩的狀態。

長話短說

那麼說了這麼多，親們越看越模糊，感受博主像個傻逼同樣BB了半天，卻根本沒讓咱們瞭解Dubbo，怎麼辦？
OK！
簡單地說，例如
第一步：Dubbo把項目切割開來變成兩個，而後項目一（action）留一個接口，告訴zookeeper我是消費者，項目二（service）實現那個接口，告訴zookeeper我是消費者。
第二部：當action被調用走到接口的時候，會去zookeeper詢問，個人消費者在哪裏啊，而後zookeeper告訴他service的IP地址和端口，找到接口的Impl實現類走完，而後返回給action結果。

沒了~入門就這麼簡單。

至於zookeeper在文中反覆提到，他又是什麼，在這裏透個小底，他是標配的小神器。除了普通的註冊以外，他還能提供負載均衡等強大功能，並且添加和移除集羣節點很是平滑哦！