讀懂 Dubbo 的設計思想，就這篇了！

如果在一個項目中有兩個service。userService和orderService。我們想要其中一個service調(diào)用另一個。

我們大概會有如下寫法：

public class userService{
 
    private orderService orderService;

    public User getOrder(Long orderId){
        return orderService.getOrder(orderId);
    }
}

隨著業(yè)務的逐漸復雜，在開發(fā)中肯定會有業(yè)務拆分。初步是通過maven進行模塊的拆分。

不管maven如何拆分，都始終是在一個jvm中運行， 這樣只是在代碼開發(fā)時會清楚方便一點。但是，某一個service在有較大壓力的情況下，沒有辦法單單對此service做出調(diào)整。最終，我們是想要userService和orderService在不同的jvm中運行，如果orderService訪問較多，我們可以只對它進行擴容。

如下圖，才是我們最終想要的方案，對于這種方案，orderService端，我們稱之為服務提供者，調(diào)用orderService的端，我們稱之為服務消費者。這種思想，也為dubbo的出現(xiàn)埋下了伏筆。

jvm的userService如何調(diào)用orderService呢？

在java遠程調(diào)用多年的沉淀，一個接著一個框架的出現(xiàn)，在一點點的優(yōu)化這個調(diào)用的過程。

首先是socket調(diào)用。在orderService中開放socket服務，在userService中進行遠程調(diào)用。

• 優(yōu)點：解決了單機調(diào)用的問題。

• 缺點：代碼復雜，不易于擴展。

這可能是最初的一個遠程調(diào)用解決方案，筆者不曾遇到過純socket調(diào)用的框架。

如何跨語言調(diào)用？

我們發(fā)現(xiàn)，在java的對象是不可以直接通過socket進行傳輸?shù)?，需要有一個序列化的過程。而且java的默認的序列化，是無法被其他語言解析的。這樣導致如果有其他語言提供的服務，是無法通過java調(diào)用。因此對于socket進行了升級，通過http+xml進行信息的傳輸。這就出現(xiàn)了webservice。

Web Service技術(shù)， 能使得運行在不同機器上的不同應用無須借助附加的、專門的第三方軟件或硬件， 就可相互交換數(shù)據(jù)或集成。依據(jù)Web Service規(guī)范實施的應用之間， 無論它們所使用的語言、 平臺或內(nèi)部協(xié)議是什么， 都可以相互交換數(shù)據(jù)。

Web Service雖然早期很多人使用，但是到現(xiàn)在看來，這是一種過時的框架。因為，同樣的一些數(shù)據(jù)，通過json會比xml少很多。通過json會更少的占用帶寬。如下面數(shù)據(jù)。

{
    "id": 12312,
    "userName": "12312"
}

<id type="number">12312</id>
<userName type="string">12312</userName>

內(nèi)部調(diào)用協(xié)議

http協(xié)議是應用層的一種協(xié)議，對于開放給外部系統(tǒng)時，是一個很好的選擇，它可以實現(xiàn)跨語言調(diào)用。如果是自己的java服務內(nèi)部調(diào)用時，使用http協(xié)議，就有點浪費資源。

如上圖，http協(xié)議在交互之前需要進行tcp三次握手，握手成功之后進行數(shù)據(jù)傳輸。一個http交互下來，有請求頭、請求體、響應頭、響應體。這些數(shù)據(jù)，在內(nèi)部調(diào)用時，很多無關(guān)緊要的數(shù)據(jù)。也許可以自定義協(xié)議，簡化傳輸數(shù)據(jù)。這就出現(xiàn)了dubbo協(xié)議，一種內(nèi)部調(diào)用的協(xié)議。另外，關(guān)注公號“終碼一生”，回復關(guān)鍵詞“資料”，獲取視頻教程和最新的面試資料！

dubbo協(xié)議追求的是數(shù)據(jù)量小，小則快，協(xié)議的設計也符合dubbo框框架的理念，適用與內(nèi)部服務之間的數(shù)據(jù)交互。安全性就沒有https做的那么好,但是也不需要，畢竟dubbo協(xié)議設計的初衷就是內(nèi)部使用的。

spring cloud的feign組件內(nèi)部使用http協(xié)議，內(nèi)部調(diào)用可能有一些資源的浪費，但是http協(xié)議可以實現(xiàn)跨語言調(diào)用。

對于一個RPC框架來說，只是能完成遠程調(diào)用，并不算完美。

一般開發(fā)一個服務需要多個機器進行部署，為了防止出現(xiàn)單點故障。對于一個較為完善的RPC框架來說，在多個機器提供同樣的一個服務的時候，需要自動做出選擇。好比上圖，userServuce在調(diào)用orderService的時候，需要自動識別集群信息，并且自動選擇機器進行調(diào)用。

目前，orderService只有一個服務，三臺機器，也許可以在userServuce中配置三個ip，然后自行編寫路由規(guī)則即可。但是隨著業(yè)務的復雜，機器的變化，也許，我們起初無法得知機器的ip信息。

為了實現(xiàn)動態(tài)的機器添加與移除。最終，添加了一個機器的協(xié)調(diào)者，所有開放服務的機器在這個協(xié)調(diào)者中添加自己的開放服務的信息，這個協(xié)調(diào)者中會有哪些機器開放了哪些服務。這樣看來這個協(xié)調(diào)者類似一個"通訊錄"。我們稱這個"通訊錄"為注冊中心。

這樣一個較為完善的RPC框架，就有了雛形。

1. 服務提供者啟動之后向注冊中心，提交自己提供服務的信息。

2. 服務消費者，在消費時，去注冊中心查詢是否有機器提供對應的服務。例如調(diào)用orderService時，可以發(fā)現(xiàn)有192.168.1.1和192.168.1.2機器有提供對應的服務。消費者可以根據(jù)隨機、輪訓等規(guī)則選擇調(diào)用哪個服務。

3. 在有服務上線或者下線時，注冊中心可以對修改的信息進行通知。

這樣一套流程下來，就完美的實現(xiàn)的服務的動態(tài)部署，可以任意部署服務。

注冊中心的選擇

作為協(xié)調(diào)者的注冊中心，占據(jù)著一個重要地位。這樣來看，注冊中心主要實現(xiàn)了臨時數(shù)據(jù)存儲的功能?？梢杂卸喾N選擇數(shù)據(jù)庫、redis、zookeeper、eureka、nacos、或者自己實現(xiàn)。

期初dubbo框架官方推薦使用zookeeper為注冊中心，出現(xiàn)nacos之后，逐漸從zookeeper轉(zhuǎn)為nacos。

為什么zookeeper轉(zhuǎn)為nacos？

結(jié)論為：zookeeper在大數(shù)據(jù)計算時做注冊中心是一個好的選擇，但是在服務調(diào)用時，也許數(shù)據(jù)不需要超強的一致性。nacos是目前來說很友好的一個注冊中心，他提供了CP+AP。還有可視化界面，還有配置中心等功能。功能相當完善。

springcloud與dubbo的歷史

筆者不才，在17年時，這兩個詞才進入我的視線。當時還有一個超級火的springboot。那個時候招聘，幾乎每個崗位都要求會springboot。

由于springboot在大大開發(fā)了開發(fā)的速度，而且springcloud的各個組件都比較完善，feign、網(wǎng)關(guān)、配置中心、熔斷等等。spring、springcloud和springboot明顯是一家人。這讓一個孤身的dubbo有點不好立足，一些公司從dubbo框架轉(zhuǎn)為springcloud全家桶。

2018年7月份，eureka停止更新。就目前來說eureka的功能單單作為注冊中心，已經(jīng)足夠優(yōu)秀了。但是對于節(jié)奏如此快的互聯(lián)網(wǎng)時代，停止更新，就意味著會慢慢的消失。

2019 年 7 月 24 日晚，Spring Cloud 官方發(fā)布公告Spring Cloud Alibaba 即將畢業(yè)。提供了很多組件，對于大部分開發(fā)者而言，nacos、dubbo、seata應該是較為常用的組件。

• nacos：注冊中心。

• dubbo：一個基于Java的高性能開源RPC框架。

• seata：一種高性能且易于使用的分布式事務解決方案，可用于微服務架構(gòu)。

nacos是一個新推出的注冊中心，其中最亮眼的功能是提供了可視化界面，而且還附帶配置中心。瞬間dubbo就找到了家人。這些組件的出現(xiàn)讓dubbo又崛起了起來。而且dubbo本來擴展性就很好。可以進行協(xié)議擴展、調(diào)用攔截擴展、引用監(jiān)聽擴展、集群擴展等等。

另外dubbo3.0主力使用 Triple 協(xié)議。完整兼容 gRPC over HTTP/2。推薦使用 protobuf 作為默認序列化，在性能和跨語言上的效果都會更好。

就目前來看，dubbo框架是一個目前位置非常優(yōu)秀的RPC框架， 一個必須要學的一個框架。也許以后它會更加優(yōu)秀，也許會落寞。但是其設計思想，非常值得開發(fā)者去學習。

作者：叁滴水

博客：https://blog.csdn.net/qq_30285985/