Spring Cloud Zuul性能调整

Spring Cloud 版本：

Dalston.SR5

这两天通过JMeter测了一下Spring Cloud Zuul的性能，用的是两台虚机8核8G和4核8G，宿主机是10核逻辑20核，代理的服务简单的返回字符串hello，vm堆内存1G够用

先说一下测试情况，值得一提的是测试并不严谨，因为用的是虚机，并且虚机上还跑了一些其它的东西，所以不能作为最终指导，仅供参考。

8核心的情况下：

zuul的性能约是nginx（8个worker）的75%，

nginx 8个worker 的cup总占用率为360%（有点奇怪）

zuul 占用750%

4核的情况下：

zuul大约是nginx（4个worker）性能的40%，

nginx的cup总占用率为320%

zuul占用380%

奇怪的现象：

nginx在4核下吞吐2W，8核下吞吐1W6，不增反降，具体不知道为什么（2019年1月30日追加：这是因为随着worker进程的增加，nginx的master进程调度能力跟不上了）。

测试zuul的时候，前几次性能比较低，到后边就比较稳定和高效了，可能和JIT有关，也可能是线程创建的比较慢，线程默认寿命是一分钟。

—————————————————————————————————分割线———————————————————————————————————————

Zuul默认是使用信号量隔离，并且信号量的大小是100，请求的并发线程超过100就会报错

可以调大该信号量的最大值来提高性能，配置如下：

zuul:
  semaphore:
    max-semaphores: 5000

也可以改为使用线程隔离，调大hystrix线程池线程大小，该线程池默认10个线程，配置如下：

zuul:
  ribbonIsolationStrategy: THREAD

hystrix:
  threadpool:
    default:
      coreSize: 100
      maximumSize: 5000
      allowMaximumSizeToDivergeFromCoreSize: true
      maxQueueSize: -1

maximumSize：最大线程数量

allowMaximumSizeToDivergeFromCoreSize：是否让maximumSize生效，false的话则只有coreSize会生效
maxQueueSize：线程池的队列大小，-1代表使用SynchronousQueue队列

默认配置都可以去HystrixThreadPoolProperties和ZuulProperties这两个java文件中查找

2018年8月31日追加：
Zuul使用的内置容器默认是Tomcat，可以将其换成undertow，可以显著减少线程的数量，替换方式即在pom中添加以下内容：

<dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
            <exclusions>
                <exclusion>
                    <groupId>org.springframework.boot</groupId>
                    <artifactId>spring-boot-starter-tomcat</artifactId>
                </exclusion>
            </exclusions>
        </dependency>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-undertow</artifactId>
        </dependency>

Spring Cloud Zuul做网关，这性能我只能说凑合，不过它提供了比nginx更多的便利。不行就多部署几个Zuul，Zuul一般不会成为瓶颈。

总结：
本文主要是对zuul和nginx网关的性能进行了对比，然后对zuul的优化配置进行了说明。
一般spring cloud微服务的实战中，都是nginx和zuul结合使用，zuul能很方便的基于注册中心进行多实例的集群部署，不会成为性能瓶颈。