# 《RPC手撸专栏》第42章：基于SPI扩展随机算法负载均衡策略

沉淀，成长，突破，帮助他人，成就自我。

大家好，我是冰河~~

在前面的章节中，我们基于SPI扩展了序列化与反序列化机制，在服务消费者端基于SPI扩展了JDK、CGLib、Javassist、ByteBuddy和ASM动态代理机制。在服务提供者端，基于SPI扩展了JDK、CGLib、Javassist、ByteBuddy和ASM反射机制调用真实方法的功能。

# 一、前言

搞完序列化与反序列化、动态代理和反射机制的SPI扩展，接下来搞搞负载均衡的SPI扩展？

在前面的文章中，我们基于SPI分别扩展了序列化与反序列化机制、动态代理机制和反射机制，做到了序列化与反序列化、动态代理和反射机制功能的高度扩展性，如果框架内置的序列化与反序列化、动态代理和反射功能不能满足大家的实际场景需求，各位小伙伴也可以根据RPC框架提供的SPI机制自行扩展相应的功能。

接下来，我们一起对负载均衡功能下手，对这些功能进行SPI扩展。

目标很明确：基于SPI扩展随机算法负载均衡策略！

经过前面文章对一些功能进行的SPI扩展，相信很多小伙伴都对SPI扩展机制有了更加深刻的理解，很多小伙伴应该也能够将SPI机制熟练的运用到自己的项目中。

还是那句话：我们学习知识，学习框架，学习自己手写中间件不能只是为了学习这个框架，学习这个技术而已，而是要将学习到的知识运用到自己的实际项目中，学会举一反三，学以致用。

好了，我们一起基于SPI扩展随机算法的负载均衡策略吧。

如果让你设计基于SPI扩展随机算法负载均衡策略，你会怎么设计呢？

基于SPI扩展随机算法负载均衡策略的流程如图42-1所示。

图42-1

由图42-1可以看出如下信息：

（1）服务提供者会通过自定义类扫描器整合注册中心，将服务注册到注册中心。

（2）服务注册到注册中心的元数据，例如服务的名称、服务的版本号、服务地址、服务端口和服务分组等信息，元数据会贯穿整个服务的注册与发现流程。

（3）服务注册与发现接口对外提供服务注册与发现的方法，服务提供者通过自定义扫描器会调用服务注册与发现接口的方法实现服务注册功能。

（4）基于服务注册与发现的接口，服务提供者会实现多个服务注册与发现的实现类，每个实现类对应着一种注册中心服务。

（5）服务消费者会通过服务注册与发现接口订阅注册中心的服务，会从注册中心获取到服务提供者发布的服务信息，实现服务发现的功能。

（7）服务消费者从注册中心获取到服务提供者发布的服务信息后，会基于SPI机制动态加载随机算法的负载均衡策略从多个服务中选择一个进行远程网络连接。

（8）服务消费者会直接与根据基于SPI机制动态加载的负载均衡策略选择出的服务提供者建立连接，实现数据交互。也就是说，后续服务消费者会与服务提供者直接实现数据交互。

说了这么多，具体要怎么实现呢？

基于SPI扩展随机算法负载均衡策略的核心类关系如图42-2所示。

图42-2

加入冰河技术 (opens new window)知识星球，解锁完整技术文章与完整代码