Midnight

从0到1实现rpc之代码重构

20 Mar 2024   |  
  1. ZK注册中心ZkRegistryCenter的的启动与销毁

重构前，初始化和销毁方法依赖于bean的生命周期。

图片

这样带来的问题是当整个服务停止时，销毁方法先执行，客户端和zk服务端已经断开连接，而服务取消注册的逻辑再执行时，就不会成功。

图片

由于取消注册使用的是quietly()方式，出错了也不会报错，最终就是服务没有取消成功，消费者还可能调用到。

图片

重构后，注册中心先启动成功，在进行服务注册。服务销毁时，先取消注册，在关闭连接。

图片

  1. 抽取类型转换逻辑到工具类TypeUtils中。

这样带来的好处是业务功能和非业务功能逻辑分离，提高代码可读性和可复用性。

图片

  1. 网络客户端封装为接口

图片

定义HttpInvoker接口，添加当前使用的方式OkHttp作为客户端。这样基于接口设计带来的好处时想使用其他客户端时就很方便替换，不需要改变上层逻辑，添加新的实现类即可。

图片

  1. 封装ServiceMeta和InstanceMeta

图片

使用ServiceMeta代替String类型，来表示一个服务的元数据，表达含义更加丰富，支持更多非功能性场景。

图片

同理，使用InstanceMeta代替String类型，来表示一个实例的元数据，表达含义更加丰富，支持更多非功能性场景。

图片

  1. 封装ProviderInvoker

将服务提供者的调用逻辑抽出独立的类，职责更单一。

图片

此次，重构的要点

  1. 业务功能和非功能性逻辑分开，提高可读性和可扩展性。
  2. 使用保证类型替换String类型，丰富表达含义。
  3. 工具类抽取，提高复用性。
  4. 基于接口做设计，提高扩展性。
  5. 类职责保持单一，解耦，类聚。

源码：

https://github.com/midnight2104/midnight-rpc/tree/lesson6

从0到1实现rpc之基于zookeeper的注册中心

17 Mar 2024   |  

一、实现ZkRegistryCenter，主要接口方法如下：

图片

  1. start()启动方法，作为客户端连接ZooKeeper。定义连接串，命名空间和连接重试策略，随着服务的启动而启动。

图片

  1. stop()停止方法，断开和ZooKeeper的的连接。服务被销毁时，连接信息随之关闭。

图片

  1. register()服务注册方法，服务提供者provider向zk的注册。服务节点为持久化节点，实例是临时节点，当实例下线时，也会删除节点。

图片

  1. unregister()服务取消注册方法，服务提供者provider取消向zk的注册。判断服务路径是否存在，不存在直接返回。删除节点时，使用quietly删，没有实例也不要报错。

图片

  1. fetchAll()获取所有实例方法，服务消费者consumer从zk获取到所有服务提供者provider实例。

图片

  1. subscribe()订阅方法，服务消费者consumer从zk获取变动的实例。使用TreeCache缓存了服务节点，并添加监听器，有节点发生变动时就会执行。即再次获取所有服务实例，通过ChangedListener执行特定动作。

图片

二、服务提供者provider注册

  1. 加载注册中心，生成bean，指定初始化方法start()和销毁方法stop()。

图片

  1. 启动服务提供者provider的引导类。注意，Spring 的所有bean加载完成，项目启动成功才进行服务注册，防止启动过程中就注册，然后启动失败了，已经注册的可能会被调用。

图片

  1. 服务注册，所有bean加载完成后，服务端provider完成注册，调用注册中心RegisterCenter的register()方法完成服务的注册。服务实例instance其实就是ip+端口。

图片

  1. 服务销毁

使用@PreDestory注解，当服务停止时，便取消服务注册，使用注册中心RegisterCenter的unregister()方法。

图片

三、服务消费者consumer

在服务消费者consumer启动的过程中，向注册中心获取服务接口实例信息，放到代理类中。同时，完成注册中心的订阅，有节点发生变动，就会清空当前已经获取到的服务节点信息，然后再次获取最新的实例信息。

图片

四、测试

  1. 本地启动ZooKeeper，默认单机模式，端口是2181，然后使用ZooInspector连接zk，作为可视化界面。
  2. 接着启动3个服务提供者provider，端口使用8081, 8082, 8083。成功后，通过ZooInspector会看到如下信息。两个服务都有三个实例。

图片

  1. 启动服务消费者consumer，连续调用6次接口。

图片

\4. 观察日志信息，使用轮询的负载均衡也起作用了，也从注册中心获取到了全部节点信息。

图片

  1. 关闭一个服务8081，会看到注册中心也少了一个8081。

图片

还有哪些问题？

  1. 代码质量不高，需要重构。
  2. 过滤器，缓存，mock还不支持。
  3. 异常处理不完善，超时重试还不支持。
  4. 灰度发布也还不支持。

源码：

https://github.com/midnight2104/midnight-rpc/tree/lesson5

从0到1实现rpc之负载均衡和静态注册中心

16 Mar 2024   |  

一、Router的定义

Router路由用于预筛选，Dubbo有这样的设计，SpringCloud没有。

图片

二、LoadBanlancer定义

负载均衡器：默认取第一个

图片

当前支持随机和轮询两种负载均衡器。

随机：从所有provider中随机选择一个。

图片

轮询：每个provider服务按照顺序，依次调用

图片

三、注册中心的定义

  1. 开始方法start();
  2. 停止方法stop();
  3. Provider的注册方法register();
  4. Provider的取消注册方法unregister()；
  5. Consumer的获取所有服务方法fetchAll();
  6. 默认提供的静态注册中心类型，是为了后续的动态注册中心做准备。都是空方法，只是fetchAll()默认返回了所有providers；

图片

四、RpcContext定义

RpcContext用于封装上下文参数，避免参数过多传递。当前有过滤器Filter，负载均衡器LoadBalancer、路由器Router。

图片

五、创建Bean

在消费者配置类ConsumerConfig中创建Bean，包括注册中心，路由器和负载均衡器（这里使用的是轮询）。

图片

六、封装代理类

在消费者启动类ConsumerBootstrap中， 把路由器router和负载均衡器loadBalancer封装到RpcContext中。

在创建代理对象时，通过注册中心获取到所有的服务提供者providers，然后联合上下文信息RpcContext一起传递给代理类。

图片

在代理类中完成负载均衡，确定调用的服务类。

图片

七、测试

启动三个服务提供者provider，端口分别是8081,8082,8083

图片

启动服务消费者Consumer，配置好服务提供者provider的地址。

图片

同一个接口连续调用三次，可以看到返回结果，依次访问的是8081,8082,8083这三个服务，使用轮询负载均衡的目的已经成功了。

图片

图片

图片

工程地址：

https://github.com/midnight2104/midnight-rpc/tree/lesson4