十萬個爲何之爲何你們都說dubbo

Dubbo是什麼?

使用背景

dubbo爲何這麼流行, 爲何你們都這麼喜歡用dubbo;

經過了解分佈式開發瞭解到, 爲適應訪問量暴增,業務拆分後, 子應用部署在多臺服務器上,而多臺服務器經過能夠經過dubbo同時向外部提供服務,解決單臺服務器處理能力和存儲空間上限的問題;

也有這樣的理解,按咱們的技術發展趨勢來看:

單一應用架構

當網站流量很小時，只需一個應用，將全部功能都部署在一塊兒，以減小部署節點和成本。此時，用於簡化增刪改查工做量的數據訪問框架(ORM) 是關鍵。

垂直應用架構

當訪問量逐漸增大，單一應用增長機器帶來的加速度愈來愈小，將應用拆成互不相干的幾個應用，以提高效率。此時，用於加速前端頁面開發的Web框架(MVC) 是關鍵。

分佈式服務架構

當垂直應用愈來愈多，應用之間交互不可避免，將核心業務抽取出來，做爲獨立的服務，逐漸造成穩定的服務中心，使前端應用能更快速的響應多變的市場需求。

此時，用於提升業務複用及整合的分佈式服務框架(RPC) 是關鍵。

流動計算架構

當服務愈來愈多，容量的評估，小服務資源的浪費等問題逐漸顯現，此時需增長一個調度中心基於訪問壓力實時管理集羣容量，提升集羣利用率。

此時，用於提升機器利用率的資源調度和治理中心(SOA) 是關鍵。  

dubbo應運而生,其致力於提供高性能和透明化的RPC遠程服務調用方案，以及SOA服務治理方案。

Dubbo定義

Dubbo是一個分佈式服務框架，致力於提供高性能和透明化的RPC遠程服務調用方案，以及SOA服務治理方案。簡單的說，dubbo就是個服務框架，若是沒有分佈式的需求，實際上是不須要用的，只有在分佈式的時候，纔有dubbo這樣的分佈式服務框架的需求，而且本質上是個服務調用的東東，說白了就是個遠程服務調用的分佈式框架（告別Web Service模式中的WSdl，以服務者與消費者的方式在dubbo上註冊）
其核心部分包含:
1. 遠程通信: 提供對多種基於長鏈接的NIO框架抽象封裝，包括多種線程模型，序列化，以及「請求-響應」模式的信息交換方式。
2. 集羣容錯: 提供基於接口方法的透明遠程過程調用，包括多協議支持，以及軟負載均衡，失敗容錯，地址路由，動態配置等集羣支持。
3. 自動發現: 基於註冊中心目錄服務，使服務消費方能動態的查找服務提供方，使地址透明，使服務提供方能夠平滑增長或減小機器。

Dubbo能作什麼？

1. 透明化的遠程方法調用，就像調用本地方法同樣調用遠程方法，只需簡單配置，沒有任何API侵入。      
2. 軟負載均衡及容錯機制，可在內網替代F5等硬件負載均衡器，下降成本，減小單點。
3. 服務自動註冊與發現，再也不須要寫死服務提供方地址，註冊中心基於接口名查詢服務提供者的IP地址，而且可以平滑添加或刪除服務提供者。

Dubbo採用全spring配置方式，透明化接入應用，對應用沒有任何API侵入，只需用Spring加載Dubbo的配置便可，Dubbo基於Spring的Schema擴展進行加載。

Dubbo的架構

節點角色說明：

       Provider: 暴露服務的服務提供方。

       Consumer: 調用遠程服務的服務消費方。

       Registry: 服務註冊與發現的註冊中心。

       Monitor: 統計服務的調用次調和調用時間的監控中心。

       Container: 服務運行容器。

調用關係說明：

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

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

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

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

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

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

 

Dubbo的負載均衡與nginx的負載均衡

我看到有人居然拿二者作對比, 這是徹底不是一個層次的;

dubbo具有server註冊,發現,路由,負載均衡的功能

注: dubbo負載均衡適用於服務層面,而nginx適用於http請求層面;

通俗的講:

nginx是橫在用戶的瀏覽器和自家的服務器之間。
dubbo是橫在自家的服務器和自家的服務器之間。

Dubbo與SpringCloud的區別

雖然二者均屬於微服務架構, 但仍是有實質區別的,Dubbo只是實現了服務治理，而Spring Cloud子項目分別覆蓋了微服務架構下的衆多部件，而服務治理只是其中的一個方面。Dubbo提供了各類Filter，對於上述中「無」的要素，能夠經過擴展Filter來完善。

從核心要素來看，Spring Cloud 更勝一籌，在開發過程當中只要整合Spring Cloud的子項目就能夠順利的完成各類組件的融合，而Dubbo缺須要經過實現各類Filter來作定製，開發成本以及技術難度略高。(通俗的講springCloud是全家桶,dubbo則是核心功能外,其他需自行組合)

來源:

Dubbo出生於阿里系，是阿里巴巴服務化治理的核心框架，並被普遍應用於中國各互聯網公司；只須要經過spring配置的方式便可完成服務化，對於應用無入侵。設計的目的仍是服務於自身的業務爲主。雖然阿里內部緣由dubbo曾經一度暫停維護版本，可是框架自己的成熟度以及文檔的完善程度，徹底能知足各大互聯網公司的業務需求。若是咱們須要使用配置中心、分佈式跟蹤這些內容都須要本身去集成，這樣無形中增長了使用 Dubbo 的難度。

Spring Cloud 是大名鼎鼎的 Spring 家族的產品， 專一於企業級開源框架的研發。 Spring Cloud 自從發展到如今，仍然在不斷的高速發展，幾乎考慮了服務治理的方方面面，開發起來很是的便利和簡單。

內容摘抄至: https://baijiahao.baidu.com/s?id=1600174787011483381&wfr=spider&for=pc