dubbo zookeeper，阿里用什么替代了dubbo

其實dubbo zookeeper的問題并不復雜，但是又很多的朋友都不太了解阿里用什么替代了dubbo，因此呢，今天小編就來為大家分享dubbo zookeeper的一些知識，希望可以幫助到大家，下面我們一起來看看這個問題的分析吧！

微服務框架spring cloud和dubbo有什么區別

首先，從嚴格意義上來說，Dubbo和SpringCloud的定位是不一樣的。Dubbo是一個高性能的、基于java的開源RPC框架，注意它的定位是是高性能和RPC框架。SpringCloud提供了一系列通用工具來幫助開發者在分布式系統里快速構建一些常見模式，比如分布式配置管理、服務發現、熔斷降級、智能路由、微代理、控制總線、一次性令牌、全局鎖、分布式選主、分布式session等一些列解決方案，它的設計目標是提供一整套服務治理能力，它具有一套完整的微服務解決方案體系。

dubbo只是一個分布式的RPC框架，如果一定要按照分布式系統架構里的功能來定義的話，只是解決了服務發現、服務路由、服務降級和負載均衡方面的能力，新版本里也提供了動態配置中心和服務治理相關的能力，但相比SpringCloud而言，還是差了相當一部分的能力。

從功能支持上來說，dubbo的角色定位可能更像是另外一個大名鼎鼎的框架，那就是gRPC，而且兩者在使用的方式以及工作原理上都非常相似，都是基于序列化協議來解決分布式系統中的遠程調用問題，在使用上可以通過約定接口或者通過proto文件生成代碼文件來“提升用戶的使用”。

如果你在系統設計之初就已經考慮到了后續可能會涉及到各種服務治理能力，比如分布式配置、全局鎖、分布式session等常見需求，那么使用SpringCloud將會減少你很多的工作，因為這些基本上都是"套件"，相互配合使用會非常順暢。如果你想要的只是解決分布式架構后的遠程調用問題，那么Dubbo是一個不錯的選擇。

SpringCloud和Dubbo的基本差異大概就是如上所述，如果你不知道該如何做選擇，這里再補充幾個比較關鍵的差異點，希望能幫助你更好的結合自身業務做出選擇：

能力支持方面

上文也提到，SpringCloud提供了一整套微服務治理的功能組件，很多組件基本上都是"開箱即用"的，并且相互之間能很好的兼容，舉個例子，如果要在SpringCloud里實現服務發現、負載均衡和熔斷降級，你只需要引用SpringCloud的依賴組件即可，直接通過注解便可使用，基本上零配置；而dubbo框架，除了上述提到的能力支持之外，如果想要使用熔斷降級，那你可能需要額外引用hystrix或者resilience4j來實現；溫馨提示，hystrix官方目前也已經宣布不再更新，并且推薦使用resilience4j。

協議兼容方面

SpringCloud里并沒有限制服務之間的通信協議，但是主流的一些客戶端比如restTemple、feign等都是直接支持使用Ribbon來做服務注冊發現和智能路由的，其底層通信的協議都是HTTP；而dubbo框架缺省是基于NIO異步傳輸使用TCP長連接并采用Hessian二進制序列化方式通信的；

這會涉及后續系統在擴展上的兼容性問題，比如需要調用一個三方系統或者是被第三方系統調用，相比而言HTTP協議可能更加通用。

模型定義方面

dubbo在模型設計上將一個接口定義為一個服務，而SpringCloud里則是將一個應用定義為一個服務，這兩者在模型上是存在很大差異的，你也許會奇怪，這個對使用會有影響嗎？從現有使用方面來說是沒有什么影響的，但是你如果有關注ServiceMesh最新微服務技術的話，目前對Dubbo協議這塊可能支持暫時還不完善，其中很大一部分原因就是因為在服務模型上與K8S的服務模型有差異；

調用性能方面

如果分布式系統中比較關注遠程調用的性能，那Dubbo可能是一個較好的選擇，基于NIO和TCP長連接的通信傳輸方式，在性能上相比HTTP協議是有絕對優勢的；當然基于SpringCloud你也可以使用gRPC協議來解決性能問題，那就是另外一個問題了。

hessian和dubbo的區別

Hessian和Dubbo都是Java中流行的RPC（RemoteProcedureCall）遠程過程調用框架，它們的主要區別如下：

1.通訊協議：Hessian默認使用HTTP協議，而Dubbo則采用自己設計的二進制協議，該協議相比于HTTP協議具有更高的傳輸效率和更低的延遲，適合用于大規模服務間的通信。

2.服務注冊中心：Dubbo提供了服務注冊中心，該注冊中心可以支持多種協議、多種類型的服務注冊和發現，并提供了多種負載均衡和故障轉移策略，方便集中管理分布式服務；而在Hessian中需要手動將服務地址傳遞給調用方，沒有直接的服務注冊中心。

3.動態代理：Dubbo使用JDK動態代理技術實現服務調用，而Hessian則使用本地動態代理技術實現服務調用，兩者實現方式不同，但都能滿足大多數現代應用場景的需求。

4.性能：在多個性能測試中，Dubbo的性能通常優于Hessian。這主要是由于Dubbo采用了更為高效的二進制協議，并且提供了更加靈活的調用策略和更為完善的服務治理機制，能夠更好地支持大規模分布式服務的調用。

總的來說，Hessian是一款輕量級的遠程服務調用框架，適合用于小型中小型應用，而Dubbo則是更為強大和完善的分布式服務框架，適合用于大型分布式應用。選擇框架應該根據具體需求和項目規模綜合考慮。

dubbo和hessian的區別

支持的協議不同。

1.dubbo支持多種遠程調用方式，例如dubboRPC（二進制序列化+tcp協議）、httpinvoker（二進制序列化+http協議，至少在開源版本沒發現對文本序列化的支持）。

2.hessian（二進制序列化+http協議）、WebServices（文本序列化+http協議）。

jdk8升jdk17，報Dubbo服務找不到provider

1Dubbo服務找不到provider的問題是可能會出現的。2這可能是因為jdk8和jdk17在某些API的實現上有所不同，導致Dubbo服務無法找到它需要的provider。3要解決這個問題，可以先嘗試檢查Dubbo服務所需要的API是否在jdk17中有實現，如果沒有，可以嘗試手動添加相應的實現類。此外，還可以查看Dubbo服務的配置是否正確，確保能夠正確地找到provider。如果還是無法解決，可以考慮聯系Dubbo的官方支持，獲得更進一步的幫助。

dubbo和zookeeper常見面試題

1.Dubbo的工作流程是什么？

答：Dubbo的工作流程包括：provider向注冊中心去注冊自己為一個服務，consumer去注冊中心訂閱服務，注冊中心會通知consumer注冊好的服務，consumer會將provider的地址等信息拉取到本地緩存，consumer去調用provider，consumer和provider都異步的通知監控中心。

2.Dubbo的通信原理是什么？

答：Dubbo底層使用hessian2進行二進制序列化進行遠程調用，Dubbo底層使用Netty框架進行異步通信。

3.Dubbo負載均衡策略有哪些？

答：Dubbo負載均衡策略包括：randomloadbalance、roundrobinloadbalance、leastactiveloadbalance、consistanthashloadbalance等。

4.ZooKeeper是什么？有什么作用？

答：ZooKeeper是一個分布式協調服務，可以用于分布式應用程序的協調和管理。它提供了一個分布式的、開放的、可靠的數據存儲，用于存儲和管理分布式應用程序的配置信息、命名服務、狀態信息等。

5.ZooKeeper的特點是什么？

答：ZooKeeper的特點包括：高可用性、高性能、數據一致性、順序訪問、可靠性、容錯性等。

6.ZooKeeper的工作原理是什么？

答：ZooKeeper的工作原理是基于ZAB協議，它將數據存儲在內存中，并將數據同步到所有的ZooKeeper服務器上，保證數據的一致性。ZooKeeper使用了一種基于觀察者模式的機制，當數據發生變化時，會通知所有的觀察者。

7.ZooKeeper的節點類型有哪些？

答：ZooKeeper的節點類型包括：持久節點、臨時節點、持久順序節點、臨時順序節點。