其他分享
首页 > 其他分享> > 【得物技术】网关路由匹配性能优化

【得物技术】网关路由匹配性能优化

作者:互联网

为了进一步加强网络安全防范工作,近期对网关服务做了相关的安全升级,其中变化最大的一点是,网关不再提供 URI 模糊匹配的模式,形如 /api/v1/app/order/** 这样的配置已经不在支持,相信很多小伙伴已经感受到了日常开发上线的不便,但是需要理解的是,随着公司的体量的迅速发展,各方面越来越规范化,安全方面加强管控显然还是非常必要的。

首先看下得物流量传递的基本路径:

APP 网关流量路径:四层高防 --> 阿里云 SLB --> Gateway --> 业务服务/业务网关(提供协议转化 &接口聚合)

通常来说与业务方打交道的最多的是 gateway 服务,很多萌新可能不是很理解网关具体在干啥,这里做个简要说明,网关最大的作用是提供流量分发,同时具备流量管控,防爬,黑白名单,基本鉴权,接口超时,灰度等常见功能;小伙伴们日常开发中最长用到的就是流量转发,比如新起一个服务需要对外网暴露接口,此时就需要在网关的路由管理上进行配置。

所以 Spring gateway 的路由匹配就成了一个非常核心的关键功能,这里我们翻阅一下 Spring gateway 的源码。

由于 Spring gateway 使用 webflux 技术,整体的代码风格较为诡异。

这里简单介绍下 webflux 的基本概念:

flux 表示 1~N 数据元素

mono ,表示 0~1 个数据元素,

针对数据流的所有操作,在没有订阅之前都不会被触发,只有调用了 subscribe 方法后才会实际触发。

图一*

这里我们看下 DispatcherHandler 的 handle 方法,该方法会进行 webHandler 的适配,对于网关来说这里主要匹配的是 RoutePredicateHandlerMapping 这一对象,我们可以从 hadlerMappings 对象中看到:

RoutePredicateHandlerMapping 中的 webHandle 为 FilteringWebHandler 该 handle 中包含了 gateway 自带的以及网关自定义的共 28 个 GolobalFilter

讲到这里很多小伙伴可能会好奇,这个路由匹配到底是在哪儿做的呢,别急,我们慢慢开趴!

按照图一所示,选中 mapping 后会获取 Handler,而获取 handler 后优会调用 invokeHandler 方法,那么我么不妨先到 getHandler 方法中看看,点开 RoutePredicateHandlerMapping 源码,我们郁闷的发现并没有 getHandler 方法,而只有 getHandlerInternal 方法,仔细看下 RoutePredicateHandlerMapping 的继承关系发现该类继承了 AbstractHandlerMapping, 而 AbstractHandlerMapping 中 getHandler 方法早已存在,实现了 HandlerMapping 接口同时也做了部分实现 ;废话不多说,源码底下无内鬼!!

原来 getHandlerInternal 是在 getHandler 方法中被调用的。这就解释得通了,

仔细观察了 getHandler 中的逻辑,并没有路由匹配的逻辑,此时嫌疑最大的当属 RoutePredicateHandlerMapping 的 getHandlerInternal 了!

不出所料,lookupRoute 没跑了!!

lookupRoute 的代码很简单,核心逻辑为简单的匹配,同时添加错误处理,在匹配成功的情况下会把路由信息添加到 ServerWebExchange 中的 attributes 中,代码如下:

观察 filterWhen,我们会发现这是一个 for 循环匹配,也就是说,效率为 O n, 在路由信息比较多的情况下非常糟糕,当然这不能怪 Spring,毕竟 gateway 设计之初,是支持各种正则,模糊匹配的,这种要求下,做到 O 1 的效率并不现实 ,但是结合得物当前的使用场景,我们可以做进一步的优化:

由于新的路由添加为精确模式,也就是每个接口对应一个路由,这种前提下,我们很显然的想到了 HASH 算法,由于对于 pathVariable 模式的 path 也不再支持(小伙伴们可以思考下,这种接口有什么缺点) ,在收到请求的时候直接提取 path 部分,通过 hash 的方式获取到对应的路由信息,改造后的路由查找逻辑如下所示:

findRoute()方法中的逻辑非常简单的:

为了保证并发安全,这里的 pathRouteMap 为 ConcurrentHashMap ,其实修改为 HashMap 也是可以的,因为路由匹配时,对 map 是只读操作,更新时候是整体 map 引用替换:这里附上刷新路由缓存信息的代码

由于更新路由信息的操作属于高危且核心的操作,对于一个批次的更新最好能够原子性完成,这里我们引入了 Copy on write 的思路,修改的时候,先修改 bakMap ,等到 bakMap 中的全部路由信息更新完成后,我们将实际使用的 map 引用指向 bakMap, 同时将 bakMap 设置为空。此外更新路由的操作一般来说都是事件触发异步完成,因此对于性能要求并不高,这里加上锁进一步保证路由更新完整性,防止在多个线程调用时,map 与 bakMap 之间出现不匹配的情况!

需要指出的是 gateway 的路由查找逻辑依赖于 CachingRouteLocator, 该类监听路由更新事件,实际的路由刷新通过发布事件的方式完成。观察源码,我们发现处理路由刷新事件时调用了 fetch 方法;

同时在初始化阶段以及缓存命中失效阶段时也调用了 fetch 方法(这里缓存是 gateway 自带的缓存机制,而非我们添加的 Map 缓存)

因此我们可以在 fetch 方法中加入 refreshPathRouteMap() 方法;

在 lookupRoute 方法中的 this.routeLocator.getRoutes() 实际调用的是 CachingRouteLocator#getRoutes()方法。此方法直接返回被缓存的的信息,这里的缓存指的是 gateway 自带的

routes = CacheFlux.lookup(cache, CACHE_KEY, Route.class).onCacheMissResume(this::fetch);

逻辑简单翻译一下,就是如果缓存命中失败会调用 fetch 方法重新加载路由信息。

至此,路由匹配的逻辑大致分析完成!其实对于之前的 /api/v1/app/order/** 这种模式的路由也可以通过 hash 方式进行加速,只需要将 * * 去掉,作为 map 的 key,在处理请求的时候,尝试获取请求的前缀进行匹配即可!

最终我们实战观察一下改进的实际效果:

可以发现,实际的 CPU 占用从原来的平均 24% --> 12% ,比原先下降了一半左右!

文/簌语

关注得物技术,携手走向技术的云端

标签:网关,缓存,匹配,得物,方法,gateway,路由
来源: https://blog.csdn.net/SmartCodeTech/article/details/119485174