本篇文章是Dubbo源碼分析的第一講，主要介紹Dubbo源碼中重要的組件。還是小編的風格,以提問的方式講解。各位看官可以自行跳躍,找到自己想要的部分。爲什麼RPC要單獨一節說呢? 因爲感覺現在網絡上關於RPC的描述都是有問題的。既然我們是要對Dubbo做全面的剖析，而Dubbo又是一款RPC框架，那麼我們必須要對RPC有一個正確的認識。在這裏小編談談我的理解!

什麼是RPC?

RPC到底是風格還是協議? 這個問題不好回答，小編把兩種的論點和論據都描述出來，並給出自己的理解，

但是最終由你來判斷! 也可以在下面提出意見,我們共同探討交流。

上圖示百度百科裏面的描述,RPC（Remote Procedure Call）—遠程過程調用，很多網上文章都是說rpc是一種協議

那麼RPC到底是一種協議嗎? 觀點一(小編的觀點) 觀點二(網絡上大多數描述)

觀點一:

RPC 風格對應的是 Restful風格

出發點: RPC 的含義來看(遠程過程調用)

RPC全稱遠程過程調用,認爲只要實現遠程調用即可，實現的方式可以是HTTP基於應用層的協議，也可以是Socket基於傳輸層協議

因爲Socket編程是比較複雜的，所以Dubbo在Socket編程方面是用的Netty來實現。同樣也可以用WebService來實現，所以我認爲RPC只是一種風格。

舉一個例子: Google的grpc框架，底層就是基於Http2.0 來實現

觀點二

認爲RPC是一個協議的是這樣理解的

出發點: OSI網絡模型

HTTP基於應用層

RPC只是基於傳輸層

看了這兩個觀點相信你應該也有自己的判斷,再後面的章節,小編會講到Dubbo到底是如何用Netty和Http來實現遠程調用的。

這點先不要着急。先對RPC有一個自己的認識。

Dubbo-RPC和傳統服務的區別是什麼?

傳統: 調用遠程服務,需要開發者①先創建Http客戶端連接遠程服務器，②封裝請求參數 ③收到處理結果

Dubbo-RPC:

因爲Dubbo是配置Spring來使用的，所以只要配置好了，遠程服務的調用，就可以像本地服務那樣調用。

就像本地服務一樣調用。直接從IOC容器拿出來，就可以用。

看了上面的例子，應該都瞭解了。那麼我們在分析分析那麼的優劣點。

Dubbo分析

因爲Dubbo默認是基於Netty來實現，基於傳輸層協議，所以性能比傳統方式自然強了很多。單單從這點看Dubbo和Http沒有可比性，碾壓的優勢。但是Dubbo配置的比較多，好再是隻要配置一次就可以了。不過唯一不好的是，對客戶端和服務端都有要求要求都要使用Dubbo來通訊，而且都是Java服務(現在也可以通過中間件，來支持其他語言)。

傳統SpringMVC分析

傳統方式理論上在Http1.x的時代，每一次方法的調用，都要重新創建一次Http客戶端，一次http請求(三握四揮)不過基於http的服務，是沒有任何約束的，沒有語言的約束。這也是爲什麼小公司都選擇傳統方式的原因。不用Dubbo還有一個重要的原因是SpringBoot和SpringCloud都非常好用簡單，Spring全家桶提供了一系列的解決方案，從,集羣性能,容錯,負載,監控都有方便的解決方案（想了解SpringBoot和Spring的小夥伴可以看小編其他文章）。

附上SpringBoot博客地址: https://blog.springlearn.cn/categories/Spring-Boot/