一、先搞懂那些线程池参数到底是干啥的 #

你提到的几个参数都是Envoy IO线程池的核心配置，我给你翻译成大白话：

• NUM_CQS（完成队列数量）：这是Envoy用来存放异步IO完成事件的“待办清单”数量。多开几个清单可以避免所有IO事件挤在一处抢资源（比如锁竞争），一般建议设置成和CPU核心数相等或者两倍，比如8核机器设8或16，能显著降低高并发下的性能损耗。
• MIN_POLLERS（最小轮询线程数）：这是Envoy会一直“留岗”的IO监听线程数。哪怕服务器没什么请求，这些线程也会盯着socket的读写事件，保证新请求一来就能立刻响应。日常低负载稳定的话，设2-4就够。
• MAX_POLLERS（最大轮询线程数）：当请求暴增、IO事件变多的时候，Envoy最多能临时加多少个监听线程。超过这个数就不会再扩容了，防止线程太多导致CPU上下文切换频繁，反而变慢。一般设成CPU核心数的1-2倍就行。
• CQ_TIMEOUT_MSEC（完成队列超时时间）：监听线程在“待办清单”上没等到事件的话，多久会“下班”（如果当前线程数超过MIN_POLLERS）。设100-500毫秒比较合适，既能快速释放空闲资源，又不会因为频繁创建销毁线程额外消耗性能。

二、解决Envoy负载均衡问题的单线程池方案 #

原来三个端口暴露相同服务导致Envoy无法正常做负载均衡，本质是Envoy会把不同端口视为不同的服务实例，没法统一调度。改成单端口+单线程池的思路如下：

1. 合并服务端口：把原来三个端口的服务统一到一个端口对外暴露，这样Envoy就能把所有请求当成同一个服务的流量来做负载均衡了。
2. 配置适配的单线程池：根据你的服务器硬件和请求特征调整参数（参考上面的解释）：
   • 如果重请求占比高，MAX_POLLERS可以设高一点（比如等于CPU核心数的2倍），保证有足够线程处理IO密集型的长耗时请求；
   • NUM_CQS跟着CPU核心数走，避免队列拥堵；
   • MIN_POLLERS设为日常稳定负载需要的线程数，保证轻量请求的响应速度。
3. 额外优化：请求优先级区分：如果原来的“heavy-but-important”请求需要优先处理，可以在Envoy里加规则——比如根据请求头、路径或者proto里的字段，把这类请求标记为高优先级，让Envoy优先分配资源处理它们，避免被普通重请求阻塞。

这样调整后，既解决了Envoy的负载均衡问题，又能通过合理的线程池配置承载不同类型的请求，哪怕是一分钟的长耗时操作也能稳定处理。

内容的提问来源于stack exchange，提问作者Šimon Tóth