spring cloud 软件系统开发定制性能瓶颈分析及优化
背景
软件系统开发定制在公司的开放平台中需软件系统开发定制要对外保留接口，软件系统开发定制此时需要一个公共层来软件系统开发定制处理公共逻辑，限流，验证权限，所以需要一个网关- 1
技术选型
此处从网上贴图
网关整体设计 及架构
优化背景
在上线之后，对接服务商增多，挂载接口增多的情况下，需要测试性能瓶颈。此时发现和官方给出的数据差别较大
直接
去掉日志之后
性能有提升，但是还是不符合预期，此时观察到jvm的情况，YGC次数太多
修改jvm参数
此时性能提升，但是还不满意，继续探索
怀疑是路由数量导致的问题，进行验证
验证之后，确实是路由数量会导致吞吐量的下降，进行代码分析
性能瓶颈代码分析
DispatcherHandler ：接收到请求，匹配 HandlerMapping ，此处会匹配到
RoutePredicateHandlerMapping 。
RoutePredicateHandlerMapping ：接收到请求，匹配 Route 。
读RoutePredicateHandlerMapping 源码发现：获取具体的路由会：
调用 RouteLocator#getRoutes() 方法，获得全部 Route ，
并调用 Predicate#test(ServerWebExchange) 方法，顺序匹配一个 Route。
此时会遍历缓存中的路由列表，然后获取每一个路由的断言器
，将请求信息传入断言器工厂，去判断是否和当前的路由匹配，
如果情况最糟糕时候，最终匹配到的路由排在
最后一个，此处就会出现性能问题
改造方式1
从官网看到一个修改的思路，结合我们SCG对Api的设计，因为路由和Api是一一对应的，知道Api其实已经可以知道路由信息了，不用走gateway自己那套功能强大但性能有损耗的路由规则解析，我们何不在构建路由信息的时候同时增加一个缓存Map，key为路由ID，这个ID是可以自定义的，我们可以让Api的唯一标识作为路由的ID，Map的value就是路由的信息，这样当请求过来，根据我们的协议规则可以解析出Api，有了Api就可以通过这个Map拿到对应的路由对象了，可以绕过RoutePredicateHandlerMapping#lookupRoute的原有逻辑。
将原有的挨个匹配改为key-value的精准匹配，所以需要修改一下源代码，官方已经给出了修改方法，结合我们的情况，觉得重写一下底层的RoutePredicateHandlerMapping和CachingRouteLocator
修改CachingRouteLocator代码如下：
RoutePredicateHandlerMapping代码修改
增加以下代码
修改完成之后，逻辑就是在原有的路由保存代码中，增加一个新的map缓存，key为路由ID，在匹配代码前从请求中获取路由的唯一标识，路由ID，然后精准匹配，匹配不到走原有逻辑
改造方式2
这部分代码不展示了，只说实现的逻辑，改造完成之后的结果
整个优化过程结果展示
改造思路3
这个只是一个方向，本人尚未实现