1月28日作业
- .响应式编程与插件链调用过程分析
- 总结
引子
前面我们介绍了divide插件,dubbo插件的底层实现原理以及他们是如何对http请求进行处理,转发至注册到网关的某一服务。那么疑问来了,soul网关是如何通过soul-bootstrap
这个启动类实现响应式编程,插件链又是如何在这过程中被调用呢?本章将带着这些疑问,进行进一步探究。
Soul响应式编程
我们可以在soul-bootstrap
中看到有配置项SoulNettyWebServerFactory
,在项目启动时加载一个nettyHttpServer,同时配置相应的tcp配置。核心代码如下
如果我们看一下pom.xml
文件,发现soul网关的启动依赖soul-spring-boot-starter-gateway
, 而这个依赖项又依赖soul-web
可以看出soul-web
在soul网关启动的一个重要的依赖项。我们追踪进入soul-web的自动装配类SoulConfiguration
,发现自动装配了SoulWebHandler
, DispatchHandler
, PluginDataSubscriber
, 以及针对dubbo, sofa等插件的Resolver解析器。
在SoulWebHandler
里实现了WebHandler
, 并在初始化阶段开启一个handler的线程池,以及重写了handle
方法,来调用soulPluginChain来处理web请求。使用Webflux来实现响应式编程。
Soul插件链的调用源码解析
那么soul插件链是如何调用的呢?主要由DefaultSoulPluginChain
中的execute
方法来执行调用。该方法会递归调用soulPluginChain里的每个插件,并对插件进行检查是否应该skip.我们以divide插件为例,可以看到覆写了skip
方法,核心代码如下:
当我们发起HTTP请求时,其中 rpcType=http,正好对应 DividePlugin 的RPC类型,因此不会跳过DividePlugin,而会跳过其他 RPC 类型的插件,比如说 SpringCloudPlugin, SofaPlugin, DubboPlugin。
同时对应每个插件都实现了各自的doExecute方法,以ApacheDubboPlugin
为例,核心实现方法如下:
值得注意的是,如果在插件doExecute过程中如果有任何异常或者错误抛出,则会中断插件链的调用,返回WebFluxResultUtils.result(exchange, error)
如果顺利执行,则通过chain.execute(exchange)
来继续执行下一个插件。
总结
今天大致理清了soul-bootstrap是如何将soul网关各个组件拼接起来,并通过webflux实现响应式编程的原理。最终又回顾了插件链具体是怎样调用的。接下来会继续进行对不同插件实现doExecute的原理分析。