Dubbo 的設計思想，真優秀！

作者：叁滴水
博客：https://blog.csdn.net/qq_30285985/

本文來自作者「叁滴水」投稿，謝謝分享，也歡迎愛好技術分享的各位技術朋友向「Java技術堆疊」投稿，讓更多人看到，投稿方式：關注公眾號「Java技術堆疊」在后臺回復：投稿，

起源

如果在一個專案中有兩個service，userService和orderService，我們想要其中一個service呼叫另一個，

我們大概會有如下寫法：

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

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

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

如下圖，才是我們最終想要的方案，對于這種方案，orderService端，我們稱之為服務提供者，呼叫orderService的端，我們稱之為服務消費者，這種思想，也為dubbo的出現埋下了伏筆，

jvm的userService如何呼叫orderService呢？

在java遠程呼叫多年的沉淀，一個接著一個框架的出現，在一點點的優化這個呼叫的程序，

首先是socket呼叫，在orderService中開放socket服務，在userService中進行遠程呼叫，

• 優點：解決了單機呼叫的問題，
• 缺點：代碼復雜，不易于擴展，

這可能是最初的一個遠程呼叫解決方案，筆者不曾遇到過純socket呼叫的框架，

如何跨語言呼叫？

我們發現，在java的物件是不可以直接通過socket進行傳輸的，需要有一個序列化的程序，而且java的默認的序列化，是無法被其他語言決議的，這樣導致如果有其他語言提供的服務，是無法通過java呼叫，因此對于socket進行了升級，通過http+xml進行資訊的傳輸，這就出現了webservice，

Web Service技術， 能使得運行在不同機器上的不同應用無須借助附加的、專門的第三方軟體或硬體， 就可相互交換資料或集成，依據Web Service規范實施的應用之間， 無論它們所使用的語言、 平臺或內部協議是什么， 都可以相互交換資料，

Web Service雖然早期很多人使用，但是到現在看來，這是一種過時的框架，因為，同樣的一些資料，通過json會比xml少很多，通過json會更少的占用帶寬，如下面資料，

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

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

內部呼叫協議

http協議是應用層的一種協議，對于開放給外部系統時，是一個很好的選擇，它可以實作跨語言呼叫，如果是自己的java服務內部呼叫時，使用http協議，就有點浪費資源，

如上圖，http協議在互動之前需要進行tcp三次握手，握手成功之后進行資料傳輸，一個http互動下來，有請求頭、請求體、回應頭、回應體，這些資料，在內部呼叫時，很多無關緊要的資料，也許可以自定義協議，簡化傳輸資料，這就出現了dubbo協議，一種內部呼叫的協議，

dubbo協議追求的是資料量小，小則快，協議的設計也符合dubbo框框架的理念，適用與內部服務之間的資料互動，安全性就沒有https做的那么好,但是也不需要，畢竟dubbo協議設計的初衷就是內部使用的，

spring cloud的feign組件內部使用http協議，內部呼叫可能有一些資源的浪費，但是http協議可以實作跨語言呼叫，

RPC框架

對于一個RPC框架來說，只是能完成遠程呼叫，并不算完美，

一般開發一個服務需要多個機器進行部署，為了防止出現單點故障，對于一個較為完善的RPC框架來說，在多個機器提供同樣的一個服務的時候，需要自動做出選擇，好比上圖，userServuce在呼叫orderService的時候，需要自動識別集群資訊，并且自動選擇機器進行呼叫，

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

為了實作動態的機器添加與移除，最終，添加了一個機器的協調者，所有開放服務的機器在這個協調者中添加自己的開放服務的資訊，這個協調者中會有哪些機器開放了哪些服務，這樣看來這個協調者類似一個"通訊錄"，我們稱這個"通訊錄"為注冊中心，

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

1. 服務提供者啟動之后向注冊中心，提交自己提供服務的資訊，
2. 服務消費者，在消費時，去注冊中心查詢是否有機器提供對應的服務，例如呼叫orderService時，可以發現有192.168.1.1和192.168.1.2機器有提供對應的服務，消費者可以根據隨機、輪訓等規則選擇呼叫哪個服務，
3. 在有服務上線或者下線時，注冊中心可以對修改的資訊進行通知，

這樣一套流程下來，就完美的實作的服務的動態部署，可以任意部署服務，

注冊中心的選擇

作為協調者的注冊中心，占據著一個重要地位，這樣來看，注冊中心主要實作了臨時資料存盤的功能，可以有多種選擇資料庫、redis、zookeeper、eureka、nacos、或者自己實作，

期初dubbo框架官方推薦使用zookeeper為注冊中心，出現nacos之后，逐漸從zookeeper轉為nacos，

其中的原因有很多，有興趣的小伙伴可以微信搜索Java技術堆疊在歷史文章中搜索閱讀，

為什么zookeeper轉為nacos？結論為：zookeeper在大資料計算時做注冊中心是一個好的選擇，但是在服務呼叫時，也許資料不需要超強的一致性，nacos是目前來說很友好的一個注冊中心，他提供了CP+AP，還有可視化界面，還有配置中心等功能，功能相當完善，

springcloud與dubbo的歷史

筆者不才，在17年時，這兩個詞才進入我的視線，當時還有一個超級火的springboot，那個時候招聘，幾乎每個崗位都要求會springboot，一時間，成為了一個java開發的必備功底，

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

2018年7月份，eureka停止更新， 就目前來說eureka的功能單單作為注冊中心，已經足夠優秀了，但是對于節奏如此快的互聯網時代，停止更新，就意味著會慢慢的消失，

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

• nacos：注冊中心，
• dubbo：一個基于Java的高性能開源RPC框架，
• seata：一種高性能且易于使用的分布式事務解決方案，可用于微服務架構，

nacos是一個新推出的注冊中心，其中最亮眼的功能是提供了可視化界面，而且還附帶配置中心，瞬間dubbo就找到了家人，這些組件的出現讓dubbo又崛起了起來，而且dubbo本來擴展性就很好，可以進行協議擴展、呼叫攔截擴展、參考監聽擴展、集群擴展等等，

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

結束語

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

近期熱文推薦：

1.1,000+ 道 Java面試題及答案整理(2021最新版)

2.終于靠開源專案弄到 IntelliJ IDEA 激活碼了，真香！

3.阿里 Mock 工具正式開源，干掉市面上所有 Mock 工具！

4.Spring Cloud 2020.0.0 正式發布，全新顛覆性版本！

5.《Java開發手冊（嵩山版）》最新發布，速速下載！

覺得不錯，別忘了隨手點贊+轉發哦！

標籤：Java

上一篇：Spring Boot動態權限變更實作的整體方案

下一篇：Drools規則引擎實踐直白總結