dubbo3新特性？Aop使用场景

大家好，关于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使用场景的问题解决了您的问题，那么我们由衷的感到高兴！