微信门户网站开发,2024年将爆发新瘟疫,小程序权限超时,营销型网站建设特点ZooKeeper 在 Dubbo 应用中的作用 ZooKeeper 是一个开源的分布式协调服务#xff0c;它在 Dubbo 中被广泛使用来实现服务注册、发现和配置管理等功能。在 Dubbo 架构中#xff0c;ZooKeeper 扮演了一个重要的角色#xff0c;可以提供以下功能#xff1a; ZooKeeper 是一个开…ZooKeeper 在 Dubbo 应用中的作用 ZooKeeper 是一个开源的分布式协调服务它在 Dubbo 中被广泛使用来实现服务注册、发现和配置管理等功能。在 Dubbo 架构中ZooKeeper 扮演了一个重要的角色可以提供以下功能 ZooKeeper 是一个开源的分布式协调服务它在 Dubbo 中被广泛使用来实现服务注册、发现和配置管理等功能。在 Dubbo 架构中ZooKeeper 扮演了一个重要的角色可以提供以下功能
服务注册与发现Dubbo 的 provider服务提供者会将自己提供的服务信息注册到 ZooKeeper 上consumer服务消费者则通过 ZooKeeper 发现可用的服务。负载均衡ZooKeeper 可以记录每个 provider 提供的服务并且 Dubbo 的 consumer 可以从中选择一个适合的 provider 进行调用实现负载均衡的效果。故障恢复如果某个 provider 发生故障或下线ZooKeeper 可以及时更新服务注册信息使得 consumer 不再选择该 provider从而实现故障恢复。动态配置Dubbo 的一些配置信息如超时设置、权重等可以通过 ZooKeeper 实现动态配置这样避免了修改代码或重启应用的麻烦。集群管理ZooKeeper 还能够用于管理 Dubbo 集群的多个节点确保集群的高可用性和一致性。 所以ZooKeeper 在 Dubbo 应用中可以起到一个公告板的作用它集中管理服务的注册、发现和配置信息使得 Dubbo 的 provider 和 consumer 能够方便地进行通信和协调。通过 ZooKeeperDubbo 应用可以实现高可用、动态扩展和负载均衡等特性。
consumer是怎么样使用provider的提供的服务的
如果 consumer 和 provider 不在同一个包下但是要使用 provider 提供的服务可以通过以下步骤进行
在 consumer 的代码中创建一个与 provider 相同的服务接口类通常在 common 包下该接口定义了 provider 可以提供的各种服务方法包括输入参数和返回值等信息。 // 服务接口 public interface UserService { User getUserById(int id); void saveUser(User user); // 其他服务方法... } 将 provider 提供的服务接口类的 Jar 包或依赖添加到 consumer 的项目中。这样在 consumer 的代码中就可以引用该服务接口类了。在 consumer 的代码中通过 Dubbo 的配置方式来声明对 provider 提供的服务的引用。如果是使用 XML 配置需要在配置文件中声明对服务接口的引用并设置相关参数。 !-- Dubbo 服务引用配置 -- dubbo:reference iduserService interfacecom.example.UserService urldubbo://localhost:20880/ 如果是使用注解方式可以在消费方的代码中使用 Reference 注解来引用服务接口。 // 引入服务接口 Reference private UserService userService; 当 consumer 启动时Dubbo 框架会自动处理服务引用并创建代理对象。 consumer 就可以像调用本地方法一样直接使用代理对象来调用 provider 提供的服务方法。 // 调用服务 User user userService.getUserById(1); 通过以上步骤consumer 就可以使用 provider 提供的服务了。无论 consumer 和 provider 是否在同一个包下只要声明了相同的服务接口并进行合适的引用配置consumer 就能够调用 provider 的服务方法。
详细说明过程——当consumer 启动Dubbo 框架会自动处理服务引用并创建代理对象
当 consumer 启动时Dubbo 框架会自动处理服务引用并创建代理对象。这个过程可以分为以下几个步骤 根据 Dubbo 配置文件或注解配置Dubbo 框架会加载配置信息包括 ZooKeeper 地址、服务注册信息、负载均衡策略等。 Dubbo 框架会扫描 consumer 的代码查找被 Reference 注解修饰的服务引用字段或方法参数。或者根据 XML 配置文件中声明的服务引用信息。 对于每一个被 Reference 注解修饰的服务引用字段或方法参数Dubbo 框架会根据被注解修饰的类型服务接口类型创建一个代理对象。 创建代理对象的方式通常有两种JDK 动态代理和 Javassist 字节码生成。Dubbo 默认使用 Javassist 字节码生成。 创建代理对象时Dubbo 框架会将服务接口类型、服务引用配置、集群配置等信息传递给代理对象。 代理对象内部封装了网络通信、负载均衡、序列化、容错处理等底层细节的逻辑。 当 consumer 调用代理对象的方法时实际上是通过代理对象将调用请求发送给 Dubbo 框架。 Dubbo 框架根据负载均衡策略选择一个合适的 provider 实例并将请求转发给该 provider 实例。 provider 接收到请求后执行相应的服务逻辑并将结果返回给 Dubbo 框架。 Dubbo 框架将服务调用结果返回给代理对象然后代理对象再将结果返回给 consumer。 通过以上步骤Dubbo 框架在 consumer 启动时会自动处理服务引用创建代理对象还可以根据配置信息对服务调用进行负载均衡和容错处理。在 consumer 的代码中可以直接调用代理对象的方法来调用 provider 提供的服务而无需关心底层的网络通信和调用细节。这种透明化的远程调用方式使得 consumer 和 provider 可以像调用本地方法一样方便地进行服务交互。 zookeeper负责干嘛它详细具体的起到了什么作用
ZooKeeper 是一个分布式协调服务它具体起到以下作用
配置管理ZooKeeper 可以用于集中管理分布式系统中的各种配置信息。在模拟场景中假设有一个分布式应用程序需要连接到不同的数据库实例而这些数据库的连接信息可能会发生变化。使用 ZooKeeper可以将数据库连接信息存储在一个节点上并且各个应用程序可以监听该节点的变化从而动态获取最新的连接信息。 流程: a) 应用程序 A、B 和 C 需要连接到数据库实例。 b) ZooKeeper 创建一个节点 /database_config 并存储数据库连接信息例如 IP 地址、端口等。 c) 应用程序 A、B 和 C 在启动时连接到 ZooKeeper并监听节点 /database_config 的变化。 d) 如果数据库连接信息发生变化ZooKeeper 会通知应用程序 A、B 和 C。 e) 应用程序 A、B 和 C 接收到通知后根据最新的连接信息重新连接到数据库。 命名服务ZooKeeper 可以提供一个统一的命名空间来存储和查询分布式系统中的节点信息。在模拟场景中假设有一个分布式存储系统每个存储节点需要注册到 ZooKeeper并提供自己的状态信息。 流程 a) 存储节点 A、B 和 C 启动时将自己的状态信息注册到 ZooKeeper 中。 b) 其他节点或应用程序可以查询 ZooKeeper 获取存储节点的列表和状态信息。 分布式锁ZooKeeper 提供了分布式锁机制用于在分布式环境下实现互斥访问共享资源的功能。在模拟场景中假设有多个线程需要访问某个共享资源使用 ZooKeeper 的分布式锁可以确保同一时刻只有一个线程可以访问该资源。 流程 a) 线程 A、B 和 C 需要访问共享资源。 b) 每个线程在访问资源之前尝试获取 ZooKeeper 上的一个分布式锁节点。 c) 只有一个线程能够成功创建分布式锁节点表示获取到了锁。 d) 当线程完成对资源的访问后释放分布式锁节点以便其他线程可以竞争获取锁。 dubbo框架细节
1、common模块在最底层用于最基本的配置包括iolombok等
2、service层需要common层依赖,对应ssm服务层的接口
3、consumer和provider层都需要service的依赖但彼此之间没有依赖不可见二者对比ssm,前者类似controller层后者类比service层的实现类和Dao层
那么问题来了
1、consumer和provider二者不可见如何调用
首先源码中并无任何花里胡哨的操作虽然consumer中没有service层的实现类依然可以通过类似注入的形式给service接口赋值调用方法也像好像本模块中真的有这个接口的实现类一样这就是远端执行本地调用的rpc
2、zookeeper在从中扮演着什么角色
我们既然启动项目的时候必须首先启动zookeeper然后才能启动provider在最后才能启动consumer,那么zookeeper一定起了很大的作用
rpc需要将请求通过网络发送的形式去调用远端从而找到结果。那么zookeeper一定在网络发送中起了一定的作用其实zookeeper可以维护一个类似于公告板的东西从而能够使得consumer找到provider然后发送请求
当然还有一种猜测我们可能可以整一个像类似中转站一样将网络请求解析然后转发到正确的位置但实际上这样并不好因为网络最好去中心化否则中心结点的崩溃会导致整个网络崩溃所以我们采用了zookeeper去维护一个“公告板”这样即使zookeeper真的产生了崩溃客户端的缓存依旧可以使用一段时间不会像中转一样立刻就去世了
3、转发流程
首先需要序列化然后封装成为合格的网络协议因为网络传输肯定是01比特流不能直接传输对象这其中还需要代理的使用代理的作用即强化功能需要完成序列化与反序列化流程 为什么在dubbo框架中只用先启动provider再启动consumer。为什么service不用启动呢 在 Dubbo 中服务提供者provider启动时会将自己的服务注册到注册中心如 ZooKeeper上并监听指定的端口等待消费者consumer的请求。消费者会从注册中心获取可用的服务列表并根据负载均衡策略选择一个服务提供者进行调用。所以在 Dubbo 中可以先启动服务提供者provider再启动服务消费者consumer。 为什么不需要单独启动服务service呢这是因为 Dubbo 框架将服务的定义和实现解耦它通过接口的方式定义服务并将服务的具体实现交给服务提供者去完成。服务提供者启动时会通过配置文件或注解的方式指定具体的服务实现类。消费者只需要引入服务的接口定义并在配置文件或代码中声明要使用的服务接口Dubbo 框架会自动根据配置信息找到可用的服务提供者。 因此在 Dubbo 框架中并不需要单独启动服务service其定义只是作为消费者和提供者之间的契约存在实际的服务实现由提供者来负责。
也就是说consumer的请求会先打到zookeeper上面然后zookeeper根据负载均衡去分配provider提供的服务然后打到该provider监听的端口上 在 Dubbo 框架中消费者consumer的请求首先会发送到注册中心如 ZooKeeper。注册中心会维护服务提供者provider的信息包括它们的 IP 地址、端口和可用性等。消费者通过与注册中心交互获取可用的服务列表。 接下来消费者根据负载均衡策略选择一个合适的服务提供者进行调用。负载均衡策略可以是轮询、随机选择、权重等算法用于分配请求到不同的服务提供者。 一旦消费者确定要调用的服务提供者它会向该服务提供者发送请求。服务提供者监听指定的端口等待消费者的请求到达。一旦请求到达服务提供者会执行相应的服务实现并将结果返回给消费者。 总结起来消费者的请求首先经过注册中心获取可用的服务列表然后根据负载均衡策略选择一个服务提供者并向选定的服务提供者发送请求。最后服务提供者执行具体的服务实现并返回结果给消费者。
