初識RPC

RPC VS REST HTTP

Dubbo

Dubbo 特性：

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

	Dubbo對開發(fā)者屏蔽了底層的調(diào)用細(xì)節(jié)，在實(shí)際代碼中調(diào)用遠(yuǎn)程服務(wù)就像調(diào)用一個(gè)本地接口類一樣方便。這個(gè)功能和Fegin很類似，但是Dubbo用起來比Fegin還要簡單很多，Fegin優(yōu)勢還需要獨(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這類降級組件，而是一種 “異常重
試”

4. 服務(wù)治理

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

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

Dubbo架構(gòu)

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

1. Dubbo里的注冊中心、Provider和Counsumer三者之間都是長連接，借助于Zookeeper的高吞吐量，實(shí)現(xiàn)基于服務(wù)端的服務(wù)發(fā)現(xiàn)機(jī)制。因此Dubbo利用Zookeeper+發(fā)布訂閱模型可以很快將服務(wù)節(jié)點(diǎn)的上線下線同步到Consumer集群。如果服務(wù)提供者宕機(jī)，那么注冊中心的長連接會立馬感知到這個(gè)事件，并且立即推送通知到消費(fèi)者。
2. 在服務(wù)發(fā)現(xiàn)的做法上Dubbo和Eureka有很大的不同，Eureka使用客戶端的服務(wù)發(fā)現(xiàn)機(jī)制，因此對于服務(wù)列表的變動(dòng)響應(yīng)會稍慢，比如某臺機(jī)器下線以后，在一段時(shí)間內(nèi)可能還會陸續(xù)有服務(wù)請求發(fā)過來，當(dāng)然這些請求會收到Service Unavailable的異常，需要借助Ribbon活Hystrix實(shí)現(xiàn)重試或者降級措施。
3. 對于注冊中心宕機(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)制序列化。
   適用場景：參數(shù)數(shù)據(jù)報(bào)大小不一，發(fā)i為i提供者和服務(wù)消費(fèi)者個(gè)數(shù)相近
3. Hessian ， 基于HTTP短連接，采用Service向外暴露服務(wù)
   適用場景：參數(shù)數(shù)據(jù)報(bào)較大，服務(wù)提供者的數(shù)量遠(yuǎn)多于消費(fèi)者數(shù)量
4. HTTP，基于http表單的協(xié)議
   適用場景：可以使用瀏覽器查看，適用于需要同時(shí)給后臺應(yīng)用程序以及瀏覽器提供服務(wù)的場景
5. WebService，基于大名鼎鼎的Apache CFX，使用基于SOAP的序列化技術(shù)
   適用場景：系統(tǒng)由多種不同語言構(gòu)成的，那么這個(gè)場景就比較適合采用WebService協(xié)議，WebService通常使用在系統(tǒng)集成和跨語言調(diào)用場景中。
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ù) -> 單連接
• 連接方式 -> 長連接
• 傳輸協(xié)議 -> TCP
• 底層通信框架 -> Netty異步NIO
• 序列化方式 -> Hessian2或Dubbo序列化

Dispatcher線程派發(fā)模型

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

1. all：所有消息都派發(fā)到線程池，包括請求，響應(yīng)，連接事件，斷開事件
2. direct：所有消息都不派發(fā)到線程池，全部在IO線程上直接執(zhí)行
3. message：只有請求和響應(yīng)消息派發(fā)到線程池，其它消息均在IO線程上執(zhí)行
4. execution：只有請求消息派發(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ā)請求，接受服務(wù)提供者返回的數(shù)據(jù)等。
2. Cluser Invoker大集合
   a. FailoverClusterInvoker - 指定重試次數(shù) (默認(rèn))
   b.FailbackClusterInvoker - 后臺定時(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)輪詢算法