网关的大部分工作是请求转发，属于IO密集型的应用，我们要在有限的资源的情况下结合公司实际请求场景做调优。

一，容器选择

在容器方面，undertow的呼声很高，一个是他很轻量级的，其次他属于java开发，性能也很好，笔者根据实际情况对tomcat和undertow做了一个对比

默认配置下，8核cpu，tomcat启动后会初始化10个io线程，而undertow会初始化72个线程，8个IO线程，64个work线程（8*8）

性能对比：写一个接口，接口中什么也不做，就睡眠2s

请求个数		tomcat		tomcat(max-threads:100)		undertow
50	平均耗时(ms)：	2241		2241		2321
	线程个数：	93		93		105
	内存	94				133
100	平均耗时(ms)：	2231		2021		2517
	线程个数：	143		138		105
	内存
200	平均耗时(ms)：	2424		2788		3884
	线程个数：	238		138		105
	内存
300	平均耗时(ms)：	3596		3753		5454
	线程个数：	238		138		105
	内存
400	平均耗时(ms)：	3427		4623		6865
	线程个数：	238		138		105
	内存

从对比来看，就初始化来看，tomcat最初只初始化10个线程，而undertow则会初始化所有的线程

性能来看，tomcat也是要占优势的

tomcat 比undertow要灵活，适应高峰和低谷也比较强

二，hystrix隔离方式

zuul默认的是信号量方式，也就是控制进来的请求总量，可以全局配置，也可以配置单个服务的最大信号量，还有一种方式是线程隔离，每种路由方式会创建单独的线程池，这样的好处是一个服务的影响不会扩散到其他的服务，但是在资源有限，且服务有限的情况下，还是信号量合适，这样我们可以充分利用tomcat创建的线程池，而不用创建过多的hystrix线程池

三：ribbon相应时间：

在默认的情况下，ribbon很容易就会报错，比如read timeout等，可以通过

ribbon:
  ReadTimeout: 60000
  ConnectTimeout: 10000
  MaxAutoRetries: 1
  MaxAutoRetriesNextServer: 1

来控制，但是如果设置过长也会导致长时间的等待，建议60比较合适

四：httpclient选择

zuul默认是Appache Httpclient，呼声比较高的是okhttp

但是经过测试，okhttp的性能更好，所以可以通过

<dependency>
    <groupId>com.squareup.okhttp3</groupId>
    <artifactId>okhttp</artifactId>
</dependency>

引入okhttp并在ribbon中配置：

ribbon:
  httpclient:
    enabled: false
  okhttp:
    enabled: true