共计 2726 个字符，预计需要花费 7 分钟才能阅读完成。
为了进一步增强网络安全防备工作，近期对网关服务做了相干的平安降级，其中变动最大的一点是，网关不再提供 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%，比原先降落了一半左右！
文 / 簌语
关注得物技术，携手走向技术的云端
