深入淺出dubbo源碼系列--走進Dubbo

什麼是RPC

瞭解dubbo之前，我們先來看下啥是RPC框架，他到底是用來幹嘛的呢？

在這個微服務盛行的大環境下，很多人應該都有使用過RPC框架的經驗；大白話來說：RPC框架最大的作用
就是對於client看來說，就像調用本地service方法一樣調用遠程的服務。他是服務化最最基本的基礎組件。

Rpc框架的底層架構來說，它大概有主要有代理模型和服務註冊發現模型；當然也有最近比較火的service mesh模型。

代理模型：比較典型的就是我們的httpclient，gRpc，Thirft等產品；路由信息都是集中配置在proxy節點的，存在單點故障的風險。

服務發現模型： 本文所述的Dubbo，spring cloud等產品，也是目前主流的RPC框架；路由信息都是註冊中心集中配置管理，但會同步到客戶端，最終是由客戶端自行路由
下面兩個圖說明下兩者的異同點：

我覺得這幾種架構各有優缺點，得看實際的業務場景纔可以決定用哪種架構比較合適吧； 下面單介紹下Dubbo的相關概念。

什麼是Dubbo

Dubbo是阿里巴巴公司開源的一個高性能優秀的分佈式服務框架，致力於提供高性能和透明化的RPC遠程服務調用方案，以及SOA服務治理方案。

Dubbo是基於java的RPC框架，與整個java的生態比較契合。

Dubbo整體架構設計介紹

整體架構圖：

說明：
服務容器負責啓動，加載，運行服務提供者。
服務提供者在啓動時，向註冊中心註冊自己提供的服務。
服務消費者在啓動時，向註冊中心訂閱自己所需的服務。
註冊中心返回服務提供者地址列表給消費者，如果有變更，註冊中心將基於長連接推送變更數據給消費者。
服務消費者，從提供者地址列表中，基於軟負載均衡算法，選一臺提供者進行調用，如果調用失敗，再選另一臺調用。
服務消費者和提供者，在內存中累計調用次數和調用時間，定時每分鐘發送一次統計數據到監控中心。

核心流程圖：
後面主要圍繞官方的一張整體設計圖給大家介紹幾個核心的流程以及相關的實現原理。

1.從上面的圖中可以看到整體架構，層次還是比較清晰；每個層次都是單向依賴，不會出現循環依賴的問題。
2.上圖左邊藍色部分主要描述了服務消費者的啓動流程，右邊描述了服務提供者的啓動流程。
3.從上往下看分了9層，從左邊看按功能分了三類，分表是面向用戶的biz，RPC核心層和負責傳輸的remotingcneg。從右邊按用戶分成了2類，一類是面向用戶的API，另外一類是面向擴展提供者的SPI.
4.藍色的虛線表示服務提供者的註冊和消費者的訂閱的過程；紅色表示一次服務的調用過程。