Envoy 监听器运行时限流envoy.resource_limits.listener 连接数上限完全解析【免费下载链接】envoyCloud-native high-performance edge/middle/service proxy项目地址: https://gitcode.com/GitHub_Trending/en/envoy本篇围绕 Envoy 官方文档 监听器运行时配置 展开解析该文档定义的运行时键envoy.resource_limits.listener.name of listener.connection_limit的语义、生效机制与源码实现路径。读完本文你将能够理解如何用 Runtime 层动态调整单个监听器的活跃连接数上限弄清该限制在监听器接收连接路径上的具体检查点从 BasicResourceLimitImpl 与 ListenerImpl 源码中确认默认不限制、运行时动态覆盖的实现细节。一、文档定义的运行时设置docs/root/configuration/listeners/runtime.rst 原文内容非常精简其定义如下The following runtime settings are supported:envoy.resource_limits.listener.name of listener.connection_limitSets a limit on the number of active connections to the specified listener.即 Envoy 支持如下运行时设置envoy.resource_limits.listener.listener_name.connection_limit该设置用于为指定监听器设置活跃连接数上限。其中name of listener需要替换为监听器在 Bootstrap / LDS 配置中声明的name字段值例如监听器名为listener_0则对应的运行时键为envoy.resource_limits.listener.listener_0.connection_limit该键的取值是一个无符号 64 位整数表示允许同时存在accept 之后、关闭之前的连接数量。当当前活跃连接数达到该上限时监听器将拒绝新连接。这一能力让运维人员可以在不重启 Envoy、不重新下发监听器配置的情况下对某个监听器的连接压力进行在线限流或快速放开是过载控制overload shedding场景中的常用手段。二、运行时键的构造与默认值在 source/common/listener_manager/listener_impl.cc 中ListenerImpl构造函数会按监听器名称拼接出运行时键并据此创建连接数资源限制器cx_limit_runtime_key_(envoy.resource_limits.listener. config.name() .connection_limit), open_connections_(std::make_sharedBasicResourceLimitImpl( std::numeric_limitsuint64_t::max(), listener_factory_context_-serverFactoryContext().runtime(), cx_limit_runtime_key_)),这段代码确认了两个事实键名格式与文档完全一致envoy.resource_limits.listener. config.name() .connection_limit监听器名称直接取自 listener 配置的name字段静态默认上限为std::numeric_limitsuint64_t::max()即默认情况下监听器连接数几乎不受限。三、实现原理BasicResourceLimitImpl 的动态上限限制器的核心实现在 source/common/common/basic_resource_impl.h。该类继承ResourceLimit接口关键字段与行为如下current_std::atomicuint64_t原子计数器记录当前活跃连接数max_静态上限构造时传入对监听器而言为uint64_t::max()runtime_key_可选的运行时键用于动态读取上限。最关键的max()方法体现了运行时覆盖机制uint64_t max() override { return (runtime_ ! nullptr runtime_key_.has_value()) ? runtime_-snapshot().getInteger(runtime_key_.value(), max_) : max_; }也就是说每次判断上限时都会从 Runtime 快照中读取envoy.resource_limits.listener.name.connection_limit的值如果运行时未配置该键则回退到静态默认值max_监听器场景下为无上限。判断连接是否可新建的逻辑同样简洁bool canCreate() override { return current_.load() max(); }由于max()每次都会实时查询 Runtime 快照因此通过 Runtime 接口例如管理端口/runtime的更新或envoy set类操作修改该键后无需重启即可改变监听器的连接上限——这正是文档所述 runtime settings 的含义。类注释中还特意说明该实现以原子操作为主极端情况下资源计数可能瞬时超出上限但不会影响整体行为属于可接受的工程取舍。四、限制在连接接收路径上的检查点那么达到上限后新连接会在哪里被拒绝查看 source/common/listener_manager/active_tcp_listener.h可以确认连接计数与检查发生在监听器的 accept 路径上// 判定该监听器是否已不可再接纳连接 bool readyToAccept... { return !config_-openConnections().canCreate(); } // 连接关闭时计数回退 ... { config_-openConnections().dec(); } // 新连接 accept 后计数递增 void postIncNumConnections() override { config_-openConnections().inc(); }对应的资源访问器定义在 source/common/listener_manager/listener_impl.hResourceLimit openConnections() override { return *open_connections_; }整体工作流程为监听器 accept 新连接前通过openConnections().canCreate()判断当前计数是否已达max()若已达上限监听器判定为过载停止/拒绝接收新连接若未达上限连接建立后调用postIncNumConnections()使计数 1连接断开时调用dec()使计数 -1。此外对于内部监听器internal listener路径source/extensions/bootstrap/internal_listener/active_internal_listener.h 同样通过config_-openConnections().inc()/dec()维护同一计数器说明该限制对常规外部监听器与内部监听器的连接生命周期都成立。五、与监听器生命周期、过载管理的关联理解该运行时键的作用域还需要注意几个实现细节上限是 per-listener 的每个ListenerImpl拥有独立的open_connections_计数器source/common/listener_manager/listener_impl.h 中cx_limit_runtime_key_与open_connections_均为成员因此对某个监听器调低上限不会影响其他监听器连接数更新时会继承计数器在 source/common/listener_manager/listener_impl.cc 中open_connections_ origin.open_connections_;表明监听器配置更新如 LDS 更新触发重建时新旧监听器共享同一个连接计数对象保证限流计数在配置变更过程中不丢失与bypass_overload_manager/ignore_global_conn_limit的关系source/common/listener_manager/listener_impl.cc 显示监听器配置另有ignore_global_conn_limit()与bypass_overload_manager()两个选项说明本运行时键单监听器级连接上限与 Envoy 的全局连接数限制、过载管理器属于不同层级的控制手段可组合使用。六、实际使用建议结合文档与源码可以给出以下实操结论键名必须精确匹配监听器namename of listener是监听器配置中的名称字符串含下划线、点等特殊字符时按原样写入键名即可无需转义不设置即不限制由max()的回退逻辑可知未通过 Runtime 配置该键时上限为uint64_t::max()行为与无限制等价动态生效通过 Envoy 的 Runtime 机制修改该整数后canCreate()在下一次判断时即采用新上限可用于流量突增时临时收紧、事后放宽而无需重启进程或推送新的监听器配置达到上限的后果新连接在 accept 阶段被拒绝表现为客户端连接被拒/超时已建立的连接不受影响继续正常处理直到断开并释放计数。七、小结监听器运行时文档 虽只定义了一个键但它背后对应着 Envoy 一条完整的资源限流链路ListenerImpl按名拼接运行时键listener_impl.cc→BasicResourceLimitImpl从 Runtime 快照动态读取上限并原子维护计数basic_resource_impl.h→ 监听器 accept 路径通过canCreate()/inc()/dec()执行准入控制active_tcp_listener.h。掌握这条链路你就能在生产中安全地利用envoy.resource_limits.listener.name.connection_limit对任意监听器做在线连接数限流。【免费下载链接】envoyCloud-native high-performance edge/middle/service proxy项目地址: https://gitcode.com/GitHub_Trending/en/envoy创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Envoy 监听器运行时限流envoy.resource_limits.listener 连接数上限完全解析【免费下载链接】envoyCloud-native high-performance edge/middle/service proxy项目地址: https://gitcode.com/GitHub_Trending/en/envoy本篇围绕 Envoy 官方文档 监听器运行时配置 展开解析该文档定义的运行时键envoy.resource_limits.listener.name of listener.connection_limit的语义、生效机制与源码实现路径。读完本文你将能够理解如何用 Runtime 层动态调整单个监听器的活跃连接数上限弄清该限制在监听器接收连接路径上的具体检查点从 BasicResourceLimitImpl 与 ListenerImpl 源码中确认默认不限制、运行时动态覆盖的实现细节。一、文档定义的运行时设置docs/root/configuration/listeners/runtime.rst 原文内容非常精简其定义如下The following runtime settings are supported:envoy.resource_limits.listener.name of listener.connection_limitSets a limit on the number of active connections to the specified listener.即 Envoy 支持如下运行时设置envoy.resource_limits.listener.listener_name.connection_limit该设置用于为指定监听器设置活跃连接数上限。其中name of listener需要替换为监听器在 Bootstrap / LDS 配置中声明的name字段值例如监听器名为listener_0则对应的运行时键为envoy.resource_limits.listener.listener_0.connection_limit该键的取值是一个无符号 64 位整数表示允许同时存在accept 之后、关闭之前的连接数量。当当前活跃连接数达到该上限时监听器将拒绝新连接。这一能力让运维人员可以在不重启 Envoy、不重新下发监听器配置的情况下对某个监听器的连接压力进行在线限流或快速放开是过载控制overload shedding场景中的常用手段。二、运行时键的构造与默认值在 source/common/listener_manager/listener_impl.cc 中ListenerImpl构造函数会按监听器名称拼接出运行时键并据此创建连接数资源限制器cx_limit_runtime_key_(envoy.resource_limits.listener. config.name() .connection_limit), open_connections_(std::make_sharedBasicResourceLimitImpl( std::numeric_limitsuint64_t::max(), listener_factory_context_-serverFactoryContext().runtime(), cx_limit_runtime_key_)),这段代码确认了两个事实键名格式与文档完全一致envoy.resource_limits.listener. config.name() .connection_limit监听器名称直接取自 listener 配置的name字段静态默认上限为std::numeric_limitsuint64_t::max()即默认情况下监听器连接数几乎不受限。三、实现原理BasicResourceLimitImpl 的动态上限限制器的核心实现在 source/common/common/basic_resource_impl.h。该类继承ResourceLimit接口关键字段与行为如下current_std::atomicuint64_t原子计数器记录当前活跃连接数max_静态上限构造时传入对监听器而言为uint64_t::max()runtime_key_可选的运行时键用于动态读取上限。最关键的max()方法体现了运行时覆盖机制uint64_t max() override { return (runtime_ ! nullptr runtime_key_.has_value()) ? runtime_-snapshot().getInteger(runtime_key_.value(), max_) : max_; }也就是说每次判断上限时都会从 Runtime 快照中读取envoy.resource_limits.listener.name.connection_limit的值如果运行时未配置该键则回退到静态默认值max_监听器场景下为无上限。判断连接是否可新建的逻辑同样简洁bool canCreate() override { return current_.load() max(); }由于max()每次都会实时查询 Runtime 快照因此通过 Runtime 接口例如管理端口/runtime的更新或envoy set类操作修改该键后无需重启即可改变监听器的连接上限——这正是文档所述 runtime settings 的含义。类注释中还特意说明该实现以原子操作为主极端情况下资源计数可能瞬时超出上限但不会影响整体行为属于可接受的工程取舍。四、限制在连接接收路径上的检查点那么达到上限后新连接会在哪里被拒绝查看 source/common/listener_manager/active_tcp_listener.h可以确认连接计数与检查发生在监听器的 accept 路径上// 判定该监听器是否已不可再接纳连接 bool readyToAccept... { return !config_-openConnections().canCreate(); } // 连接关闭时计数回退 ... { config_-openConnections().dec(); } // 新连接 accept 后计数递增 void postIncNumConnections() override { config_-openConnections().inc(); }对应的资源访问器定义在 source/common/listener_manager/listener_impl.hResourceLimit openConnections() override { return *open_connections_; }整体工作流程为监听器 accept 新连接前通过openConnections().canCreate()判断当前计数是否已达max()若已达上限监听器判定为过载停止/拒绝接收新连接若未达上限连接建立后调用postIncNumConnections()使计数 1连接断开时调用dec()使计数 -1。此外对于内部监听器internal listener路径source/extensions/bootstrap/internal_listener/active_internal_listener.h 同样通过config_-openConnections().inc()/dec()维护同一计数器说明该限制对常规外部监听器与内部监听器的连接生命周期都成立。五、与监听器生命周期、过载管理的关联理解该运行时键的作用域还需要注意几个实现细节上限是 per-listener 的每个ListenerImpl拥有独立的open_connections_计数器source/common/listener_manager/listener_impl.h 中cx_limit_runtime_key_与open_connections_均为成员因此对某个监听器调低上限不会影响其他监听器连接数更新时会继承计数器在 source/common/listener_manager/listener_impl.cc 中open_connections_ origin.open_connections_;表明监听器配置更新如 LDS 更新触发重建时新旧监听器共享同一个连接计数对象保证限流计数在配置变更过程中不丢失与bypass_overload_manager/ignore_global_conn_limit的关系source/common/listener_manager/listener_impl.cc 显示监听器配置另有ignore_global_conn_limit()与bypass_overload_manager()两个选项说明本运行时键单监听器级连接上限与 Envoy 的全局连接数限制、过载管理器属于不同层级的控制手段可组合使用。六、实际使用建议结合文档与源码可以给出以下实操结论键名必须精确匹配监听器namename of listener是监听器配置中的名称字符串含下划线、点等特殊字符时按原样写入键名即可无需转义不设置即不限制由max()的回退逻辑可知未通过 Runtime 配置该键时上限为uint64_t::max()行为与无限制等价动态生效通过 Envoy 的 Runtime 机制修改该整数后canCreate()在下一次判断时即采用新上限可用于流量突增时临时收紧、事后放宽而无需重启进程或推送新的监听器配置达到上限的后果新连接在 accept 阶段被拒绝表现为客户端连接被拒/超时已建立的连接不受影响继续正常处理直到断开并释放计数。七、小结监听器运行时文档 虽只定义了一个键但它背后对应着 Envoy 一条完整的资源限流链路ListenerImpl按名拼接运行时键listener_impl.cc→BasicResourceLimitImpl从 Runtime 快照动态读取上限并原子维护计数basic_resource_impl.h→ 监听器 accept 路径通过canCreate()/inc()/dec()执行准入控制active_tcp_listener.h。掌握这条链路你就能在生产中安全地利用envoy.resource_limits.listener.name.connection_limit对任意监听器做在线连接数限流。【免费下载链接】envoyCloud-native high-performance edge/middle/service proxy项目地址: https://gitcode.com/GitHub_Trending/en/envoy创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
