Soul的SPI以及负载均衡策略研究

Soul的SPI以及负载均衡策略研究

上一节留下的几个问题在以后进行的研究

• 如何从abstractSoulPlugin执行完以后到WebClientPlugin的相同方法，是责任链模式仍是其余的加载过程

各个插件执行的时候其实是责任链模式。请求分发执行的这个方法主要是SoulWebHandler 继承了Spring webflux的WebHandler的handle方法。handle方法中的参数正好就是请求的相关参数，而后咱们就能够在插件的执行逻辑内转发和作操做

• abstractSoulPlugin是如何加载注册或修改后的选择器等数据

能够看到在数据同步的配置中,是由zkClient.subscribeDataChanges来订阅数据的改变操做，从感受上来讲，可能没有websocket那么明显

• plugin 中的执行方法是如何获取到ServerWebExchange的相关请求数据

SoulWebHandler 继承了Spring webflux的WebHandler的handle方法,springwebflux内部获取了请求的相关属性放入了ServerWebExchange中

Soul的SPI以及引伸出的负载均衡

针对负载均衡的研究，其实我在一开始的使用的文章中就已经提到过了。所以我今天继续尝试了负载均衡的相关代码的查看，首先，在上一节的基础上，咱们能够知道，插件是经过责任链模式进行执行的。而咱们负载均衡这一部分是使用的 默认的divide插件来执行的。在divide插件的doExecute方法中，首先进行了SPI的类加载，而后根据类加载的状况获取了具体的负载均衡的策略。用来执行了具体的负载均衡策略，经过以下在SPI代码插入的日志语句

能够看到。SPI不只加载了负载均衡的具体方式。并且在此以前，还加载了屡次匹配策略，全局搜索后发现不只base插件和divide插件会加载SPI类，监控相关的MetricsTrackerFacade中也一样使用了SPI类。同时，在SPI的第一次加载某个SPI实现时，SPI会将相关类实例在缓存中缓存起来。这样不用在后续的代码中继续执行加载资源解析spi文件等具体的耗时操做，另外 负载均衡中内置了hash，轮询roundrobin,随机random三种负载均衡方式，因为对算法尚未进行深刻研究，在此不作过多说明，后续进行了一些研究再在此基础上进行说明



下面，想探讨下，当选择器负载均衡和选择器规则负载均衡不相同且选择器规则负载均衡为random时为何选择的是选择器的负载均衡

经过在插件执行的断点中执行能够看出。插件同时获取了规则和选择器的负载均衡策略。而执行那个负载均衡策略在具体的执行器中进行选择

能够看到在random的负载均衡策略中仍然进行了选择器权重的区分。经过类的继承关系能够看到getWeight方法被定义在模板抽象类中，同时被roundrobin和random使用，从而实现了上述的所说的在选择器规则存在的状况下依然选择了roundrobin负载均衡

欢迎搜索关注本人与朋友共同开发的微信面经小程序【大厂面试助手】和公众号【微瞰技术】，以及总结的分类面试题https://github.com/zhendiao/JavaInterview