内容

　　作为微服务架构系统的入口，毫无疑问，Zuul的并发性能直接决定了整个系统的并发性能。本文结合前几篇文章的内容，在云服务器中部署了包含Eureka Server，Zuul等组件的1.0版本的微服务架构，并进行单点部署Zuul的压力测试，对其并发性能一探究竟。

环境

说明

　　转载请说明出处：

#增大tomcat中worker的最大线程数量 server:   tomcat:    max-threads: 500

　　Service端完整的yaml配置文件：GitHub链接

问题二

问题剖析

​　　为什么Zuul会在Serivce正常的情况下出现服务熔断呢？

​　　默认情况下，当某微服务请求的失败比例大于50%（且请求总数大于20次）时，会触发Zuul中断路器的开启，后续对该微服务的请求会发生熔断，直到微服务的访问恢复正常。在Serivce正常时出现服务熔断，有可能是请求端或网络的问题，但通常是由于hystrix的信号量小于Zuul处理请求的线程数造成的。Zuul默认使用semaphores信号量机制作为Hystrix的隔离机制，当Zuul对后端微服务的请求数超过最大信号量数时会抛出异常，通过配置zuul.semaphore.max-semaphores可以设置Hystrix中的最大信号量数。也就是说zuul.semaphore.max-semaphores设置的值小于server.tomcat.max-threads，会导致hystrix的信号量无法被acquire，继而造成服务熔断。

问题解决

​　　确保zuul.semaphore.max-semaphores属性值大于server.tomcat.max-threads。

问题一

问题剖析

　　​Zuul端转发请求的线程数与后端Service处理请求的线程数之间是什么关系呢？

　　​Zuul集成了Ribbon与Hystrix，当使用Service ID配置Zuul的路由规则时，Zuul会通过Ribbon实现负载均衡，通过Hystrix实现服务熔断。这个过程可以理解为这三个动作：Zuul接收请求，Zuul转发请求，Service接收请求。其中第一个和第三个动作，由问题三可知，分别由Zuul和Service的server.tomcat.max-threads属性配置。

　　第二个动作使用了Ribbon实现负载均衡，通过设置ribbon.MaxConnectionsPerHost属性（默认值50）和ribbon.MaxTotalConnections属性（默认值200）可以配置Zuul对后端微服务的最大并发请求数，这两个参数分别表示单个后端微服务实例请求的并发数最大值和所有后端微服务实例请求并发数之和的最大值。

　　第二个动作同时使用Hystrix实现熔断，Zuul默认使用semaphores信号量机制作为Hystrix的隔离机制，当Zuul对后端微服务的请求数超过最大信号量数时会抛出异常，通过配置zuul.semaphore.max-semaphores可以设置Hystrix中的最大信号量数。

​　　因此通过配置上述三个属性可以增加每个路径下允许转发请求的线程数。这三个属性的关系用下图粗略的进行表示：

​　　Zuul端转发请求的线程数与Service端处理请求的线程数的关系：

　　限制一：单点部署的Zuul同时处理的最大线程数为server.tomcat.max-threads；

　　限制二：向所有后端Service同时转发的请求数的最大值为server.tomcat.max-threads、ribbon.MaxTotalConnections和zuul.semaphore.max-semaphores的最小值，这也是所有后端Service能够同时处理请求的最大并发线程数；

　　限制三：单个后端Service能同时处理的最大请求数为其server.tomcat.max-threads和ribbon.MaxConnectionsPerHost中的最小值。

　　注意：很多博客提到使用zuul.host.maxTotalConnections与zuul.host.maxPerRouteConnections这两个参数。经过查阅和实践，这两个参数在使用Service ID配置Zuul的路由规则时无效，只适用于指定微服务的url配置路由的情景。

配置调优

　　在Zuul端的yaml配置文件中增加如下配置，为了避免因为等待时间过长造成请求处理失败，增加Ribbon和Hystrix的超时设置：

ribbon:   #Ribbon允许最大连接数，即所有后端微服务实例请求并发数之和的最大值。   MaxTotalConnections: 500   #单个后端微服务实例能接收的最大请求并发数     MaxConnectionsPerHost: 500   #建议设置超时时间，以免因为等待时间过长造成请求处理失败（一）   #Http请求中的socketTimeout   ReadTimeout: 5000   #Http请求中的connectTimeout   ConnectTimeout: 10000 ​ #hystrix信号量semaphore的设置，默认为100，决定了hystrix并发请求数 zuul:   semaphore:    max-semaphores: 500       #建议设置超时时间，以免因为等待时间过长造成请求处理失败（二） hystrix:   command:    default:      execution:        isolation:          thread:            timeoutInMilliseconds: 10000

　　Zuul端完整的yaml配置文件：GitHub链接

再测2.1.2通过Zuul调用sayHello接口（200并发用户数）

​　　系统吞吐量达到了4200左右，请求平均处理时间为0.236ms，请求平均等待时间为47.165ms，50000次请求全部成功

​结果：请求全部成功，问题2成功解决。