一个API网关性能优化实践之路

前言

最近换了一份工作，而新工作是调研下目前业界Api网关的一些性能情况，而在最近过去一年的时间里，我也主要开发了一个Api网关来支持协议适配的需求，但是由于前东家的话整个流量都不大，而相应的性能优化也没有很好的去做，借着让原来在唯品会的同事把网关推到了OYO在做性能压测及我刚入职新单位接手的第一项任务，把网关的性能进行了一下优化，也踩了一些坑，把这些作为总结写下来；本文是https://juejin.im/post/5d19dd5c6fb9a07ec27bbb6e?from=timeline&isappinstalled=0
的补充，主要是介绍整个优化步骤；

网关简介

Tesla的整个网络框架是基于littleproxy[https://github.com/adamfisk/LittleProxy]，littleproxy是著名的软件的后端代理，按照常规性能应该不错，在此基础上我们加了些功能，具体代码在：[https://github.com/spring-avengers/tesla]

删除UDP代理的功能及SSL的功能；
增加了10多个Filter，而这些Filter由一个最大的Filter包裹来执行；

HttpFiltersAdapter的clientToProxyRequest方法，负责调用方到代理方的拦截处理

public HttpResponse clientToProxyRequest(HttpObject httpObject) {
     logStart();
     HttpResponse httpResponse = null;
     try {
         httpResponse = HttpRequestFilterChain.doFilter(serveletRequest, httpObject, ctx);
         if (httpResponse != null) {
             return httpResponse;
         }
     } catch (Throwable e) {
         httpResponse = ProxyUtils.createFullHttpResponse(HttpVersion.HTTP_1_1, HttpResponseStatus.BAD_GATEWAY);
         HttpUtil.setKeepAlive(httpResponse, false);
         logger.error("Client connectTo proxy request failed", e);
         return httpResponse;
     }
     ...
 }

HttpFiltersAdapter的proxyToClientResponse方法，负责从后端服务拿到请求返回给调用方的拦截处理

public HttpObject proxyToClientResponse(HttpObject httpObject) {
      if (httpObject instanceof HttpResponse) {
          HttpResponse serverResponse = (HttpResponse)httpObject;
          HttpResponse response = HttpResponseFilterChain.doFilter(serveletRequest, serverResponse, ctx);
          logEnd(serverResponse);
          return response;
      } else {
          return httpObject;
      }
  }

每个Filter的配置数据都是定时从数据库里面拉取（用hazelcast做了缓存）；
为了让Filter做到热插拔，大量的使用了反射去构造Filter的实例；

优化步骤

由于大量的使用了反射去构造实例，但是没有去缓存这些实例，原本的想法是所有的Filter都是有状态的，伴随每一个HTTP请求的消亡而消亡，但是最终运行下来发现如果并发量上来整个GC完全接受不了，大量的对象的产生引起了yong gc的频率几乎成倍的增加，进而导致qps上不去，而解决这个问题的办法就是缓存实例，让每一个Filter无状态，整个JVM内存中仅存在一份实例；
但是这些做下来，发现网关的QPS也没上去，尽管GC情况解决了，QPS有所上升，但是远远没达到Netty所想要的QPS，那只能继续往前走；
线程池的优化

我们都知道Netty的线程池分为boss线程池和work线程池，其中boss线程池负责接收网络请求，而work线程池负责处理io任务及其他自定义任务，对于网关这个应用来说，boss线程池是必须要的，因为要负责请求的接入，但是网关比较特殊，对于真正的调用方来说，它是一个服务端，对于后端服务来说它是一个客户端，所以他的线程模型应该是如下：

image.png

这种线程池模型是典型的netty的线程池模型：
Acceptor负责接收请求，ClientToProxyWorker是负责代理服务器的处理IO请求，而ProxyServerWorker负责转发请求到后端服务，LittleProxy就是使用这种很经典的线程模型，其QPS在4核32G的机器下QPS大概能达到9000多，但是这种线程模型存在ClientToProxyWorker和ProxyServerWorker线程切换的问题，我们都知道线程切换是要耗费CPU资源的，那我们是不是可以做一个改变呢？换成以下这种：

image.png

这种线程池模型是将ClientToProxyWorker和ProxyServerWorker复用同一个线程池，这种做法在省却了一个线程切换的时间，也就是对于代理服务器来说，netty的服务端及netty的客户端在线程池传入时复用同一个线程池对象；
做到这一步的话整个代理服务的性能应该能提升不少，但是有没有更好的线程模型呢？答案是肯定的；

image.png

这个线程模型的话，整个处理请求及转发请求都复用同一个线程，而这种做法的话线程的切换基本没有；
而相应的代码如下：

  /**
     * Opens the socket connection.
     */
    private ConnectionFlowStep connectChannel = new ConnectionFlowStep(this, CONNECTING) {
        @Override
        public boolean shouldExecuteOnEventLoop() {
            return false;
        }

        @Override
        public Future<?> execute() {
            //复用整个ClientToProxy的处理IO的线程
            Bootstrap cb = new Bootstrap().group(ProxyToServerConnection.this.clientConnection.channel.eventLoop())
                .channel(NioSocketChannel.class)
                .option(ChannelOption.CONNECT_TIMEOUT_MILLIS, proxyServer.getConnectTimeout())
                .handler(new ChannelInitializer<Channel>() {
                    public void initChannel(Channel ch) throws Exception {
                        Object tracingContext =
                            ProxyToServerConnection.this.clientConnection.channel.attr(KEY_CONTEXT).get();
                        ch.attr(KEY_CONTEXT).set(tracingContext);
                        initChannelPipeline(ch.pipeline(), initialRequest);
                    }

                ;
                });
            if (localAddress != null) {
                return cb.connect(remoteAddress, localAddress);
            } else {
                return cb.connect(remoteAddress);
            }
        }
    };

这种做法zuul2也是如此做，文章可以看看这篇介绍比较详细：https://www.jianshu.com/p/cb413fec1632

部署压测：

image.png

压测结果

image.png

总结

Netty的线程池模型选择直接决定了性能
在Netty的InboundHandler里不要做任何的加锁动作，Netty的pipline已经保证了是单线程运行，如果要缓存数据的话直接用HashMap就好，别用ConcuurentHashMap或者 Collections.synchronizedMap来做加锁动作
保证Filter是无状态的
慎用applicationContext.getEnvironment().getProperty()，在非Web容器环境下该操作将影响很大的性能