實操：Java大牛帶你梳理dubbo的那些底層原理，再也不怕被坑了

今日分享開始啦，請大家多多指教~

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

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

我們大概會有如下寫法：

隨著業務的逐漸複雜，在開發中肯定會有業務拆分。初步是透過maven進行模組的拆分。

如下圖，才是我們最終想要的方案，對於這種方案，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會更少的佔用頻寬。如下面資料。

內部呼叫協議

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框架，就有了雛形。

服務提供者啟動之後向註冊中心，提交自己提供服務的資訊。

服務消費者，在消費時，去註冊中心查詢是否有機器提供對應的服務。例如呼叫orderService時，可以發現有192。168。1。1和192。168。1。2機器有提供對應的服務。消費者可以根據隨機、輪訓等規則選擇呼叫哪個服務。

在有服務上線或者下線時，註冊中心可以對修改的資訊進行通知。

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

註冊中心的選擇

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

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

為什麼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作為預設序列化，在效能和跨語言上的效果都會更好。

結束語

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

今日份分享已結束，請大家多多包涵和指點！