大家好，關于dubbo3新特性很多朋友都還不太明白，不過沒關系，因為今天小編就來為大家分享關于Aop使用場景的知識點，相信應該可以解決大家的一些困惑和問題，如果碰巧可以解決您的問題，還望關注下本站哦，希望對各位有所幫助！

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

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

說一下Dubbo的工作原理注冊中心掛了可以繼續通信嗎

Dubbo分布式的RPC，微服務框架，

包括三個關鍵功能：基于接口的遠程調用，容錯與負載均衡，服務自動注冊與發現。

Dubbo使得調用遠程服務就像調用本地java服務一樣簡單。

參考Dubbo官方文檔：包括實現細節，遠程調用細節，服務提供者暴露服務。

主要流程。

1、provider向注冊中心去注冊

2、consumer從注冊中心訂閱服務，注冊中心會通知consumer注冊好的服務

3、consumer調用provider

4、consumer和provider都異步的通知監控中心

基于zk作為注冊中心：

【提供者】在【啟動】時，向注冊中心zk【注冊】自己提供的服務。

【消費者】在【啟動】時，向注冊中心zk【訂閱】自己所需的服務。

所以是可以的，消費者在啟動時，消費者會從zk拉取注冊的生產者的地址接口等數據，緩存在本地。每次調用時，按照本地存儲的地址進行調用，消費者本地有一個生產者的列表，他會按照列表繼續工作，倒是無法從注冊中心去同步最新的服務列表，短期的注冊中心掛掉是不要緊的，但一定要盡快修復，掛掉是不要緊的，但前提是你沒有增加新的服務，如果你要調用新的服務，則是不能辦到的

關于dubbo負載均衡算法如何選擇

在生產環境我推薦加權輪選或加權隨機，強烈反對使用一致性hash算法，理由如下。

在Dubbo中主要提供了如下幾種負載均衡算法：

1、random加權隨機

2、roundrobin加權輪詢

3、leastactive最小連接數

4、consistenthash一致性Hash算法

加權隨機與加權輪詢都引入了權重的概率，主要是考慮到集群中各個機器的配置不一樣，導致其提供服務的能力不一致，故可以將配置低的機器其權重調低，實現流量更加合理的分配。

最小連接數負載均衡主打的特色是可以根據運行時當前的調用情況選擇進行流量分配，即優先將流量分發到當前負載低的節點，這個算法看似高大上，個人覺得其使用場景不是特別多，并且需要實時采集這些信息，其實現也較為復雜，實際生產中無特殊情況，不建議使用。

個人是強烈反對使用一致性Hash算法來用做Dubbo的服務負載均衡算法，因為Dubbo服務是無狀態的，不存在緩存命中率這一說法。而一致性Hash算法最大的使用場景是放在分布式緩存。

例如一個分布式Redis集群，原先有4個節點，如果按照輪詢來進行負載均衡，有4個key

key1->node1

key2->node2

key3->node3

key4->node4

那例如節點node1發生宕機，那根據原先存儲的key再用輪詢的策略，會發生如下對應情況：

key1->node2

key2->node3

key3->node4

key4->node2

即這個時候，用key2去集群中查詢數據，因為key2的數據存儲在node2中，但由于節點發生變化，導致會路由到node3上，導致緩存失效。

這就是緩存命中率的問題。

但一致性hash算法，只會影響故障節點相鄰的數據，其他數據還是能命中，這樣緩存才有意義。

最后我推薦roundrobin或random，通常建議考慮roundrobin，因為它不具隨機性，跟蹤問題方便，兩者實現復雜程度不大，故都可以。

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的節點類型包括：持久節點、臨時節點、持久順序節點、臨時順序節點。

8.ZooKeeper如何保證數據的一致性？

答：ZooKeeper使用了ZAB協議來保證數據的一致性，它將數據存儲在內存中，并將數據同步到所有的ZooKeeper服務器上，保證數據的一致性。

dubbo和openfeign的優缺點

Dubbo和OpenFeign都是用于服務治理的開源框架，但它們的設計思路不同，因此也有不同的優缺點。

Dubbo的優點：

1.高性能：Dubbo采用了多種優化技術，如緩存、序列化、線程池等，能夠提供非常高的性能。

2.強大的服務治理：Dubbo提供了完善的服務治理功能，如服務的注冊與發現、負載均衡、熔斷、限流等。

3.支持多協議：Dubbo支持多種RPC協議（Dubbo協議、Thrift協議、HTTP協議等），讓開發者有更多的選擇權。

4.支持多語言：Dubbo支持Java、Python、C#、Node.js等多種語言，在微服務多語言化的應用場景下比較方便。

Dubbo的缺點：

1.只適用于Java語言

2.對接口侵入性比較強，需要遵循Dubbo的API規范

3.部署配置較為復雜，需要進行配置注冊中心、協議等信息

OpenFeign的優點：

1.聲明式服務調用，減少了代碼量和開發難度，可以直接通過注解方式定義RESTful接口

2.支持多種編碼器和解碼器，方便數據的傳輸和解析。

3.沒有復雜的XML配置，只需簡單的配置與Spring集成即可。

OpenFeign的缺點：

1.不支持Dubbo和Thrift等RPC協議

2.相比于Dubbo，功能相對簡單，不支持熔斷、降級等高級的服務治理功能。

3.性能相對Dubbo要差一些。

它幾乎無所不能，點此提問

dubbo和hessian的區別

支持的協議不同。

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

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

文章到此結束，如果本次分享的dubbo3新特性和Aop使用場景的問題解決了您的問題，那么我們由衷的感到高興！