目标
Divide 插件介绍
-
Divide 插件配置
- pom依赖配置
- admin配置
发起请求如何通过Divide代理转发
Divide插件介绍
Divide 插件是网关处理Http协议请求的核心处理插件,通过设置可以准确的拦截和负载对应的请求。目前Soul针对规则支持 And 和 Or 逻辑连接。同时对于代理多个三方应用支持负载均衡。目前支持的负载均衡算法有 Hash,Rondom,RoundRobin三种算法。
Divide插件配置
pom依赖配置
admin配置
- 通过注解@SoulSpringMvcClient配置
- 通过网页配置
这里 注解方式其实就是简化了配置,实现接口自动注册
- 三方应用信息的自动配置
三方应用使用提供的客户端Client,在启动时候,Client 就会发起注册admin的接口/springmvc-register 此时就会将三方应用的ip,port 协议等信息自动填写到selector的handler字段中,同时出发数据同步
这里divide支持多个三方应用发起连接,所以这里就会涉及到负载均衡。
发起请求如何通过Divide进行代理转发
下面处理流程是采用了插件链SoulPluginChain方式进行处理的。
- 为了演示和debug,我这里只打开了divide插件
- 我们上节知道Request请求先到SoulWebHandler的Handler方法,这里我们看到除了业务插件之外还有一些与通信Http协议相关的插件Filter
- 经过按照顺序执行,执行到了DividePlugin的doExecute
- 获取请求的Attribute("context")
- 根据选择器id 获取转发的第三方应用List
3.根据转发List,规则处理Handler所配置的负载均衡器再加上转发远端的ip找到对应的最后转发Host
DivideUpstream divideUpstream = LoadBalanceUtils.selector(upstreamList, ruleHandle.getLoadBalance(), ip);
具体负载均衡的算法讲解下一节介绍
4.应用发起的请求是 localhost:9195/http/order/findById?id=3 , 经过DividePlugin再次根据规则拼接成真正的发起请求的URL
5.将真正的URL填充到exchange中,提交给WebClientPlugin发送请求的处理器
6.中间经过拼接组织信息,发送到真正的服务,然后最后返回给调用方式在WebClientResposePlugin进行处理
Reactor 之 subscribeOn 与 publishOn
概述
在 Spring Reactor 项目中，有两个出镜较少的方法：publishOn 和 subscribeOn。这两个方法的作用是指定执行 Reactive Streaming 的 Scheduler（可理解为线程池）。
为何需要指定执行 Scheduler 呢？一个显而易见的原因是：组成一个反应式流的代码有快有慢，例如 NIO、BIO。如果将这些功能都放在一个线程里执行，快的就会被慢的影响，所以需要相互隔离。这是这两个方法应用的最典型的场景。
Scheduler
在介绍 publishOn 和 subscribeOn 方法之前，需要先介绍 Scheduler 这个概念。在 Reactor 中，Scheduler 用来定义执行调度任务的抽象。可以简单理解为线程池，但其实际作用要更多。先简单介绍 Scheduler 的实现：
-
Schedulers.elastic(): 调度器会动态创建工作线程，线程数无上界，类似于Execturos.newCachedThreadPool() -
Schedulers.parallel(): 创建固定线程数的调度器，默认线程数等于 CPU 核心数。
关于 Scheduler 的更多作用留在以后介绍。
这就是为什么SoulWebHandler 会使用调度器的原因,为了响应式处理都在独立的线程中执行,这样做到真正的异步
publishOn 与 subscribeOn
接下来进入正题。先看两个例子（来自 https://github.com/reactor/lite-rx-api-hands-on）
publishOn 的例子
Mono<Void> fluxToBlockingRepository(Flux<User> flux,
BlockingRepository<User> repository) {
return flux
.publishOn(Schedulers.elastic())
.doOnNext(repository::save)
.then();
}
subscribeOn 的例子
Flux<User> blockingRepositoryToFlux(BlockingRepository<User> repository) {
return Flux.defer(() -> Flux.fromIterable(repository.findAll()))
.subscribeOn(Schedulers.elastic());
}
这里的 repository 的类型是 BlockingRepository，指的是会导致线程阻塞的数据库操作的集合，例如 JPA、MyBatis 等基于 JDBC 技术实现的 DAO。
在第一个例子中，在执行了 publishOn(Schedulers.elastic()) 之后，repository::save 就会被 Schedulers.elastic() 定义的线程池所执行。
而在第二个例子中，subscribeOn(Schedulers.elastic()) 的作用类似。它使得 repository.findAll()（也包括 Flux.fromIterable）的执行发生在 Schedulers.elastic() 所定义的线程池中。
从上面的描述看，publishOn 和 subscribeOn 的作用类似，那两者的区别又是什么？
两者的区别
简单说，两者的区别在于影响范围。publishOn 影响在其之后的 operator 执行的线程池，而 subscribeOn 则会从源头影响整个执行过程。所以，publishOn 的影响范围和它的位置有关，而 subscribeOn 的影响范围则和位置无关。
看个 publishOn 和 subscribeOn 同时使用的例子
Flux.just("tom"）
.map(s -> {
System.out.println("[map] Thread name: " + Thread.currentThread().getName());
return s.concat("@mail.com");
})
.publishOn(Schedulers.newElastic("thread-publishOn"))
.filter(s -> {
System.out.println("[filter] Thread name: " + Thread.currentThread().getName());
return s.startsWith("t");
})
.subscribeOn(Schedulers.newElastic("thread-subscribeOn"))
.subscribe(s -> {
System.out.println("[subscribe] Thread name: " + Thread.currentThread().getName());
System.out.println(s);
});
输出结果如下：
[map] Thread name: thread-subscribeOn-3
[filter] Thread name: thread-publishOn-4
[subscribe] Thread name: thread-publishOn-4
tom@mail.com
从上面的例子可以看出，subscribeOn 定义在 publishOn 之后，但是却从源头开始生效。而在 publishOn 执行之后，线程池变更为 publishOn 所定义的。
实际用途
这里介绍 publishOn 和 subscribeOn 的一种实际用途，那就是反应式编程和传统的，会导致线程阻塞的编程技术混用的场景。其实开头两个例子已经解释了这个场景。
在第一个 publishOn 的例子中，repository::save 会导致线程阻塞，为了避免造成对其它反应式操作的影响，便使用 publishOn 改变其执行线程。
在第二个 subscribeOn 的例子中，repository.findAll() 会导致线程阻塞。但是其是源头的 publisher，因此不能使用 publishOn 改变其 执行线程。这时就需要使用 subscribeOn，在源头上修改其执行线程。
这样，通过 publishOn 和 subscribeOn 就在反应式编程中实现了线程池隔离的目的，一定程度上避免了会导致线程阻塞的程序执行影响到反应式编程的程序执行效率。
局限性
使用 publishOn 和 subscribeOn 只能在一定程度上避免反应式编程代码执行的效率被影响。因为用来隔离的线程池资源终归是有限的，比如当出现数据库资源不足、慢查询等问题时，对应的线程池资源如果被耗尽，还是会使整个反应式编程的执行效率受到影响。
目前，Redis、Mongo、Couchbase 等非关系型数据库均有相应的反应式编程的解决方案，但是关系型数据库却没有理想的方案。一个重要原因是 JDBC 本身就是一个阻塞式的 API，根本不可能让其适应反应式编程。因此需要一个新的方案。目前 Oracle 正在推动 ADBA (Asynchronous Database Access API)，使得关系型数据库可以满足异步编程的需要。但是，因为是 Oracle 主导，大家都懂的，所以目前前景还不是很明朗。另外一个技术方案是 Spring 推动的 R2DBC，从名字上来看就很像是 JDBC 在反应式编程领域的对应的解决方案。目前可以支持 PostgreSQL，支持 MySQL 目前还尚需时日。
总结
其实到这里,我们就可以简单的把之前分析的从数据的注册到数据的同步,在到插件的注册,在到请求的入口定位，然后到真正的处理流程。全部分析完了，后面就是对具体的细节进行分析讲解。
