初識(shí)RPC

RPC VS REST HTTP

Dubbo

Dubbo 特性：

1. 基于接口+動(dòng)態(tài)代理的遠(yuǎn)程方法調(diào)用

	Dubbo對(duì)開發(fā)者屏蔽了底層的調(diào)用細(xì)節(jié)，在實(shí)際代碼中調(diào)用遠(yuǎn)程服務(wù)就像調(diào)用一個(gè)本地接口類一樣方便。這個(gè)功能和Fegin很類似，但是Dubbo用起來比Fegin還要簡(jiǎn)單很多，Fegin優(yōu)勢(shì)還需要獨(dú)立聲明一個(gè)接口，而Dubbo真的就是拿到公共接口類后直接就能用。

2. 負(fù)載均衡

Dubbo內(nèi)置多種負(fù)載均衡策略，只能感知下游節(jié)點(diǎn)健康狀況，提高系統(tǒng)吞吐量，這部分功能和Ribbon十分接近，
但是Dubbo的負(fù)載均衡策略不如Ribbon的多，而且Dubbo的負(fù)載均衡能力只能供自己享用，而Ribbon可以賦能
給Spring Cloud里的各個(gè)組件。

3. 集群容錯(cuò)

Dubbo提供了一個(gè)Cluster組件專門用來做集群容錯(cuò)，它其實(shí)并不是Hystrix這類降級(jí)組件，而是一種 “異常重
試”

4. 服務(wù)治理

支持多種注冊(cè)中心服務(wù)，服務(wù)實(shí)力上下線實(shí)時(shí)感知。就是服務(wù)注冊(cè)、服務(wù)發(fā)現(xiàn)、服務(wù)下線之類的流程，這些功能
和Eureka里面的概念是一模一樣的，只是實(shí)現(xiàn)方式卻大有不同。比如Dubbo在服務(wù)下線后會(huì)主動(dòng)將可用服務(wù)列表
下發(fā)到各個(gè)服務(wù)節(jié)點(diǎn)，送貨上門服務(wù)周到，而Eureka每次都等著服務(wù)節(jié)點(diǎn)自己上注冊(cè)中心來拿數(shù)據(jù)。

Dubbo 的技能點(diǎn)比較專一，全點(diǎn)在了服務(wù)治理體系，但就服務(wù)治理來看確實(shí)比Eureka細(xì)致一些。

Dubbo架構(gòu)

Dubbo和Eureka中服務(wù)發(fā)現(xiàn)的不同

1. Dubbo里的注冊(cè)中心、Provider和Counsumer三者之間都是長(zhǎng)連接，借助于Zookeeper的高吞吐量，實(shí)現(xiàn)基于服務(wù)端的服務(wù)發(fā)現(xiàn)機(jī)制。因此Dubbo利用Zookeeper+發(fā)布訂閱模型可以很快將服務(wù)節(jié)點(diǎn)的上線下線同步到Consumer集群。如果服務(wù)提供者宕機(jī)，那么注冊(cè)中心的長(zhǎng)連接會(huì)立馬感知到這個(gè)事件，并且立即推送通知到消費(fèi)者。
2. 在服務(wù)發(fā)現(xiàn)的做法上Dubbo和Eureka有很大的不同，Eureka使用客戶端的服務(wù)發(fā)現(xiàn)機(jī)制，因此對(duì)于服務(wù)列表的變動(dòng)響應(yīng)會(huì)稍慢，比如某臺(tái)機(jī)器下線以后，在一段時(shí)間內(nèi)可能還會(huì)陸續(xù)有服務(wù)請(qǐng)求發(fā)過來，當(dāng)然這些請(qǐng)求會(huì)收到Service Unavailable的異常，需要借助Ribbon活Hystrix實(shí)現(xiàn)重試或者降級(jí)措施。
3. 對(duì)于注冊(cè)中心宕機(jī)的情況，Dubbo和Eureka的處理方式相同，這兩個(gè)框架的服務(wù)節(jié)點(diǎn)都在本地緩存了服務(wù)提供者的列表，因此仍然可以發(fā)起調(diào)用，但服務(wù)提供者列表無法被更新，因此可能導(dǎo)致本地緩存的服務(wù)狀態(tài)與實(shí)際情況有別。

Dubbo有哪些底層協(xié)議

1. Dubbo本尊，官方推薦；
2. RMI ， JDK中“java.rmi”包下的實(shí)現(xiàn)，底層采用阻塞的短連接 + JDK中標(biāo)準(zhǔn)的二進(jìn)制序列化。
   適用場(chǎng)景：參數(shù)數(shù)據(jù)報(bào)大小不一，發(fā)i為i提供者和服務(wù)消費(fèi)者個(gè)數(shù)相近
3. Hessian ， 基于HTTP短連接，采用Service向外暴露服務(wù)
   適用場(chǎng)景：參數(shù)數(shù)據(jù)報(bào)較大，服務(wù)提供者的數(shù)量遠(yuǎn)多于消費(fèi)者數(shù)量
4. HTTP，基于http表單的協(xié)議
   適用場(chǎng)景：可以使用瀏覽器查看，適用于需要同時(shí)給后臺(tái)應(yīng)用程序以及瀏覽器提供服務(wù)的場(chǎng)景
5. WebService，基于大名鼎鼎的Apache CFX，使用基于SOAP的序列化技術(shù)
   適用場(chǎng)景：系統(tǒng)由多種不同語言構(gòu)成的，那么這個(gè)場(chǎng)景就比較適合采用WebService協(xié)議，WebService通常使用在系統(tǒng)集成和跨語言調(diào)用場(chǎng)景中。
6. REST，基于標(biāo)準(zhǔn)的Java REST API 實(shí)現(xiàn)的REST風(fēng)格調(diào)用， Dubbo花了大力氣在這部分的實(shí)現(xiàn)上面， 他的使用風(fēng)格和原生Spring MVC類似。

Dubbo協(xié)議的特性和性能

• 連接個(gè)數(shù) -> 單連接
• 連接方式 -> 長(zhǎng)連接
• 傳輸協(xié)議 -> TCP
• 底層通信框架 -> Netty異步NIO
• 序列化方式 -> Hessian2或Dubbo序列化

Dispatcher線程派發(fā)模型

Dispatcher用來創(chuàng)建具有線程派發(fā)能力的ChannelHandler，將來訪Request派發(fā)到線程池或者當(dāng)前IO線程。我們可以給Dispatcher配置5種派發(fā)策略：

1. all：所有消息都派發(fā)到線程池，包括請(qǐng)求，響應(yīng)，連接事件，斷開事件
2. direct：所有消息都不派發(fā)到線程池，全部在IO線程上直接執(zhí)行
3. message：只有請(qǐng)求和響應(yīng)消息派發(fā)到線程池，其它消息均在IO線程上執(zhí)行
4. execution：只有請(qǐng)求消息派發(fā)到線程池，不含響應(yīng)。其它消息均在IO線程上執(zhí)行
5. connection：在IO線程上，將連接斷開事件放入隊(duì)列，有序逐個(gè)執(zhí)行，其它消息派發(fā)到線程池

Dubbo的Cluster和Clister Invoker組件：

1. 集群模塊是服務(wù)提供者和服務(wù)消費(fèi)者的中間層，為服務(wù)消費(fèi)者屏蔽了服務(wù)提供者的情況，這樣服務(wù)消費(fèi)者就可以專心處理遠(yuǎn)程調(diào)用相關(guān)事宜。比如發(fā)請(qǐng)求，接受服務(wù)提供者返回的數(shù)據(jù)等。
2. Cluser Invoker大集合
   a. FailoverClusterInvoker - 指定重試次數(shù) (默認(rèn))
   b.FailbackClusterInvoker - 后臺(tái)定時(shí)重試
   c.FailfastClusterInvoker - 早死早超生
   d.FailsafeClusterInvoker - 睜一只眼閉一只眼
   e.ForkingClusterInvoker - 百萬雄師過大江

Dubbo中的負(fù)載均衡

1. RandomLoadBalance 基于權(quán)重算法的負(fù)載均衡策略
2. LeastActiveLoadBalance 基于最少活躍調(diào)用數(shù)算法
3. ConsistentLoadBalance 基于Hash一致性
4. RoundRobinLoadBalance 基于加權(quán)輪詢算法