一、事务布景
老网关运用 Spring Cloud Gateway （下称SCG）技能结构搭建，SCG根据webflux 编程范式，webflux是一种呼应式编程理念，呼应式编程关于提高体系吞吐率和功用有很大帮助; webflux 的底层构建在netty之上功用表现优异；SCG归于spring生态的产品，具备开箱即用的特点，以较低的运用本钱助力得物前期的事务快速开展；可是跟着公司事务的快速开展，流量越来越大，网关迭代的事务逻辑越来越多，以及安全审计需求的不断晋级和安稳性需求的提高，SCG在以下几个方面逐渐露出了一系列的问题。
网络安全
从网络安全视点来讲，对公网露出接口无疑是一件危险极高的事情，网关是对外网络流量的重要桥梁，前期的接口露出选用泛化路由的形式，即经过正则办法（ /api/v1/app/order/** ）的路由规矩敞开接口，单个运用服务往往只装备一个泛化路由，后续上线新接口时外部可以直接拜访；这带来了极大的安全危险，许多时分事务开发的接口或许仅仅是内部调用，可是一不小心就被泛化路由敞开到了公网，乃至许多时分没人讲得清楚某个服务详细有多少接口归于对外，多少对内；另一方面从监控数据来看，黑产势力也在不断对咱们的接口做浸透打听。
协同功率
引进了接口注册机制，一切对外露出接口逐个注册到网关，未注册接口不行拜访，安全的问题得到了处理但一起带来了功用问题，SCG选用遍历办法匹配路由规矩，接口注册形式推广后路由接口注册数量迅速提高到3W ，路由匹配功用呈现严峻问题；泛化路由的时代，一个服务只要一个路由装备，改变频率很低，装备作业由网关关开发人员担任，功率尚可，接口注册形式将路由作业搬运到了事务开发同学的身上，这就得引进一套完整的路由审核流程，以提高协同功率；由于路由信息前期都存在装备中心，一起这么大的数据量给装备中心也带来极大的压力和安稳性危险。
功用与维护本钱
事务迭代的不断增多，也使得API网关堆积了许多的事务逻辑，这些事务逻辑分散在不同的filter中，为了下降开发本钱，网关只要一套主线分支，不同集群部署的代码彻底相同，可是不同集群的事务特点不同，所需求的filter 逻辑是不相同的；如内网网关集群简直没什么事务逻辑，可是App集群或许需求几十个filter的逻辑协同作业；这样的一套代码对内网网关而言，存在着许多的功用糟蹋；怎么平衡维护本钱和运转功率是个需求考虑的问题。
安稳性危险
API网关作为基础服务，承载全站的流量出入，安稳性无疑是第一优先级，但其定位决议了绝不行能是一个简略的署理层，在安稳运转的一起仍然需求承受许多事务需求，例如C端用户登录下线才干，App强升才干，B端场景下的鉴权才干等；很难幻想较长一段时刻以来，网关都坚持着双周一次的发版频率；频频的发版也带来了一些问题，实例发动初期有许多资源需求初始化，此刻承受的流量处理时刻较长，存在着明显的接口超时现象；前期的每次发版简直都会导致下流服务的接口短时刻内超时率大幅提高，而且往往触及多个服务一同呈现相似状况；为此乃至拉了一个网关发版公告群，提前置顶发版公告，让事务同学和NOC有一个心里预期；在发布晋级期间尽或许让事务服务无感知这是个刚需。
定制才干
流量灰度是网关最常见的功用之一，关于新版本迭代，事务服务的某个节点发布新版本后希望引进少部分流量试跑观察，但很遗憾SCG原生并不支撑，需求对负载均衡算法进行手动改写才干够，此外根据流量特征的定向节点路由也需求手动开发，在SCG中整个负载均衡算法归于比较中心的模块，不对外直接露出，存在较高的改造本钱。
B端事务和C端事务存在着很大的不同，例如对接口的呼应时刻的忍耐度是不相同的，B端场景下下载一个报表用户可以承受等候10s或许1分钟，可是C端用户现在没有这个耐性。作为署理层针对以上的场景，咱们需求针对不同接口定制不同的超时时刻，原生的SCG明显也不支撑。
比如此类的定制需求还有许多，咱们并不寄希望于开源产品可以开箱即用满意悉数需求，但至少定制性拓宽性满足好。上手改造本钱低。
二、技能痛点
SCG首要运用了webflux技能，webflux的底层构建在reactor-netty之上，而reactor-netty构建于netty之上；SCG可以和spring cloud 的技能栈的各组件，完美适配，做到开箱即用，以较低的运用本钱助力得物前期的事务快速开展；可是运用webflux也是需求支付必定本钱，首要它会额定增加编码人员的心智负担，需求了解流的概念和常用的操作函数，比如map, flatmap, defer 等等；其次异步非堵塞的编码办法，充斥着许多的回调函数，会导致次序性事务逻辑被分裂开来，增加代码阅览理了解本钱；此外经过多方面评估咱们发现SCG存在以下缺点：
内存走漏问题
SCG存在较多的内存走漏问题，排查困难，且官方迟迟未能修正，长期运转会导致服务触发OOM并宕机；以下为github上SCG官方开源库房的待处理的内存走漏问题，大约有16个之多。
SCG内存走漏BUG
下图可以看到SCG在长期运转的进程中内存运用一直在增加，当增加到机器内存上限时当时节点将不行用，联系到网关单节点所承受的QPS 在几千，可想而知节点宕机带来的危害有多大；一段时刻以来咱们需求对SCG网关做定时重启。
SCG出产实例内存增加趋势
呼应式编程范式杂乱
根据webflux 中的flux 和mono ，在对request和response信息读取修正时，编码杂乱度高，代码了解困难，下图是对body信息进行修正时的代码逻辑。
对requestBody进行修正的办法
多层笼统的功用损耗
尽管比较于传统的堵塞式网关，SCG的功用现已满足优异，但比较原生的netty仍然比较低下，SCG依靠于webflux编程范式，webflux构建于reactor-netty之上，reactor-netty 构建于netty 之上，多层笼统存在较大的功用损耗。
SCG依靠层级
一般以为程序调用栈越深功用越差；下图为只要一个filter的状况下的调用栈，可以看到存在许多的 webflux 中的 subscribe() 和onNext() 办法调用,这些办法的履行不相关任何事务逻辑，归于纯粹的结构运转层代码，粗略估算下没有引进任何逻辑的状况下SCG的调用栈深度在 90 ，假如引进多个filter处理不同的事务逻辑，线程栈将进一步加深，当时网关的事务杂乱度实践栈深度会到达120左右，也便是差不多有四分之三的非事务栈损耗，这个份额是有点夸张的。
SCG filter调用栈深度
路由才干不完善
原生的的SCG并不支撑动态路由办理，路由的装备信息经过许多的KV装备来做，均匀一个路由装备需求三到四条KV装备信息来支撑，这些装备数据一般放在比如Apollo或许ark 这样的装备中心，即使是增加了新的装备SCG并不能动态识别，需求引进动态改写路由装备的才干。另一方面路由匹配算法经过遍历一切的路由信息逐个匹配的形式，当接口级别的路由数量急剧胀大时，功用是个严峻问题。
SCG路由匹配算法为On时刻杂乱度
预热时刻长，冷发动RT尖刺大
SCG中LoadBalancerClient 会调用choose办法来挑选合适的endpoint 作为本次RPC建议调用的实在地址，由所以懒加载，只要在有实在流量触发时才会加载创立相关资源；在触发底层的NamedContextFactory#getContext 办法时存在一个大局锁导致，woker线程在该锁上许多等候。
NamedContextFactory#getContext办法存在大局锁
SCG发布时超时报错增多
定制性差，数据流操控耦合
SCG在开发运维进程中现已呈现了较多的针对源码改造的场景，如动态路由，路由匹配功用优化等；其规划理念老旧，操控流和数据流混合运用，架构不明晰，如对路由办理操作仍然耦合在filter中，即使引进spring mvc办法办理，仍然绑定运用webflux编程范式，一起也无法做到操控流端口独立，存在必定安全危险。
filter中对路由进行办理
三、计划调研
抱负中的网关
归纳事务需求和技能痛点，咱们发现抱负型的网关应该是这个样子的：
- 支撑海量接口注册，并可以在运转时支撑动态增加修正路由信息，具备超卓路由匹配功用
- 编程范式尽或许简略，下降开发人员心智负担，一起最好是开发人员较为了解的语言
- 功用满足好，至少要等同于现在SCG的功用，RT99线和ART较低
- 安稳性好，无内存走漏，可以长时刻继续安稳运转，发布晋级期间要尽或许下流无感
- 拓宽才干强，支撑超时定制，多网络协议支撑，http，Dubbo等，生态完善
- 架构规划明晰，数据流与操控流别离，集成UI操控面
开源网关比照
根据以上需求，咱们对市面上的常见网关进行了调研，以下几个开源计划比照。
结合当时团队的技能栈，咱们倾向于挑选Java技能栈的开源产品，仅有可选的只要zuul2 ，可是zuul2路由注册和安稳性方面也不可以满意咱们的需求，也没有完结数控别离的架构规划。因而唯有走上自研之路。
四、自研架构
一般而言署理网关分为通明署理与非通明署理，其首要区别在于关于流量是否存在侵入性，这儿的侵入性首要是指对恳求和呼应数据的修正；明显API Gateway的定位决议了必定会对流量进行数据调整，常见的调整首要有 增加或许修正head 信息，加密或许解密 query params head ,以及 requestbody 或许responseBody，可以说http恳求的每一个部分数据都存在修正的或许性，这要求署理层必需求彻底解析数据包信息，而非简略的做一个路由器转发功用。
传统的服务器架构，以reactor架构为主。boss线程和worker线程的明确分工，boss线程担任衔接树立创立；worker线程担任现已树立的衔接的读写事情监听处理，一起会将部分杂乱事务的处理放到独立的线程池中，从而避免worker线程的履行时刻过长影响对网络事情处理的及时性；由于网关是IO密集型服务，相对来说核算内容较少，可以不必引进这样的事务线程池；直接根据netty 原生reactor架构完结。
Reactor多线程架构
为了只求极致功用和下降多线程编码的数据竞争，单个恳求从接纳到转发后端，再到接纳后端服务呼应，以及终究的回写给client端，这一系列操作被规划为彻底闭合在一个workerEventLoop线程中处理；这需求worker线程中履行的IO类型操作悉数完结异步非堵塞化，确保worker线程的高速运转；这样的架构和NGINX很相似；咱们称之为 thread-per-core形式。
API网关组件架构
数据流操控流别离
数据面板专心于流量署理，不处理任何admin 类恳求，操控流监听独立的端口，接纳办理指令。
五、中心规划
恳求上下文封装
新的API网关底层仍然根据Netty，其自带的http协议解析handler可以直接运用。根据netty结构的编程范式，需求在初始化时逐个注册用到的 Handler。
Client到Proxy链路Handler履行次序
HttpServerCodec 担任HTTP恳求的解析；关于体积较大的Http恳求，客户端或许会拆成多个小的数据包进行发送，因而在服务端需求适当的封装拼接，避免收到不完整的http恳求；HttpObjectAggregator 担任整个恳求的组装组合。
拿到HTTP恳求的悉数信息后在事务handler 中进行处理；假如恳求体积过大直接扔掉；运用ServerWebExchange 目标封装恳求上下文信息，其中包含了client2Proxy的channel, 以及担任处理该channel 的eventLoop 线程等信息，考虑到整个恳求的处理进程中或许在不同阶段传递一些拓宽信息，引进了getAttributes 办法 用于存储需求传递的数据；此外ServerWebExchange 接口的根本遵从了SCG的规划标准，确保了在搬迁事务逻辑时的最小化改动；详细到完结类，可以参阅如下代码：
@Getter
public class DefaultServerWebExchange implements ServerWebExchange {
private final Channel client2ProxyChannel;
private final Channel proxy2ClientChannel;
private final EventLoop executor;
private ServerHttpRequest request;
private ServerHttpResponse response;
private final Map<String, Object> attributes;
}
DefaultServerWebExchange
Client2ProxyHttpHandler作为中心的进口handler 担任将接纳到的FullHttpRequest 进行封装和构建ServerWebExchange 目标，其中心逻辑如下。可以看到关于数据读取封装的逻辑较为简略，并没有植入常见的事务逻辑，封装完目标后随即调用 Request filter chain。
@Override
protected void channelRead0(ChannelHandlerContext ctx, FullHttpRequest fullHttpRequest) {
try {
Channel client2ProxyChannel = ctx.channel();
DefaultServerHttpRequest serverHttpRequest = new DefaultServerHttpRequest(fullHttpRequest, client2ProxyChannel);
ServerWebExchange serverWebExchange = new DefaultServerWebExchange(client2ProxyChannel,(EventLoop) ctx.executor(), serverHttpRequest, null);
// request filter chain
this.requestFilterChain.filter(serverWebExchange);
}catch (Throwable t){
log.error("Exception caused before filters!n {}",ExceptionUtils.getStackTrace(t));
ByteBufHelper.safeRelease(fullHttpRequest);
throw t;
}
}
Client2ProxyHttpHandler 精简后的代码
FilterChain规划
FilterChain可以处理异步恳求发送出去后，还没收到呼应，可是次序逻辑现已履行完结的为难；例如当咱们在上文的。
channelRead0 办法中建议某个鉴权RPC调用时，出于功用考虑只能运用非堵塞的办法，按照netty的非堵塞编码API终究要引进相似如下的 callback 机制，在事务逻辑上在没有收到RPC的呼应之前该恳求的处理应该“暂停”，等候收到呼应时才干继续后续的逻辑履行; 也便是下面代码中的下一步履行逻辑并不能履行，正确的做法是将nextBiz() 办法包裹在 callBack() 办法内，由callBack() 触发后续逻辑的履行；这仅仅建议一次RPC调用的状况，在实践的的日常研制进程中存在着鉴权，风控，集群限流（Redis）等屡次RPC调用，这就导致这样的非堵塞代码编写将反常杂乱。
ChannelFuture writeFuture = channel.writeAndFlush(asyncRequest.httpRequest);
writeFuture.addListener(future -> {
if(future.isSuccess()) {
callBack();
}
}
);
nextBiz()；
非堵塞调用下的事务逻辑编排
关于这样的杂乱场景，选用filterChain形式可以很好的处理；首要RequestFilterChain().filter(serverWebExchange); 后不存在任何逻辑；建议恳求时 ，当时filter履行完毕，由于此刻没有调用chain.filter(exchange); 所以不会继续履行下一个filter，发送恳求到下流的逻辑也不会履行；当时恳求的处理流程暂时中止，eventloop 线程将切换到其他恳求的处理进程上；当收到RPC呼应时，chain.filter(exchange) 被履行，之前中止的流程被重新拉起。
public void filter(ServerWebExchange exchange) {
if (this.index < filters.size()) {
GatewayFilter filter = filters.get(this.index);
DefaultGatewayFilterChain chain = new DefaultGatewayFilterChain(this, this.index 1);
try {
filter.filter(exchange, chain);
}catch (Throwable e){
log.error("Filter chain unhandle backward exception! Request path {}, FilterClass: {}, exception: {}", exchange.getRequest().getPath(), filter.getClass(), ExceptionUtils.getFullStackTrace(e));
ResponseDecorator.failResponse(exchange,500, "网关内部过错！filter chain exception！");
}
}
}
根据filterChain的调用形式
关于filter的履行需求定义先后次序，这儿参阅了SCG的计划，每个filter回来一个order值。不同的地方在于DAG的规划不允许 order值重复，由于在order重复的状况下，很难界定到底哪个Filter 先履行，存在模糊地带，这不是咱们期望看到的；DAG中的Filter 履行次序为order值从小到大，且不允许order值重复。为了易于了解，这儿将Filter拆分为了 requestFilter，和responseFilter；别离代表恳求的处理阶段 和拿到下流呼应阶段，responseFilter 遵从相同的逻辑履行次序与不行重复性。
public interface GatewayFilter extends Ordered {
void filter(ServerWebExchange exchange, GatewayFilterChain chain);
}
public interface ResponseFilter extends GatewayFilter { }
public interface RequestFilter extends GatewayFilter { }
filter接口规划
路由办理与匹配
以SCG网重视册的路由数量为基准，网关节点的需求支撑的路由规矩数量是上万级别的，按照得物现在的事务量，上限不超越5W，为了确保匹配功用，路由规矩放在分布式缓存中明显是不合适的，需求保存在节点的内存中。相似于在nginx上装备上万条location 规矩，手动维护难度可想而知，即使在装备中心办理起来也很麻烦，所以需求引进独立路由办理模块。
在匹配的功率上也需求进一步优化，SCG的路由匹配策略为普通的循环迭代逐个匹配，时刻功率为On，在路由规矩胀大到万级别后，功用急剧拉胯，结合得物的接口标准，新网关选用Hash匹配形式，将匹配功率提高到O1；hash的key为接口的path, 需求强调的是在同一个网关集群中，path是仅有的，这儿的path并不等价于事务服务的接口path, 绝大多数时分存在一些取舍，例如在事务服务的编写的/order/detail接口，在网关实践注册的接口或许为/api/v1/app/order/detail；由于运用了path作为key进行hash匹配。常见的restful 接口明显是不支撑的，确切的讲根据path传参数形式的接口均不支撑；出于某些前史原因，网关保留了相似nginx 的前缀匹配的支撑，可是这部分功用不对外敞开。
public class Route implements Ordered {
private final String id;
private final int skipCount;
private final URI uri;
}
route类规划
route的URI字段中包含了，需求路由到的详细服务名，这儿也可以称之为host ，route 信息会暂存在 exchange目标的 attributes 特点中, 在后续的loadbalance阶段host信息会被进一步替换为实在的 endpoint。
private Route lookupRoute(ServerWebExchange exchange) {
String path = exchange.getRequest().getPath();
CachingRouteLocator locator = (CachingRouteLocator) routeLocator;
Route exactRoute = pathRouteMap.getOrDefault(path, null);
if (exactRoute != null) {
exchange.getAttributes().put(DAGApplicationConfig.GATEWAY_ROUTE_CACHE, route);
return exactRoute;
}
}
路由匹配逻辑
单线程闭环
为了更好地使用CPU，以及减少不必要的数据竞争，将单个恳求的处理悉数闭合在一个线程当中；这意味着这个恳求的事务逻辑处理，RPC调用，权限验证，限流token获取都将一直由某个固定线程处理。netty中 网络衔接被笼统为channel，channel 与eventloop线程的对应关系为 N对1，一个channel 仅能被一个eventloop 线程所处理，这在处理用户恳求时没有问题，可是在接纳恳求完毕向下流转发恳求时，咱们碰到了一些应战，下流的衔接往往是衔接池在办理，衔接池的办理是另一组eventLoop线程在担任，为了坚持闭环需求将衔接池的线程设定为处理当时恳求的线程，而且只能是这一个线程；这样一来，默许状况下发动的N个线程（N 与机器中心数相同），别离需求办理一个衔接池；thread-per-core 形式的功用现已在nginx开源组件上得到验证。
衔接办理优化
为了满意单线程闭环，需求将衔接池的办理线程设置为当时的 eventloop 线程，终究咱们经过threadlocal 进行线程与衔接池的绑定；一般状况下netty自带的衔接池 FixedChannelPool 可以满意咱们大部分场景下的需求，这样的衔接池也是适用于多线程的场景；由于新网关运用thread-per-core形式并将恳求处理的全生命周期闭合在单个线程中，一切为了线程安全的额定操作不再必要且存在功用糟蹋；为此需求对原生衔接池做一些优化, 衔接的获取和开释简化为对链表结构的简略getFirst , addLast。
关于RPC 而言，无论是HTTP，还是Dubbo，Redis等终究底层都需求用到TCP衔接，将构建在TCP衔接上的数据解析协议与衔接剥离后，咱们发现这种纯粹的衔接办理是可以复用的，关于衔接池而言不需求知道详细衔接的用途，只需求维持到特定endpoint的衔接安稳即可，那么这儿的RPC服务的衔接仍然可以放入衔接池中进行保管；终究的衔接池规划架构图。
AsyncClient规划
关于七层流量而言根本悉数都是Http恳求，相同在RPC恳求中 http协议也占了大多数，考虑到还会存在少数的dubbo, Redis 等协议通信的场景。因而需求笼统出一套异步调用结构来支撑；这样的结构需求具备超时办理，回调履行，过错输出等功用，更重要的是具备协议无关性质， 为了更方便运用需求支撑链式调用。
建议一次RPC调用一般可以分为以下几步：
- 获取目标地址和运用的协议, 目标服务为集群部署时，需求运用loadbalance模块
- 封装发送的恳求，这样的恳求在运用层可以详细化为某个Request类，网络层序列化为二进制数据流
- 出于功用考虑挑选非堵塞式发送，发送动作完结后开端核算超时
- 接纳数据呼应，由于选用非堵塞形式，这儿的发送线程并不会以block的办法等候数据
- 在超时时刻内完结数据处理，或许触发超时导致衔接取消或许封闭
AsyncClient 模块内容并不杂乱，AsyncClient为笼统类不区分运用的网络协议；ConnectionPool 作为衔接的办理者被client所引证，获取衔接的key 运用 protocol ip port 再适合不过；一般在某个详细的衔接初始化阶段就现已确认了该channel 所运用的协议，因而初始化时会直接绑定协议Handler；当协议为HTTP恳求时，HttpClientCodec 为HTTP恳求的编解码handler；也可以是构建在TCP协议上的 Dubbo, Mysql ,Redis 等协议的handler。
首要关于一个恳求的不同履行阶段需求引进状况定位，这儿引进了 STATE 枚举：
enum STATE{
INIT,SENDING,SEND,SEND_SUCCESS,FAILED,TIMEOUT,RECEIVED
}
其次在履行进程中规划了 AsyncContext作为信息存储的载体，内部包含request和response信息，作用相似于上文说到的ServerWebExchange；channel资源从衔接池中获取，运用完结后需求主动放回。
public class AsyncContext<Req, Resp> implements Cloneable{
STATE state = STATE.INIT;
final Channel usedChannel;
final ChannelPool usedChannelPool;
final EventExecutor executor;
final AsyncClient<Req, Resp> agent;
Req request;
Resp response;
ResponseCallback<Resp> responseCallback;
ExceptionCallback exceptionCallback;
int timeout;
long deadline;
long sendTimestamp;
Promise<Resp> responsePromise;
}
AsyncContext
AsyncClient 封装了根本的网络通信才干，不拘泥于某个固定的协议，可以是Redis, http，Dubbo 等。当将数据写出去之后，该channel的非堵塞调用立即完毕，在没有收到呼应之前无法对AsyncContext 封装的数据做进一步处理，怎么在收到数据时将接纳到的呼应和之前的恳求办理起来这是需求面对的问题，channel 目标 的attr 办法可以用于临时绑定一些信息，以便于上下文切换时传递数据，可以在发送数据时将AsyncContext目标绑定到该channel的某个固定key上。当channel收到呼应信息时，在相关的 AsyncClientHandler 里面取出AsyncContext。
public abstract class AsyncClient<Req, Resp> implements Client {
private static final int defaultTimeout = 5000;
private final boolean doTryAgain = false;
private final ChannelPoolManager channelPoolManager = ChannelPoolManager.getChannelPoolManager();
protected static AttributeKey<AsyncRequest> ASYNC_REQUEST_KEY = AttributeKey.valueOf("ASYNC_REQUEST");
public abstract ApplicationProtocol getProtocol();
public AsyncContext<Req, Resp> newRequest(EventExecutor executor, String endpoint, Req request) {
final ChannelPoolKey poolKey = genPoolKey(endpoint);
ChannelPool usedChannelPool = channelPoolManager.acquireChannelPool(executor, poolKey);
return new AsyncContext<>(this,executor,usedChannelPool,request, defaultTimeout, executor.newPromise());
}
public void submitSend(AsyncContext<Req, Resp> asyncContext){
asyncContext.state = AsyncContext.STATE.SENDING;
asyncContext.deadline = asyncContext.timeout System.currentTimeMillis();
ReferenceCountUtil.retain(asyncContext.request);
Future<Resp> responseFuture = trySend(asyncContext);
responseFuture.addListener((GenericFutureListener<Future<Resp>>) future -> {
if(future.isSuccess()){
ReferenceCountUtil.release(asyncContext.request);
Resp response = future.getNow();
asyncContext.responseCallback.callback(response);
}
});
}
/**
* 测验从衔接池中获取衔接并发送恳求，若失利回来过错
*/
private Promise<Resp> trySend(AsyncContext<Req, Resp> asyncContext){
Future<Channel> acquireFuture = asyncContext.usedChannelPool.acquire();
asyncContext.responsePromise = asyncContext.executor.newPromise();
acquireFuture.addListener(new GenericFutureListener<Future<Channel>>() {
@Override
public void operationComplete(Future<Channel> channelFuture) throws Exception {
sendNow(asyncContext,channelFuture);
}
});
return asyncContext.responsePromise;
}
private void sendNow(AsyncContext<Req, Resp> asyncContext, Future<Channel> acquireFuture){
boolean released = false;
try {
if (acquireFuture.isSuccess()) {
NioSocketChannel channel = (NioSocketChannel) acquireFuture.getNow();
released = true;
assert channel.attr(ASYNC_REQUEST_KEY).get() == null;
asyncContext.usedChannel = channel;
asyncContext.state = AsyncContext.STATE.SEND;
asyncContext.sendTimestamp = System.currentTimeMillis();
channel.attr(ASYNC_REQUEST_KEY).set(asyncContext);
ChannelFuture writeFuture = channel.writeAndFlush(asyncContext.request);
channel.eventLoop().schedule(()-> doTimeout(asyncContext), asyncContext.timeout, TimeUnit.MILLISECONDS);
} else {
asyncContext.responsePromise.setFailure(acquireFuture.cause());
}
} catch (Exception e){
throw new Error("Unexpected Exception.............!");
}finally {
if(!released) {
ReferenceCountUtil.safeRelease(asyncContext.request);
}
}
}
}
AsyncClient中心源码
public class AsyncClientHandler extends SimpleChannelInboundHandler {
@Override
protected void channelRead0(ChannelHandlerContext ctx, Object msg) throws Exception {
AsyncContext asyncContext = ctx.attr(AsyncClient.ASYNC_REQUEST_KEY).get();
try {
asyncContext.state = AsyncContext.STATE.RECEIVED;
asyncContext.releaseChannel();
asyncContext.responsePromise.setSuccess(msg);
}catch (Throwable t){
log.error("Exception raised when set Success callback. Exception n: {}", ExceptionUtils.getFullStackTrace(t));
ByteBufHelper.safeRelease(msg);
throw t;
}
}
}
AsyncClientHandler
经过上面几个类的封装得到了一个易用运用的 AsyncClient，下面的代码为调用权限体系的事例：
final FullHttpRequest httpRequest = HttpRequestUtil.getDefaultFullHttpRequest(newAuthReq, serviceInstance, "/auth/newCheckSls");
asyncClient.newRequest(exchange.getExecutor(), endPoint,httpRequest)
.timeout(timeout)
.onComplete(response -> {
String checkResultJson = response.content().toString(CharsetUtil.UTF_8);
response.release();
NewAuthResult result = Jsons.parse(checkResultJson,NewAuthResult.class);
TokenResult tokenResult = this.buildTokenResult(result);
String body = exchange.getAttribute(DAGApplicationConfig.REQUEST_BODY);
if (tokenResult.getUserInfoResp() != null) {
UserInfoResp userInfo = tokenResult.getUserInfoResp();
headers.set("userid", userInfo.getUserid() == null ? "" : String.valueOf(userInfo.getUserid()));
headers.set("username", StringUtils.isEmpty(userInfo.getUsername()) ? "" : userInfo.getUsername());
headers.set("name", StringUtils.isEmpty(userInfo.getName()) ? "" : userInfo.getName());
chain.filter(exchange);
} else {
log.error("{},heads: {},response: {}", path, headers, tokenResult);
int code = tokenResult.getCode() != null ? tokenResult.getCode().intValue() : ResultCode.UNAUTHO.code;
ResponseDecorator.failResponse(exchange, code, tokenResult.getMsg());
}
})
.onError(throwable -> {
log.error("Request service {},occur an exception {}",endPoint, throwable);
ResponseDecorator.failResponseWithStatus(exchange,HttpResponseStatus.INTERNAL_SERVER_ERROR,"AuthFilter 验证失利");
})
.sendRequest();
asyncClient的运用
恳求超时办理
一个恳求的处理时刻不能无限期拉长， 超越某个阈值的状况下App的页面会被取消 ，长时刻的加载卡顿不如快速报错带来的体验杰出；明显网关需求针对接口做超时处理，尤其是在向后端服务建议恳求的进程，一般咱们会设置一个默许值，例如3秒钟，超越这个时刻网关会向恳求端回写timeout的失利信息，由于网关下流接入的服务形形色色，或许是RT灵敏型的C端事务，也或许是逻辑较重B端服务接口，乃至是存在许多核算的监控大盘接口。这就导致不同接口对超时时刻的诉求不相同，因而针对每个接口的超时时刻设定应该被独立出来，而不是一致装备成一个值。
asyncClient.newRequest(exchange.getExecutor(), endPoint,httpRequest)
.timeout(timeout)
.onComplete(response -> {
String checkResultJson = response.content().toString(CharsetUtil.UTF_8);
//..........
})
.onError(throwable -> {
log.error("Request service {},occur an exception {}",endPoint, throwable);
ResponseDecorator.failResponseWithStatus(exchange,HttpResponseStatus.INTERNAL_SERVER_ERROR,"AuthFilter 验证失利");
})
.sendRequest();
asyncClient 的链式调用规划了 timeout办法，用于传递超时时刻，咱们可以经过一个大局Map来装备这样的信息。
Map<String,Integer> 其key为全途径的path 信息，V为设定的超时时刻，单位为ms, 至于Map的信息在实践装备进程中怎么承载，运用ARK装备或许Mysql 都很容易完结。处于并发安全和功用的极致追求，超时事情的设定和调度最好可以在与当时channel绑定的线程中履行，庆幸的是 EventLoop线程自带schedule 办法。详细来看上文的 AsyncClient 的56行。schedule 办法内部以堆结构的办法完结了对超时时刻进行办理，整体功用尚可。
堆外内存办理优化
常见的堆外内存手动办理办法无非是引证计数，不同处理逻辑或许针对 RC (引证计数) 的值做调整，到某个环节的事务逻辑处理后现已不记得当时的引证计数值是多少了，乃至是前面的RC增加了，后边的RC忘掉减少了；但换个思路，在数据回写给客户端后咱们必定要把这个恳求整个生命周期所恳求的堆外内存悉数开释掉，堆外内存在收回的时分条件只要一个，便是RC值为0 ，那么在终究的release的时分，咱们引进一个safeRelase的思路 , 假如当时的RC>0 就不停的 release ，直至为0；因而只要把这样的逻辑放在netty的终究一个Handler中即可确保内存得到有用开释。
public static void safeRelease(Object msg){
if(msg instanceof ReferenceCounted){
ReferenceCounted ref = (ReferenceCounted) msg;
int refCount = ref.refCnt();
for(int i=0; i<refCount; i ){
ref.release();
}
}
}
safeRelease
呼应时刻尖刺优化
由于DAG 挑选了复用spring 的 loadbalance 模块，但这样一来就会和SCG相同存在发动初期的呼应时刻尖刺问题；为此咱们进一步剖析RibbonLoadBalancerClient 的构建进程，发现其用到了NamedContextFactory，该类的 contexts 变量保存了每一个serviceName对应的一个独立context，这种运用形式带来许多的功用糟蹋。
public abstract class NamedContextFactory<C extends NamedContextFactory.Specification>implements DisposableBean, ApplicationContextAware {
//1. contexts 保存 key -> ApplicationContext 的map
private Map<String, AnnotationConfigApplicationContext> contexts = new ConcurrentHashMap<>();
//........
}
在实践运转中 RibbonLoadBalancerClient 会调用choose办法来挑选合适的endpoint 作为本次RPC建议调用的实在地址；choose 办法履行进程中会触发 getLoadBalancer() 办法履行，可以看到该办法的可以按照传入的serviceId 获取专归于这个服务的LoadBalancer，事实上这样的规划有点多此一举。大部分状况下，每个服务的负载均衡算法都一致的，彻底可以复用一个LoadBalancer目标；该办法终究是从spring 容器中获取 LoadBalancer。
class RibbonLoadBalancerClient{
//..........
private SpringClientFactory clientFactory;
@Override
public ServiceInstance choose(String serviceId) {
return choose(serviceId, null);
}
public ServiceInstance choose(String serviceId, Object hint) {
Server server = getServer(getLoadBalancer(serviceId), hint);
if (server == null) {
return null;
}
return new RibbonServer(serviceId, server, isSecure(server, serviceId),
serverIntrospector(serviceId).getMetadata(server));
}
protected ILoadBalancer getLoadBalancer(String serviceId) {
return this.clientFactory.getLoadBalancer(serviceId);
}
//.........
}
RibbonLoadBalancerClient
由所以懒加载，实践流量触发下才会履行，因而第一次履行时，RibbonLoadBalancerClient 目标并不存在，需求初始化创立，创立时许多线程并发调用SpringClientFactory#getContext 办法，锁在同一个目标上，呈现许多的RT尖刺。这也解说了为什么SCG网关在发布期间会呈现呼应时刻大起伏抖动的现象。
public class SpringClientFactory extends NamedContextFactory<RibbonClientSpecification>{
//............
protected AnnotationConfigApplicationContext getContext(String name) {
if (!this.contexts.containsKey(name)) {
synchronized (this.contexts) {
if (!this.contexts.containsKey(name)) {
this.contexts.put(name, createContext(name));
}
}
}
return this.contexts.get(name);
}
//.........
}
SpringClientFactory
在后期的压测进程中，发现 DAG的线程数量远超预期，根据thread-per-core的架构形式下，过多的线程对功用损害比较大，尤其是当负载上升到较高水位时。上文说到默许状况下，每个服务都会创立独立loadBalanceClient , 而在其内部又会发动独立的线程去同步当时相关的serviceName对应的可用serverList,网关的特殊性导致需求接入的服务数量极为巨大，从而导致运转一段时刻后DAG的线程数量急剧胀大，关于同步serverList 这样的动作而言，彻底可以选用非堵塞的办法从注册中心拉取相关的serverList , 这种形式下单线程足以满意功用要求。
serverList的更新前后架构比照
经过预先初始化的办法以及大局只运用1个context的办法，可以将这儿冷发动尖刺消除，改造后的测验成果符合预期。
经过进一步修正优化spring loadbalance serverList 同步机制，下降90%线程数量的运用。
优化前线程数量（725）
优化后线程数量（72）
集群限流改造优化
首要来看DAG 发动后sentinel相关线程，相似的问题，线程数量十分多，需求针对性优化。
Sentinel 线程数
sentinel线程剖析优化：
终究优化后的线程数量为4个
sentinel原生限流源码剖析如下，进一步剖析SphU#entry办法发现其底调用 FlowRuleCheck#passClusterCheck；在passClusterCheck办法中发现底层网络IO调用为堵塞式，由于该办法的履行线程为workerEventLoop，因而需求运用上文说到的AsyncClient 进行优化。
private void doSentinelFlowControl(ServerWebExchange exchange, GatewayFilterChain chain, String resource){
Entry urlEntry = null;
try {
if (!StringUtil.isEmpty(resource)) {
//1. 检测是否限流
urlEntry = SphU.entry(resource, ResourceTypeConstants.COMMON_WEB, EntryType.IN);
}
//2. 经过，走事务逻辑
chain.filter(exchange);
} catch (BlockException e) {
//3. 阻拦，直接回来503
ResponseDecorator.failResponseWithStatus(exchange, HttpResponseStatus.SERVICE_UNAVAILABLE, ResultCode.SERVICE_UNAVAILABLE.message);
} catch (RuntimeException e2) {
Tracer.traceEntry(e2, urlEntry);
log.error(ExceptionUtils.getFullStackTrace(e2));
ResponseDecorator.failResponseWithStatus(exchange, HttpResponseStatus.INTERNAL_SERVER_ERROR,HttpResponseStatus.INTERNAL_SERVER_ERROR.reasonPhrase());
} finally {
if (urlEntry != null) {
urlEntry.exit();
}
ContextUtil.exit();
}
}
SentinelGatewayFilter（sentinel 适配SCG的逻辑）
public class RedisTokenService implements InitializingBean {
private final RedisAsyncClient client = new RedisAsyncClient();
private final RedisChannelPoolKey connectionKey;
public RedisTokenService(String host, int port, String password, int database, boolean ssl){
connectionKey = new RedisChannelPoolKey(String host, int port, String password, int database, boolean ssl);
}
//恳求token
public Future<TokenResult> asyncRequestToken(ClusterFlowRule rule){
....
sendMessage(redisReqMsg,this.connectionKey)
}
private Future<TokenResult> sendMessage(RedisMessage requestMessage, EventExecutor executor, RedisChannelPoolKey poolKey){
AsyncRequest<RedisMessage,RedisMessage> request = client.newRequest(executor, poolKey,requestMessage);
DefaultPromise<TokenResult> tokenResultFuture = new DefaultPromise<>(request.getExecutor());
request.timeout(timeout)
.onComplete(response -> {
...
tokenResultFuture.setSuccess(response);
})
.onError(throwable -> {
...
tokenResultFuture.setFailure(throwable);
}).sendRequest();
return tokenResultFuture;
}
}
RedisTokenService
终究的限流Filter代码如下：
public class SentinelGatewayFilter implements RequestFilter {
@Resource
RedisTokenService tokenService;
@Override
public void filter(ServerWebExchange exchange, GatewayFilterChain chain) {
//当时为 netty NioEventloop 线程
ServerHttpRequest request = exchange.getRequest();
String resource = request.getPath() != null ? request.getPath() : "";
//判断是否有集群限流规矩
ClusterFlowRule rule = ClusterFlowManager.getClusterFlowRule(resource);
if (rule != null) {
//异步非堵塞恳求token
tokenService.asyncRequestToken(rule,exchange.getExecutor())
.addListener(future -> {
TokenResult tokenResult;
if (future.isSuccess()) {
tokenResult = (TokenResult) future.getNow();
} else {
tokenResult = RedisTokenService.FAIL;
}
if(tokenResult == RedisTokenService.FAIL || tokenResult == RedisTokenService.ERROR){
log.error("Request cluster token failed, will back to local flowRule check");
}
ClusterFlowManager.setTokenResult(rule.getRuleId(), tokenResult);
doSentinelFlowControl(exchange, chain, resource);
});
} else {
doSentinelFlowControl(exchange, chain, resource);
}
}
}
改造后适配DAG的SentinelGatewayFilter
六、压测功用
DAG高压表现
wrk -t32 -c1000 -d60s -s param-delay1ms.lua –latency http://a.b.c.d:xxxxx
DAG网关的QPS、实时RT、过错率、CPU、内存监控图；在CPU占用80% 状况下，可以支撑的QPS在4.5W。
DAG网关的QPS、RT 折线图
DAG在CPU占用80% 状况下，可以支撑的QPS在4.5W，ART 19ms
SCG高压表现
wrk -t32 -c1000 -d60s -s param-delay1ms.lua –latency http://a.b.c.d:xxxxx
SCG网关的QPS、实时RT、过错率、CPU、内存监控图：
SCG在CPU占用95% 状况下，可以支撑的QPS在1.1W，ART 54.1ms
DAG低压表现
wrk -t5 -c20 -d120s -s param-delay1ms.lua –latency http://a.b.c.d:xxxxx
DAG网关的QPS、实时RT、过错率、CPU、内存：
DAG在QPS 1.1W状况下，CPU占用30%，ART 1.56ms
数据比照
结论
满负载状况下，DAG要比SCG的吞吐量高许多，QPS简直是4倍，RT反而耗费更低，SCG在CPU被打满后，RT表现呈现严峻功用劣化。DAG的吞吐操控和SCG相同状况下，CPU和RT损耗下降了更多。DAG在最大压力下，内存耗费比较高，到达了75%左右，不过到峰值后，就不再见有大幅改变了。比照压测成果，结论令人欢喜，SCG作为Java生态当时运用最广泛的网关，其功用归于一线水准，DAG的功用到达其4倍以上也是远超意料，这样的成果给与研制同学极大的鼓动。
七、投产收益
安全性提高
完善的接口级路由办理
根据接口注册形式的全新路由上线，包含了接口注册的恳求人，恳求时刻，接口场景备注信息等，接口办理愈加严谨标准；结合路由组功用可以方便的查询当时服务的一切对外接口信息，某种程度上具备必定的API查询办理才干；一起为了缓解用户需求检索的接口太多的为难，引进了一键保藏功用，大部分时分用户只需求切换到已重视列表即可。
注册接口列表
接口保藏
防浸透才干极大增强
前期的泛化路由，给黑产的浸透带来了极大的幻想空间和安全隐患，乃至可以在外网直接拜访某些事务的装备信息。
黑产接口浸透
接口注册形式启用后，一切未注册的接口均无法拜访，防浸透才干提高一个台阶，一起主动推送反常接口拜访信息。
404接口拜访反常推送
安稳性增强
内存走漏问题处理
经过一系列手段改善优化和严格的测验，新网关的内存运用愈加稳健，内存增加曲线直接拉平，彻底处理了走漏问题。
老网关内存增加趋势
新网关内存增加趋势
呼应时刻尖刺消除
经过预先初始化 & context 共用等手段，去除了运转时并发创立多个context 抢占大局锁的开支，冷发动RT尖刺下降99% ；关于spring load balance 模块的更多优化细节可以参阅这篇博客：Spring LoadBalance 存在问题与优化。
压测数据比照
实践出产监控
趋势图上略有差异，可是从非200恳求的肯定值上看，这种差异可以忽略, 比照发布期间和非发布期间反常恳求的数量，发现根本没有区别，这代表着以往的发布期间的呼应时刻尖刺根本消除，做到了发布期间事务服务彻底无感知。
1月4日发布期间各节点流量改变
1月4日反常恳求状况数量监控(发布期间)
1月5日反常恳求状况数量监控（无发布）
降本增效
资源占用下降50%
SCG均匀CPU占用
DAG资源占用
JDK17晋级收益
得益于ZGC的优异算法，JVM17 在GC暂停时刻上取得了超卓的成果，网关作为延迟灵敏型运用对GC的暂停时刻尤为垂青，为此咱们组织晋级了JDK17 版本；下面为平等流量压力状况下的装备不同GC的作用比照，可以看到GC的暂停时刻从均匀70ms 下降到1ms 内，RT99线得到大起伏提高；吞吐量不再受流量波动而大起伏改变，功用表现愈加安稳；一起网关的均匀呼应时刻损耗下降5%。
JDK8-G1 暂停时刻表现
JDK17-ZGC暂停时刻表现
吞吐量方面，G1随同流量的改变呈现出必定的波动趋势，均线在99.3%左右。ZGC的吞吐量则比较安稳，维持在无限接近100%的水平。
JDK8-G1 吞吐量
JDK17-ZGC吞吐量
关于实践事务接口的影响，从下图中可以看到均匀呼应时刻有所下降，这儿的RT差值表明接口经过网关层的损耗时刻；不同接口的RT差值损耗是不同的，这或许和恳求呼应体的巨细，是否经过登录验证，风控验证等事务逻辑有关。
JDK17与JDK8 ART比照
需求指出的是ZGC关于一般的RT灵敏型运用有很大提高， 服务的RT 99线得到显著改善。可是假如当时运用许多运用了堆外内存的办法，则提高相对较弱，如许多运用netty结构的运用, 由于这些运用的大部分数据都是经过手动开释的办法进行办理。
八、考虑总结
架构演进
API网关的自研并非一蹴而就，而是阅历了屡次事务迭代按部就班的进程；从前期的泛化路由引发的安全问题处理，到后边的许多路由注册，带来的匹配功用下降 ，以及终究压垮老网关终究一根稻草的内存走漏问题；在不同阶段需求运用不同的应对策略，前期事务快速迭代，许多的需求堆积，最快的时分一个功用点的改动需求三四天内上线 ，咱们很难有满足的精力去做一些深层次的改造，这个时分需求导向为优先，功用性建造完善优先，是一个快速奔驰的建造期；随同体量的增加安全和安稳性的重视程度逐渐拔高，继而推动了这些方面的许多建造；从拓宽SCG的原有功用到改善结构源码，以及终究的自研重写，可以说新的API网关是一个事务推从而演化出来的产品，也只要这样 “生长” 出来的架构产品才干更好的符合事务开展的需求。
技能考虑
开源的API网关有许多，可是自研的事例并不多，咱们可以参阅的计划也很有限。除了几个业界闻名的产品外，许多开源的项目参阅的价值并不大；从自研的目标来看，咱们最根本的要求是功用和安稳性要优于现有的开源产品，至少Java的生态是这样；这就要求架构规划和代码质量上必须比现有的开源产品愈加优异，才有或许；为此咱们深度学习了流量署理界的常青树Nginx，发现根据Linux 多进程模型下的OS，假如要发挥出最大效能，单CPU中心支撑单进程（线程）是功率最高的形式。可以将OS的进程调度开支最小化一起将高速缓存miss降到最低，此外还要尽或许减少或许消除数据竞争，避免锁等候和自旋带来的功用糟蹋；DAG的整个技能架构可以简化的了解为引进了独立操控流的多线程版的Nginx。
中间件的研制创新存在着较高的难度和杂乱性，更何况是在事务不断推动中换引擎。在整个研制进程中，为了尽或许适配老的事务逻辑，对原有的事务逻辑的改动最小化，新网关对老网关的架构层接口做了全面适配；换句话说新引擎的对外露出的中心接口与老网关坚持一致，让老的事务逻辑在0改动或许仅改动少数几行代码后就能在新网关上直接跑，可以极大起伏下降咱们的测验回归本钱，由于这些代码自身的逻辑正确性，现已在出产环境得到了许多验证。这样的适配器形式相同适用于其他组件和事务开发。
作为底层基础组件的开发人员，要对自己写下的每一行代码都有明晰的知道，不了解的地方必定要多翻材料，多读源码，模棱两可的了解是肯定不行的；常见的开源组件尽管说大部分代码都是资深开发人员写出来的，可是有程序员的地方就有bug ，要带着审慎眼光去看到这些组件，而不是一味地运用盲从，所谓尽信书不如无书；许多中间件的根本原理都是相通的，如常见Raft协议，根据epoll的reactor网络架构，存储范畴的零拷贝技能，预写日志，常见的索引技能，hash结构，B 树，LSM树等等。一个成熟的中间件往往会触及多个方向的技能内容。研制人员并不需求每一个组件都涉猎极深，也不现实，掌握常见的架构思路和技巧以及一些根本的技能点，做到对一两个组件做到熟稔于心。考虑和了解到位了，很容易举一反三。
安稳性把控
自研基础组件是一项浩大的工程，可以预见代码量会极为巨大，怎么有用办理新项目的代码质量是个扎手的问题; 原有事务逻辑的改造也需求回归测验；现实的状况是中间件团队没有专职的测验，质量确保彻底依靠开发人员；这就对开发人员的代码质量提出了极高的要求，一方面咱们经过与老网关适配相同的署理引擎接口，下降搬迁本钱和事务逻辑呈现bug的概率；另一方面还对编码质量提出了高标准，均匀每周两到三次的CodeReview；80%的单元测验行覆盖率要求。
网关作为流量进口，承受全司最高流量，对安稳性的要求极为苛刻。最抱负的状况是在事务服务没有任何感知的状况下，咱们将新网关逐渐替换上去；为此咱们对新网关上线的进程做了充分的预备，严格操控上线进程；详细来看整个上线流程分为以下几个阶段：
第一阶段
咱们在压测环境长时刻高负载压测，继续运转时刻24小时以上，以检测内存走漏等安稳性问题。一起使用功用检测工具抓取热点火焰图，做针对性优化。
第二阶段
发布测验环境试跑，选用并行试跑的办法，新老网关一起对外提供服务（流量份额1 ：1，初期新网关承受流量或许只要十分之一），一旦用户反应的问题或许跟新网关有关，或许发现反常case，立即关停新网关的流量。待查明原因并确认修正后，重新引流。
第三阶段
上线预发，小得物环境试跑，由于这些环境流量不大，仍然可以并行长时刻试跑，发现问题处理问题。
第四阶段
出产引流，单节点从万分之一份额开端灰度，逐渐引流扩大，每个阶段停留24小时以上，观察修正后再扩大，循环此进程；根据单节点承担正常份额流量后，再次抓取火焰图，根据实在流量场景下的功用热点做针对性优化。
团队生长
回顾整个研制进程咱们在不间断新事务承受的状况下，几个月时刻内完结开发和上线，从节奏上来讲不行谓不快，研制同学的心态也阅历了一些改变。从一开端的质疑，以为我们曾经从没有做过的东西现在就这点人能搞的出来吗？到中期的这个组件写起来蛮有应战也很有意思！直到后期初版压测数据出来后的惊奇。就项目成果而言，可以说收成感满满，从后续的针对研制同学的one one 交流反应来看，关于整个项目感受最大的是技能上的提高很大，对高并发网络编程范畴的认知提高了一个层次, 尤其是异步编程方面，技能决心增强许多；内部也组织了分享会，我们普遍很感兴趣，收成了较大的技能红利。
*文/簌语
本文属得物技能原创，更多精彩文章请看：得物技能官网
未经得物技能答应禁止转载，不然依法追究法律责任！
