大家好,今天小編來(lái)為大家解答以下的問(wèn)題，關(guān)于dubbo協(xié)議有哪些，dubbo的原理和機(jī)制這個(gè)很多人還不知道，現(xiàn)在讓我們一起來(lái)看看吧！
dubbo和zookeeper常見面試題
1.Dubbo的工作流程是什么？
答：Dubbo的工作流程包括：provider向注冊(cè)中心去注冊(cè)自己為一個(gè)服務(wù)，consumer去注冊(cè)中心訂閱服務(wù)，注冊(cè)中心會(huì)通知consumer注冊(cè)好的服務(wù)，consumer會(huì)將provider的地址等信息拉取到本地緩存，consumer去調(diào)用provider，consumer和provider都異步的通知監(jiān)控中心。
2.Dubbo的通信原理是什么？
答：Dubbo底層使用hessian2進(jìn)行二進(jìn)制序列化進(jìn)行遠(yuǎn)程調(diào)用，Dubbo底層使用Netty框架進(jìn)行異步通信。
3.Dubbo負(fù)載均衡策略有哪些？
答：Dubbo負(fù)載均衡策略包括：randomloadbalance、roundrobinloadbalance、leastactiveloadbalance、consistanthashloadbalance等。
4.ZooKeeper是什么？有什么作用？
答：ZooKeeper是一個(gè)分布式協(xié)調(diào)服務(wù)，可以用于分布式應(yīng)用程序的協(xié)調(diào)和管理。它提供了一個(gè)分布式的、開放的、可靠的數(shù)據(jù)存儲(chǔ)，用于存儲(chǔ)和管理分布式應(yīng)用程序的配置信息、命名服務(wù)、狀態(tài)信息等。
5.ZooKeeper的特點(diǎn)是什么？
答：ZooKeeper的特點(diǎn)包括：高可用性、高性能、數(shù)據(jù)一致性、順序訪問(wèn)、可靠性、容錯(cuò)性等。
6.ZooKeeper的工作原理是什么？
答：ZooKeeper的工作原理是基于ZAB協(xié)議，它將數(shù)據(jù)存儲(chǔ)在內(nèi)存中，并將數(shù)據(jù)同步到所有的ZooKeeper服務(wù)器上，保證數(shù)據(jù)的一致性。ZooKeeper使用了一種基于觀察者模式的機(jī)制，當(dāng)數(shù)據(jù)發(fā)生變化時(shí)，會(huì)通知所有的觀察者。
7.ZooKeeper的節(jié)點(diǎn)類型有哪些？
答：ZooKeeper的節(jié)點(diǎn)類型包括：持久節(jié)點(diǎn)、臨時(shí)節(jié)點(diǎn)、持久順序節(jié)點(diǎn)、臨時(shí)順序節(jié)點(diǎn)。
8.ZooKeeper如何保證數(shù)據(jù)的一致性？
答：ZooKeeper使用了ZAB協(xié)議來(lái)保證數(shù)據(jù)的一致性，它將數(shù)據(jù)存儲(chǔ)在內(nèi)存中，并將數(shù)據(jù)同步到所有的ZooKeeper服務(wù)器上，保證數(shù)據(jù)的一致性。
dubbo的協(xié)議為什么推薦dubbo
dubbo是一款高性能、輕量級(jí)的開源JavaRPC框架，它提供了三大核心能力：面向接口的遠(yuǎn)程方法調(diào)用，智能容錯(cuò)和負(fù)載均衡，以及服務(wù)自動(dòng)注冊(cè)和發(fā)現(xiàn)。隨著服務(wù)化的進(jìn)一步發(fā)展，服務(wù)越來(lái)越多，服務(wù)之間的調(diào)用和依賴關(guān)系也越來(lái)越復(fù)雜，誕生了面向服務(wù)的架構(gòu)體系(SOA)。
如果沒有dubbo該怎么調(diào)用遠(yuǎn)程服務(wù)
1可以使用HTTP協(xié)議進(jìn)行遠(yuǎn)程調(diào)用2因?yàn)閐ubbo是一種基于RPC協(xié)議的遠(yuǎn)程調(diào)用框架，如果沒有dubbo可以選擇使用HTTP協(xié)議進(jìn)行遠(yuǎn)程調(diào)用，通過(guò)構(gòu)造HTTP請(qǐng)求和響應(yīng)來(lái)完成遠(yuǎn)程服務(wù)的調(diào)用。3當(dāng)然，使用HTTP協(xié)議進(jìn)行遠(yuǎn)程調(diào)用相對(duì)于使用RPC框架而言，會(huì)存在一定的性能損失和安全風(fēng)險(xiǎn)，因此在實(shí)際項(xiàng)目中需要根據(jù)具體情況進(jìn)行權(quán)衡和選擇。
dubbo和openfeign的優(yōu)缺點(diǎn)
Dubbo和OpenFeign都是用于服務(wù)治理的開源框架，但它們的設(shè)計(jì)思路不同，因此也有不同的優(yōu)缺點(diǎn)。
Dubbo的優(yōu)點(diǎn)：
1.高性能：Dubbo采用了多種優(yōu)化技術(shù)，如緩存、序列化、線程池等，能夠提供非常高的性能。
2.強(qiáng)大的服務(wù)治理：Dubbo提供了完善的服務(wù)治理功能，如服務(wù)的注冊(cè)與發(fā)現(xiàn)、負(fù)載均衡、熔斷、限流等。
3.支持多協(xié)議：Dubbo支持多種RPC協(xié)議（Dubbo協(xié)議、Thrift協(xié)議、HTTP協(xié)議等），讓開發(fā)者有更多的選擇權(quán)。
4.支持多語(yǔ)言：Dubbo支持Java、Python、C#、Node.js等多種語(yǔ)言，在微服務(wù)多語(yǔ)言化的應(yīng)用場(chǎng)景下比較方便。
Dubbo的缺點(diǎn)：
1.只適用于Java語(yǔ)言
2.對(duì)接口侵入性比較強(qiáng)，需要遵循Dubbo的API規(guī)范
3.部署配置較為復(fù)雜，需要進(jìn)行配置注冊(cè)中心、協(xié)議等信息
OpenFeign的優(yōu)點(diǎn)：
1.聲明式服務(wù)調(diào)用，減少了代碼量和開發(fā)難度，可以直接通過(guò)注解方式定義RESTful接口
2.支持多種編碼器和解碼器，方便數(shù)據(jù)的傳輸和解析。
3.沒有復(fù)雜的XML配置，只需簡(jiǎn)單的配置與Spring集成即可。
OpenFeign的缺點(diǎn)：
1.不支持Dubbo和Thrift等RPC協(xié)議
2.相比于Dubbo，功能相對(duì)簡(jiǎn)單，不支持熔斷、降級(jí)等高級(jí)的服務(wù)治理功能。
3.性能相對(duì)Dubbo要差一些。
它幾乎無(wú)所不能，點(diǎn)此提問(wèn)
微服務(wù)框架spring cloud和dubbo有什么區(qū)別
首先，從嚴(yán)格意義上來(lái)說(shuō)，Dubbo和SpringCloud的定位是不一樣的。Dubbo是一個(gè)高性能的、基于java的開源RPC框架，注意它的定位是是高性能和RPC框架。SpringCloud提供了一系列通用工具來(lái)幫助開發(fā)者在分布式系統(tǒng)里快速構(gòu)建一些常見模式，比如分布式配置管理、服務(wù)發(fā)現(xiàn)、熔斷降級(jí)、智能路由、微代理、控制總線、一次性令牌、全局鎖、分布式選主、分布式session等一些列解決方案，它的設(shè)計(jì)目標(biāo)是提供一整套服務(wù)治理能力，它具有一套完整的微服務(wù)解決方案體系。
dubbo只是一個(gè)分布式的RPC框架，如果一定要按照分布式系統(tǒng)架構(gòu)里的功能來(lái)定義的話，只是解決了服務(wù)發(fā)現(xiàn)、服務(wù)路由、服務(wù)降級(jí)和負(fù)載均衡方面的能力，新版本里也提供了動(dòng)態(tài)配置中心和服務(wù)治理相關(guān)的能力，但相比SpringCloud而言，還是差了相當(dāng)一部分的能力。
從功能支持上來(lái)說(shuō)，dubbo的角色定位可能更像是另外一個(gè)大名鼎鼎的框架，那就是gRPC，而且兩者在使用的方式以及工作原理上都非常相似，都是基于序列化協(xié)議來(lái)解決分布式系統(tǒng)中的遠(yuǎn)程調(diào)用問(wèn)題，在使用上可以通過(guò)約定接口或者通過(guò)proto文件生成代碼文件來(lái)“提升用戶的使用”。
如果你在系統(tǒng)設(shè)計(jì)之初就已經(jīng)考慮到了后續(xù)可能會(huì)涉及到各種服務(wù)治理能力，比如分布式配置、全局鎖、分布式session等常見需求，那么使用SpringCloud將會(huì)減少你很多的工作，因?yàn)檫@些基本上都是"套件"，相互配合使用會(huì)非常順暢。如果你想要的只是解決分布式架構(gòu)后的遠(yuǎn)程調(diào)用問(wèn)題，那么Dubbo是一個(gè)不錯(cuò)的選擇。
SpringCloud和Dubbo的基本差異大概就是如上所述，如果你不知道該如何做選擇，這里再補(bǔ)充幾個(gè)比較關(guān)鍵的差異點(diǎn)，希望能幫助你更好的結(jié)合自身業(yè)務(wù)做出選擇：
能力支持方面
上文也提到，SpringCloud提供了一整套微服務(wù)治理的功能組件，很多組件基本上都是"開箱即用"的，并且相互之間能很好的兼容，舉個(gè)例子，如果要在SpringCloud里實(shí)現(xiàn)服務(wù)發(fā)現(xiàn)、負(fù)載均衡和熔斷降級(jí)，你只需要引用SpringCloud的依賴組件即可，直接通過(guò)注解便可使用，基本上零配置；而dubbo框架，除了上述提到的能力支持之外，如果想要使用熔斷降級(jí)，那你可能需要額外引用hystrix或者resilience4j來(lái)實(shí)現(xiàn)；溫馨提示，hystrix官方目前也已經(jīng)宣布不再更新，并且推薦使用resilience4j。
協(xié)議兼容方面
SpringCloud里并沒有限制服務(wù)之間的通信協(xié)議，但是主流的一些客戶端比如restTemple、feign等都是直接支持使用Ribbon來(lái)做服務(wù)注冊(cè)發(fā)現(xiàn)和智能路由的，其底層通信的協(xié)議都是HTTP；而dubbo框架缺省是基于NIO異步傳輸使用TCP長(zhǎng)連接并采用Hessian二進(jìn)制序列化方式通信的；
這會(huì)涉及后續(xù)系統(tǒng)在擴(kuò)展上的兼容性問(wèn)題，比如需要調(diào)用一個(gè)三方系統(tǒng)或者是被第三方系統(tǒng)調(diào)用，相比而言HTTP協(xié)議可能更加通用。
模型定義方面
dubbo在模型設(shè)計(jì)上將一個(gè)接口定義為一個(gè)服務(wù)，而SpringCloud里則是將一個(gè)應(yīng)用定義為一個(gè)服務(wù)，這兩者在模型上是存在很大差異的，你也許會(huì)奇怪，這個(gè)對(duì)使用會(huì)有影響嗎？從現(xiàn)有使用方面來(lái)說(shuō)是沒有什么影響的，但是你如果有關(guān)注ServiceMesh最新微服務(wù)技術(shù)的話，目前對(duì)Dubbo協(xié)議這塊可能支持暫時(shí)還不完善，其中很大一部分原因就是因?yàn)樵诜?wù)模型上與K8S的服務(wù)模型有差異；
調(diào)用性能方面
如果分布式系統(tǒng)中比較關(guān)注遠(yuǎn)程調(diào)用的性能，那Dubbo可能是一個(gè)較好的選擇，基于NIO和TCP長(zhǎng)連接的通信傳輸方式，在性能上相比HTTP協(xié)議是有絕對(duì)優(yōu)勢(shì)的；當(dāng)然基于SpringCloud你也可以使用gRPC協(xié)議來(lái)解決性能問(wèn)題，那就是另外一個(gè)問(wèn)題了。
dubbo協(xié)議有哪些和dubbo的原理和機(jī)制的問(wèn)題分享結(jié)束啦，以上的文章解決了您的問(wèn)題嗎？歡迎您下次再來(lái)哦！
