Soul 网关源码阅读(六)Sofa 请求处理概览
Soul 网关源码阅读(六)Sofa 请求处理概览
简介
今天来探索一下 Sofa 请求处理流程,看看和前面的 HTTP、Dubbo 有什么异同
Sofa 示例运行
PS:如果请求加上参数运行不成功,请更新最新版本,此问题在新版本中已经修复:https://blog.csdn.net/baidu_27627251/article/details/112726694 Add sofa param resolve service
首先运行下官方的 Sofa 示例,首先启动下 mysql 和 zookeeper,这里使用 docker 启动:
然后运行 Soul-admin,Soul-Bootst,在管理图界面起用 sofa 插件
运行官方示例:soul-examples --> soul-examples-sofa
这里有个坑,需要注意,启动后,bootstrap 打印日志中没有 sofa 插件,请求一直失败
经过探索和老哥的讨论,发现是每天起用 sofa 的相关依赖
我们在 Bootstrap 的 pom.xml 文件中添加下面的依赖,然后重启
然后查看日志打印,出现了 sofa 相关的插件
日志中还打印了成功加载 sofa 相关的 metadata
访问链接: http://localhost:9195/sofa/findAll ,成功返回如下请求
源码解析
PS:Debug 时间过程,会导致超时,这是正常的
首先找到我们非常熟悉的切入点函数: SoulWebHandler ,在下面的方法中打上断点,然后逐步进入每个 plugin 观察其行为
GlobalPlugin
进入其中,执行处理逻辑,通过上篇的分析,我们知道大致作用是将请求类型放入 exchange 中
SignPlugin/WafPlugin/RateLimiterPlugin/HystrixPlugin/Resilience4JPlugin
进入其中,但 plugin 没有起用,不执行逻辑
DividePlugin/WebClientPlugin/WebSocketPlugin
通过类型判断,跳过,不执行
BodyParamPlugin
这个 plugin 在 dubbo 的时候也是要执行,我们来看看它干了写啥事。从下面逻辑中大概能看出先判断是否符合执行条件,然后将请求地址替换成真实的后端地址
这里有个非常有趣的现象,我们第四篇分析中,dubbo 也走了一模一样的类,在上面函数逻辑中,我们看出它并不能兼容 dubbo,那 dubbo 是如何走这个类的呢?
通过调试我们发现,当同时启动 dubbo 和 sofa 的时候,会生成两个 BodyParamPlugin,名称是一模一样的,但里面的判断类型换了,很神奇,猜测这个类是动态生成之类的手段,这里先不探索了,可以后面研究研究
AlibabaDubboPlugin
通过类型判断,跳过
SofaPlugin
这个从名字就看出来是核心类,我们看看它具体干了啥。通过下面注释的地方,可以看出和 dubbo 请求的非常的相像。进行路由匹配,成功后 rpc 调用,获得结果后放入 exchange 中
MonitorPlugin
不跳过,但插件没有开启
DubboResponsePlugin/WebClientResponsePlugin
通过类型判断,跳过执行
SofaResponsePlugin
通过上几篇分析和名字能猜出来是将响应返回给客户端的,通过下面代码的逻辑也可以看出
总结
上面的 plugin 流程大致如下:
GlobalPlugin : 将请求类型置入
SignPlugin : 跳过不执行逻辑
WafPlugin : 跳过不执行逻辑
RateLimiterPlugin : 跳过不执行逻辑
HystrixPlugin : 跳过不执行逻辑
Resilience4JPlugin : 跳过不执行逻辑
DividePlugin : 跳过不执行逻辑
WebClientPlugin : 跳过不执行逻辑
WebSocketPlugin : 跳过不执行逻辑
BodyParamPlugin : 执行 RPC 的请求路径替换,替换成真实的服务器后端路径,作用类似于 dividePlugin;不同 rpc 有相关的这个插件名,也就是会有多个 BodyParamPlugin
AlibabaDubboPlugin : 跳过不执行逻辑
SofaPlugin : 发送请求到后台服务器,拿到结果,写入 exchange
MonitorPlugin : 跳过不执行逻辑
DubboResponsePlugin : 跳过不执行逻辑
WebClientResponsePlugin : 跳过不执行逻辑
SofaResponsePlugin : 从 exchange 中拿到响应,发送给客户端
经过这几篇的分析,我们进一步优化我们对 Soul 网关的请求流程,大致如下:
更新了我们对处理流程中一些类的认知:
通过上篇分析,得到 GlobalPlugin 的具体作用,是置入请求类型
BodyParamPlugin 作用类似于 dividePlugin,能进行路由匹配,匹配后将路径修改真实的后端服务器路径;并且能动态的生成同名的但针对不同 rpc 实现的 plugin
版权声明: 本文为 InfoQ 作者【萧】的原创文章。
原文链接:【http://xie.infoq.cn/article/b6aaa13c2d1a0d9a0c15359b4】。
本文遵守【CC-BY 4.0】协议,转载请保留原文出处及本版权声明。
评论