更新時(shí)間:2020年11月04日18時(shí)31分 來源:傳智播客 瀏覽次數(shù):
dubbo(默認(rèn)):單一長連接和NIO異步通訊,適合大并發(fā)小數(shù)據(jù)量的服務(wù)調(diào)用,以及消費(fèi)者遠(yuǎn)大于提供者。傳輸協(xié)議 TCP,異步,Hessian 序列化;
rmi:采用JDK標(biāo)準(zhǔn)的rmi協(xié)議實(shí)現(xiàn),傳輸參數(shù)和返回參數(shù)對(duì)象需要實(shí)現(xiàn)Serializable接口,使用java標(biāo)準(zhǔn)序列化機(jī)制,使用阻塞式短連接,傳輸數(shù)據(jù)包大小混合,消費(fèi)者和提供者個(gè)數(shù)差不多,可傳文件,傳輸協(xié)議 TCP。多個(gè)短連接,TCP 協(xié)議傳輸,同步傳輸,適用常規(guī)的遠(yuǎn)程服務(wù)調(diào)用和 rmi 互操作。在依賴低版本的 Common-Collections包,java 序列化存在安全漏洞;
webservice:基于 WebService 的遠(yuǎn)程調(diào)用協(xié)議,集成 CXF 實(shí)現(xiàn),提供和原生 WebService 的互操作。多個(gè)短連接,基于 HTTP 傳輸,同步傳輸,適用系統(tǒng)集成和跨語言調(diào)用;
http:基于 Http 表單提交的遠(yuǎn)程調(diào)用協(xié)議,使用Spring的HttpInvoke 實(shí)現(xiàn)。多個(gè)短連接,傳輸協(xié)議 HTTP,傳入?yún)?shù)大小混合,提供者個(gè)數(shù)多于消費(fèi)者,需要給應(yīng)用程序和瀏覽器 JS 調(diào)用;
hessian:集成Hessian 服務(wù),基于HTTP通訊,采用Servlet暴露服務(wù),Dubbo 內(nèi)嵌 Jetty 作為服務(wù)器時(shí)默認(rèn)實(shí)現(xiàn),提供與Hession服務(wù)互操作。多個(gè)短連接,同步 HTTP 傳輸,Hessian 序列化,傳入?yún)?shù)較大,提供者大于消費(fèi)者,提供者壓力較大,可傳文件;
memcache: 基于memcached實(shí)現(xiàn)的RPC協(xié)議
傳入傳出參數(shù)數(shù)據(jù)包較小(建議小于100K),消費(fèi)者比提供者個(gè)數(shù)多,單一消費(fèi)者無法壓滿提供者,盡量不要用dubbo協(xié)議傳輸大文件或超大字符串。
redis: 基于redis實(shí)現(xiàn)的RPC協(xié)議
傳入傳出參數(shù)數(shù)據(jù)包較小(建議小于100K),消費(fèi)者比提供者個(gè)數(shù)多,單一消費(fèi)者無法壓滿提供者,盡量不要用dubbo協(xié)議傳輸大文件或超大字符串。
通過timeout屬性配置超時(shí)時(shí)間,服務(wù)的提供者和消費(fèi)者都可以配置,盡量在服務(wù)提供者中配置,因?yàn)榉?wù)的提供者會(huì)對(duì)自己提供的服務(wù)情況更清楚超時(shí)時(shí)間不要設(shè)置太大(1~5S),會(huì)影響并發(fā)性能問題。
Dubbo在調(diào)用服務(wù)不成功時(shí),默認(rèn)會(huì)重試2次。Dubbo的路由機(jī)制,會(huì)把超時(shí)的請(qǐng)求路由到其他機(jī)器上,而不是本機(jī)嘗試,所以 dubbo的重試機(jī)制也能一定程度的保證服務(wù)的質(zhì)量
Multicast 注冊(cè)中心
Multicast 注冊(cè)中心不需要任何中心節(jié)點(diǎn),只要廣播地址,就能進(jìn)行服務(wù)注冊(cè)和發(fā)現(xiàn)?;诰W(wǎng)絡(luò)中組播傳輸實(shí)現(xiàn)
Zookeeper 注冊(cè)中心
基于分布式協(xié)調(diào)系統(tǒng) Zookeeper 實(shí)現(xiàn),采用Zookeeper 的 watch 機(jī)制實(shí)現(xiàn)數(shù)據(jù)變更
redis 注冊(cè)中心
基于redis實(shí)現(xiàn),采用key/Map存儲(chǔ),住key存儲(chǔ)服務(wù)名和類型,Map中key存儲(chǔ)服務(wù)URL,value 服務(wù)過期時(shí)間?;趓edis 的發(fā)布/訂閱模式通知數(shù)據(jù)變更;
隨機(jī)
按權(quán)重設(shè)置隨機(jī)概率。在一個(gè)截面上碰撞的概率高,但調(diào)用量越大分布越均勻,而且按概率使用權(quán)重后也比較均勻,有利于動(dòng)態(tài)調(diào)整提供者權(quán)重。(權(quán)重可以在dubbo管控臺(tái)配置)
輪循
按公約后的權(quán)重設(shè)置輪循比率。存在慢的提供者累積請(qǐng)求問題,比如:第二臺(tái)機(jī)器很慢,但沒掛,當(dāng)請(qǐng)求調(diào)到第二臺(tái)時(shí)就卡在那,久而久之,所有請(qǐng)求都卡在調(diào)到第二臺(tái)上。
最少活躍調(diào)用數(shù)
相同活躍數(shù)的隨機(jī),活躍數(shù)指調(diào)用前后計(jì)數(shù)差。使慢的提供者收到更少請(qǐng)求,因?yàn)樵铰奶峁┱叩恼{(diào)用前后計(jì)數(shù)差會(huì)越大。
一致性Hash
相同參數(shù)的請(qǐng)求總是發(fā)到同一提供者。當(dāng)某一臺(tái)提供者掛時(shí),原本發(fā)往該提供者的請(qǐng)求,基于虛擬節(jié)點(diǎn),平攤到其它提供者,不會(huì)引起劇烈變動(dòng)。
dubbo序列化:阿里尚未開發(fā)成熟的高效java序列化實(shí)現(xiàn),阿里不建議在生產(chǎn)環(huán)境使用它
hessian2序列化(默認(rèn)推薦):hessian是一種跨語言的高效二進(jìn)制序列化方式。但這里實(shí)際不是原生的hessian2序列化,而是阿里修改過的hessian lite,它是dubbo RPC默認(rèn)啟用的序列化方式
json序列化:目前有兩種實(shí)現(xiàn),一種是采用的阿里的fastjson庫,另一種是采用dubbo中自己實(shí)現(xiàn)的簡單json庫,但其實(shí)現(xiàn)都不是特別成熟,而且json這種文本序列化性能一般不如上面兩種二進(jìn)制序列化。
java序列化:主要是采用JDK自帶的Java序列化實(shí)現(xiàn),性能很不理想。
可以通信的,啟動(dòng)dubbo時(shí),消費(fèi)者會(huì)從zk拉取注冊(cè)的生產(chǎn)者的地址接口等數(shù)據(jù),緩存在本地。每次調(diào)用時(shí),按照本地存儲(chǔ)的地址進(jìn)行調(diào)用;
但前提是你沒有增加新的服務(wù),如果你要調(diào)用新的服務(wù),則是不能辦到的。
另外如果服務(wù)的提供者全部宕機(jī),服務(wù)消費(fèi)者會(huì)無法使用,并無限次重連等待服務(wù)者恢復(fù);
Dubbo采用全Spring 配置方式,透明化接入應(yīng)用,對(duì)應(yīng)用沒有任何API 侵入,只需用Spring加載Dubbo的配置即可。
NIO Netty框架
Failover Cluster(默認(rèn)):
失敗自動(dòng)切換,當(dāng)出現(xiàn)失敗,重試其它服務(wù)器。通常用于讀操作,但重試會(huì)帶來更長延遲。
Failfast Cluster
快速失敗,只發(fā)起一次調(diào)用,失敗立即報(bào)錯(cuò)。通常用于非冪等性的寫操作,比如新增記錄。
Failsafe Cluster
失敗安全,出現(xiàn)異常時(shí),直接忽略。通常用于寫入審計(jì)日志等操作。
Failback Cluster
失敗自動(dòng)恢復(fù),后臺(tái)記錄失敗請(qǐng)求,定時(shí)重發(fā)。通常用于消息通知操作。
Forking Cluster
并行調(diào)用多個(gè)服務(wù)器,只要一個(gè)成功即返回。通常用于實(shí)時(shí)性要求較高的讀操作,但需要浪費(fèi)更多服務(wù)資源。可通過 forks="2" 來設(shè)置最大并行數(shù)。
Broadcast Cluster
廣播調(diào)用所有提供者,逐個(gè)調(diào)用,任意一臺(tái)報(bào)錯(cuò)則報(bào)錯(cuò) 。通常用于通知所有提供者更新緩存或日志等本地資源信息。
Dubbo 是 SOA 時(shí)代的產(chǎn)物,它的關(guān)注點(diǎn)主要在于服務(wù)的調(diào)用,流量分發(fā)、流量監(jiān)控和熔斷。而 Spring Cloud 誕生于微服務(wù)架構(gòu)時(shí)代,考慮的是微服務(wù)治理的方方面面,另外由于依托了 Spirng、Spirng Boot 的優(yōu)勢之上,兩個(gè)框架在開始目標(biāo)就不一致,Dubbo定位服務(wù)治理、Spirng Cloud 是一個(gè)生態(tài)。最大的區(qū)別:Dubbo 底層是使用 Netty 這樣的 NIO 框架,是基于TCP 協(xié)議傳輸?shù)?,配合?Hession 序列化完成 RPC 通信。而 SpringCloud 是基于 Http 協(xié)議+Rest 接口調(diào)用遠(yuǎn)程過程的通信,相對(duì)來說,Http 請(qǐng)求會(huì)有更大的報(bào)文,占的帶寬也會(huì)更多。但是REST相比RPC更為靈活,服務(wù)提供方和調(diào)用方的依賴只依靠一紙契約,不存在代碼級(jí)別的強(qiáng)依賴。
猜你喜歡:
排他鎖和共享鎖分別是什么?有什么不同?
2020-10-30Java培訓(xùn)多少錢?選擇java培訓(xùn)機(jī)構(gòu)要注意什么?
2020-10-30重慶Java軟件開發(fā)培訓(xùn)價(jià)格是多少錢?Java零基礎(chǔ)注意啦!
2020-10-30ZooKeeper在集群Master選舉中應(yīng)用介紹
2020-10-30Java培訓(xùn)機(jī)構(gòu)學(xué)費(fèi)一般要多少錢?近期java學(xué)習(xí)趨勢
2020-10-30Zookeeper如何實(shí)現(xiàn)集群管理?
2020-10-30北京校區(qū)