如何基于开放网络连接数实现ECS Task自动扩缩容？

你猜测的句柄（文件描述符）指标并不适用。句柄数统计的是进程持有的所有文件、网络连接资源引用，其中包含大量空闲长连接、未释放的僵尸连接，和实际正在处理的并发请求量没有线性对应关系，用它做扩缩容依据很容易出现误判。

你的场景属于典型的应用层瓶颈触发的性能问题：服务CPU、内存等基础资源水位低，但单实例的请求处理单元（工作线程/协程、数据库连接池）被占满，导致新请求无法被处理，这类场景不能依赖传统的CPU、内存利用率指标做扩缩容，推荐优先选用以下几类指标：

• 服务内埋点的在途请求数（in-flight requests）
  这是最精准的指标，统计的是当前已经被服务接收、还未完成处理返回响应的请求总量。你可以先通过压测测出单实例能稳定承载的最大在途请求阈值，比如单实例稳定承载80个并发请求不出现排队，就可以配置自动扩缩容规则：当集群平均单实例在途请求数超过64（80%阈值）时触发扩容，当平均单实例在途请求数低于16时触发缩容。
• 请求排队相关指标
  如果你的服务自身维护了请求等待队列，或者前置的网关、负载均衡有排队统计，可以用队列堆积长度、请求平均排队等待时长作为扩缩容依据。这类指标可以提前感知并发耗尽的趋势，在请求报错前就完成扩容，比单纯统计在途请求数更稳妥。
• 网关层统计的活跃请求数
  如果不想改动业务代码做埋点，可以直接从服务前置的API网关、K8s Ingress层获取单后端实例的活跃请求数做判断，注意要和空闲长连接数做区分，不要把保持连接状态但没有实际请求传输的空闲连接算入统计值。
• 错误率类兜底指标
  可以把请求超时率、5xx响应占比作为兜底校验指标，当并发请求耗尽时，通常会先出现503服务不可用、请求超时的报错，和上述并发指标配合使用可以避免单一指标异常导致的误扩缩容。

注意不要直接用QPS（每秒请求数）作为核心扩缩容依据：QPS是单位时间的请求吞吐量，实际并发数=QPS*平均接口响应时长，同样的QPS下，如果接口响应变慢，并发数会线性上涨，仅靠QPS判断完全无法匹配实际的负载情况。

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