前言
之前出现过一次服务器Cpu占用率达到100%的问题，经分析是Jenkins的重启Jar包脚本导致的。
最近在使用测试服务器时，发现服务器卡顿仍然很严重，定位到问题是 rsdun-zuul-balance 网关服务导致的，下面是调查过程：
发现问题
在任务管理器中，定位到一个java服务的线程数很多，然后通过pid定位到是rsdun-zuul-balance服务
通过 jconsole.exe 监视该服务，利用压测工具 jmeter 进行压力测试，请求 获取朋友圈信息 接口，得到的运行情况如下
CPU 占用率在 5% - 25% 之间浮动，利用 windows 自带的资源监视器，对比其他正在运行的 java 服务，CPU 占用率稍高
注：资源监视器打开方式如下
原因分析
所有的请求都需要经过 zuul 进行转发，这是造成 zuul 服务 cpu 占用过高的原因。当某个时间点大量请求涌入，CPU 使用率会飙升，见下方测试:
优化办法
根据上面的分析，CPU 使用率与单位时间请求数量成正比，这一块儿目前无法进行优化。但是可以以下面两个目标作为优化方向：
- **提高系统的TPS(吞吐量)**。
- 降低请求错误率。
优化方法：
zuul服务参数调优。- 建立高可用架构。
目前的主要调优手段应该是第一种，第二种需要物理设备的支持。
其他问题
在使用 jmeter 进行压力测试时，发现了如下几个错误。
REJECTED_SEMAPHORE_EXECUTION 错误
在使用 jmeter 进行压测时(1s内1000请求)，发现大量请求报错：{"timestamp":"2021-09-22T08:30:37.484+0000","status":500,"error":"Internal Server Error","message":"REJECTED_SEMAPHORE_EXECUTION"}
异常率达到 87.2%
并且这个报错有时在进行 App测试 时也会出现。查询资料发现是因为 zuul 默认每个路由直接用信号量做隔离，并且默认值是 100 ，也就是当一个路由请求的信号量高于 100 那么就拒绝服务了，返回500。
重新设置信号量为5000，再次测试，没有出现报错。
Internal Server Error 错误
目前测试发现有两个原因会导致该错误：
- 请求连接时间过长。
- 服务挂了。
这里仅分析一下第一个原因，与 ribbon.ConnectTimeout 这个参数有关。这个参数配置的是请求连接超时时间，将这个参数调整至1(ms)，头几个请求会报这个错误；调整至3000(ms)，请求正常。
1 | # 请求连接超时时间3s |
