Spring Cloud Netflix Zuul网关HTTP延迟调优及技术咨询

嗨，咱们结合你遇到的场景，逐个解决这些Zuul性能问题：

1. 当单主机最大连接数设为10，网关收到1000个请求时，剩余990个请求的队列如何查看/调试？ #

• 首先可以借助Spring Boot Actuator的监控端点获取连接池指标。开启metrics端点后，查找和zuul.host或底层Apache HttpClient相关的指标，比如httpclient.connections.pending就能显示队列中等待的请求数。
• 实时调试的话，可以用JConsole或者VisualVM连接网关的JVM，查看连接池的内部状态。找到PoolingHttpClientConnectionManager这个Bean，它的pendingConnections属性就是当前队列的请求数量。
• 你也可以在网关里添加自定义日志，追踪请求进入和离开连接队列的时机。比如包装HttpClient的执行逻辑，当请求等待连接时记录队列中的请求数。

2. 何时需要增大信号量，其作用是什么？ #

• Zuul里的信号量是用来做路由级别的并发限制的，核心作用是控制单条路由同时能处理的请求数，防止网关被过多并发请求压垮。
• 需要增大信号量的场景：
  • 当你发现并发请求数超过了信号量上限，导致请求被拒绝或者排队（具体看配置）的时候。不过在你的场景里调整信号量没效果是合理的——因为你的瓶颈在HTTP连接池（调大连接数后耗时降低了），信号量的上限还没被触发，所以改了也没变化。
  • 如果网关频繁抛出和信号量耗尽相关的ZuulException，那肯定得调大信号量了。
• 一般来说，信号量的上限要根据网关能承受的最大并发请求数来设置，得留好余量，避免突发流量直接打满。

3. 如何计算单主机最大连接数及总最大连接数的合理配置值？ #

• 咱们分两部分来看：
  • 单主机最大连接数（max-per-route-connections）：这个值要参考目标服务的并发处理能力。比如目标服务能稳定处理100个并发请求，那把这个值设为80-100就比较合理（留些冗余）。另外还要结合请求的平均耗时：如果每个请求耗时10ms，那100个连接每秒就能处理10000次请求（100/0.01）。
  • 总最大连接数（max-total-connections）：可以把所有路由的单主机最大连接数加起来，再加上10%-20%的缓冲（应对突发流量）。如果路由很多，也可以根据网关的资源限制来算——每个连接会占用一定内存，别设太高导致OOM就行。
• 另外一定要在压测或者生产环境下监控连接池的指标，比如httpclient.connections.leased（已占用的连接数）、httpclient.connections.available（空闲连接数）。如果已占用连接经常打满单主机或总连接数上限，还有大量等待的请求，那就得调大；如果大部分连接都处于空闲状态，就可以适当降低来节省资源。

4. 未使用ribbon/serviceId机制，而是通过host配置zuul.routes，如何确认网关的IsolationStrategy？目前看到配置为"ribbonIsolationStrategy": "SEMAPHORE"的内容 #

• 当你用基于host的路由配置（zuul.routes.*.url）而不是serviceId时，Zuul不会用Ribbon做负载均衡，而是直接用Apache HttpClient结合你配置的连接池（zuul.host.*相关参数）来处理请求。
• 你看到的ribbonIsolationStrategy配置其实和当前场景无关——这个配置只在使用serviceId结合Ribbon的路由里生效。
• 要确认基于host的路由的隔离策略：因为没用到Ribbon，Zuul默认会对路由处理用信号量隔离，但这和Ribbon的信号量设置是两回事。你可以查看应用里的ZuulProperties Bean，看它的isolation属性；或者开启org.springframework.cloud.netflix.zuul的debug日志，日志里会显示用的是SimpleHostRoutingFilter而不是RibbonRoutingFilter，这就说明没用到Ribbon的隔离策略。
• 另外你配置的zuul.semaphore.maxSemaphores是全局的Zuul过滤器执行并发限制，如果你要针对单路由设置，可以用zuul.routes.*.semaphore.maxSemaphores。

内容的提问来源于stack exchange，提问作者user1653027