企业官网建设流程全解析

Envoy 过载管理器（Overload Manager）架构与配置实战：资源监控、触发器与过载动作的完整解析

【免费下载链接】envoyCloud-native high-performance edge/middle/service proxy项目地址: https://gitcode.com/GitHub_Trending/en/envoy

Envoy 的 Overload Manager 是一个可扩展的自保护组件，用于在连接数或请求量激增时，防止代理进程因内存、CPU、文件描述符等系统资源耗尽而崩溃。本文基于 Envoy 仓库中的架构文档与配置文档，完整讲解其“资源（Resources）→ 触发器（Triggers）→ 动作（Actions）”三层模型、全部内置资源监控器、过载动作与负载卸载点（Load Shed Points）的配置方法，并结合source/server/overload_manager_impl.cc等源码剖析触发器状态机、线程本地状态分发与概率式负载卸载的实现细节。

一、定位：保护 Envoy 自身，而非保护上游

过载管理器保护的对象是Envoy 服务器本身。文档明确指出：它与熔断机制（Circuit Breaking） 的目标不同——熔断主要是保护上游服务不被打垮，而过载管理器是当“过多的客户端连接或请求”压垮各种系统资源（内存、CPU、文件描述符等）时，保护 Envoy 进程自身不被压垮。

这一点在工程实践上意味着：过载管理器是边缘/入口侧的最后一道防线。配合 K8s、裸金属部署时，它可以避免单个 Envoy 实例 OOM 或被宿主机 CPU 打满，从而防止整个机队（fleet）进入级联故障（cascading failure）模式。

配置入口位于 Bootstrap 的overload_manager字段中，即 envoy/config/bootstrap/v3/bootstrap.proto 中的overload_manager。

二、总体架构：Resources → Triggers → Actions

过载管理器的工作方式是周期性地轮询一组资源的“压力（pressure）”，将压力值送入触发器进行求值，再根据触发结果执行动作。资源监控器、触发器和动作这三类组件都在启动时（startup）指定，不可动态增删。

2.1 Resources（资源）

资源是能被过载管理器监控的对象，其压力用[0, 1]区间内的实数表示。压力由一个**资源监控器（resource monitor）**计算得出。Envoy 使用统一的扩展（Extension）框架 定义资源监控器，内置的监控器包括：

2.2 Triggers（触发器）

触发器在每次资源压力更新时被重新求值，把压力值转换成动作状态（action state）。动作状态同样是[0, 1]的值，并分为两类：

当某个资源的压力值更新时，相关的触发器重新求值。对于配置了至少一个触发器的每个动作，其最终动作状态是所有触发器状态的最大值（max over triggers）。动作状态具体产生什么效果，取决于动作的配置与实现。

2.3 Actions（动作）

当触发器状态变化时，新状态被分发给注册过该动作的组件，这些组件随后可以改变连接与请求的处理方式。每个动作对输入状态的解读方式不同，有些动作会完全忽略scaling状态，只在saturated时生效。

一个重要的联动行为：当 HttpConnectionManager.append_local_overload 被设为true时，过载导致的 HTTP 请求丢弃会在连接管理器发出的本地应答（local reply）中携带 x-envoy-local-overloaded 响应头，便于客户端感知本次失败是由 Envoy 过载而非上游故障引起的。

三、完整配置示例：三级阈值保护

下面是一个完整的 Overload Manager 配置（来自配置文档）。它的语义是：堆内存达到 92% 时排水 HTTP/1/2/3 连接；达到 95% 时对新请求返回 503；达到 95% 时停止接受新 TCP 连接：

refresh_interval: seconds: 0 nanos: 250000000 resource_monitors: - name: "envoy.resource_monitors.fixed_heap" typed_config: "@type": type.googleapis.com/envoy.extensions.resource_monitors.fixed_heap.v3.FixedHeapConfig max_heap_size_bytes: 2147483648 actions: - name: "envoy.overload_actions.disable_http_keepalive" triggers: - name: "envoy.resource_monitors.fixed_heap" threshold: value: 0.92 - name: "envoy.overload_actions.stop_accepting_requests" triggers: - name: "envoy.resource_monitors.fixed_heap" threshold: value: 0.95 loadshed_points: - name: "envoy.load_shed_points.tcp_listener_accept" triggers: - name: "envoy.resource_monitors.fixed_heap" threshold: value: 0.95

其中refresh_interval是资源轮询周期（本例为 0.25 秒）。从源码看，若未配置该字段，OverloadManagerImpl 构造函数 通过PROTOBUF_GET_MS_OR_DEFAULT(config, refresh_interval, 1000)将其默认为 1000 毫秒。

四、Cgroup Memory 监控器：K8s 环境下的内存压力度量

envoy.resource_monitors.cgroup_memory通过读取 cgroup 内存子系统的用量与限额来跟踪内存压力，同时支持 cgroup v1 和 v2。它把压力报告为“当前用量 / 内存限额”的比值。限额的确定规则是：

1. 优先使用 cgroup 报告的内存限额（典型场景）；
2. 若配置了max_memory_bytes，则取“配置的max_memory_bytes”与“cgroup 限额”的较小值作为压力计算的分母，即max_memory_bytes充当分母上限；
3. 当 cgroup 未设置内存限额（v1 中为-1、v2 中为"max"）时，压力报告为 0。

示例配置：

resource_monitors: - name: "envoy.resource_monitors.cgroup_memory" typed_config: "@type": type.googleapis.com/envoy.extensions.resource_monitors.cgroup_memory.v3.CgroupMemoryConfig max_memory_bytes: 1073741824 # 1GB

配合动作即可在内存压力升高时卸载负载：

actions: - name: "envoy.overload_actions.stop_accepting_requests" triggers: - name: "envoy.resource_monitors.cgroup_memory" threshold: value: 0.95 # Trigger at 95% memory utilization

五、触发器详解：threshold 与 scaled

触发器把资源监控器连接到动作，支持两种类型：

源码中两个触发器的实现清晰印证了上述语义：

• ThresholdTriggerImpl：updateValue()中直接比较value >= threshold_，状态只在 saturated 与 inactive 之间切换；
• ScaledTriggerImpl：构造时强制校验scaling_threshold < saturation_threshold，否则返回InvalidArgumentError；updateValue()按三段式计算状态值。

而“动作状态取所有触发器最大值”的规则，在 OverloadAction::updateResourcePressure 中实现：每次某个触发器更新后，遍历triggers_取最大值写入state_，并同步刷新active/scale_percent两个统计量。

六、内置过载动作全表

6.1 shrink_heap：定期归还空闲内存

envoy.overload_actions.shrink_heap在被触发后会周期性尝试把堆上空闲内存归还给操作系统，对减少内存碎片、在使用 tcmalloc 时尤其有用。它可通过ShrinkHeapConfig配置：

来自仓库示例文件 shrink_heap_overload.yaml 的配置片段：

actions: - name: "envoy.overload_actions.shrink_heap" typed_config: "@type": type.googleapis.com/envoy.config.overload.v3.ShrinkHeapConfig timer_interval: 5s max_unfreed_memory_bytes: 52428800 triggers: - name: "envoy.resource_monitors.fixed_heap" threshold: value: 0.9

若不提供typed_config，动作使用默认值。源码侧，OverloadManagerImpl构造时若识别到ShrinkHeap动作且带有typed_config，会通过anyConvertAndValidate解析出ShrinkHeapConfig缓存下来（见 overload_manager_impl.cc#L525-L530），并在接口上以getShrinkHeapConfig()暴露给堆收缩器使用；实际的收缩逻辑位于 heap_shrinker.cc。

6.2 reduce_timeouts：按压力缩放超时时间

envoy.overload_actions.reduce_timeouts在资源压力升高时缩短 Envoy 等待各类交互完成的超时时长。每类超时的最小值可以配置为“对配置最大值应用一个缩放因子”或一个具体时长。示例（单个动作条目）：

name: "envoy.overload_actions.reduce_timeouts" triggers: - name: "envoy.resource_monitors.fixed_heap" scaled: scaling_threshold: 0.85 saturation_threshold: 0.95 typed_config: "@type": type.googleapis.com/envoy.config.overload.v3.ScaleTimersOverloadActionConfig timer_scale_factors: - timer: HTTP_DOWNSTREAM_CONNECTION_IDLE min_timeout: 2s

该配置让 HTTP 连接的空闲超时随堆使用率变化：堆用量低于 85% 时按 idle_timeout 原值超时；达到或超过 95% 时空闲连接在min_timeout（2 秒）后被关闭；介于 85% 与 95% 之间时按 scaled trigger 的线性公式在两者之间插值。例如RouteAction.idle_timeout = 600s、堆用量 92% 时，空闲超时为2s + (600s - 2s) × (95% − 92%) / (95% − 85%) = 181.4s。

若把min_timeout: 2s换成min_scale: { value: 10 }，则最小超时值改为基于最大值计算：idle_timeout = 600s时最小值为10% × 600s = 60s。

从源码看，reduce_timeouts是少数支持typed_config的动作之一：构造期解析timer_scale_factors得到 ScaledTimerTypeMap，其中min_timeout与min_scale二选一（min_scale按value / 100.0换算），重复配置同一 timer 类型会直接报InvalidArgumentError。这些最小值随后经scaledTimerFactory()注入到各超时计时器，实现“压力越大、超时越短”的动态缩放。

6.3 reset_high_memory_stream：按内存分桶重置流

注意：通过过载动作重置流目前仅对 HTTP/2 生效（文档中的显式警告）。

envoy.overload_actions.reset_high_memory_stream会重置“昂贵”的流。它必须通过 OverloadManager 的buffer_factory_config配置minimum_account_to_track_power_of_two：

buffer_factory_config: minimum_account_to_track_power_of_two: 20 actions: name: "envoy.overload_actions.reset_high_memory_stream" triggers: - name: "envoy.resource_monitors.fixed_heap" scaled: scaling_threshold: 0.85 saturation_threshold: 0.95

只有使用 ≥2^minimum_account_to_track_power_of_two缓冲内存的流才会被跟踪。上例中2^20 = 1MiB，即跟踪缓冲占用 ≥ 1MiB 的流，并按 8 个 2 的幂大小的桶分类（桶数当前硬编码为 8）：

重置策略按堆用量分档推进：堆用量低于 85% 时不重置任何流；达到 85% 开始重置最后一个桶（≥128MiB）的流；在85% + 1 × gradation处扩展到后两个桶（≥64MiB），其中gradation = (saturation_threshold − scaling_threshold) / 8；到达 95% 时所有 ≥1MiB 的流都有资格被重置。每次动作触发时每个 worker 最多重置 50 个流（硬编码上限），既减少被重置的流数量，也避免 worker 线程长时间停摆触发 Watchdog。由于只有 8 个桶，前几档梯度通常不应触发重置——除非真的存在 ≥128MiB 缓冲的异常流。

源码中，ResetStreams动作在构造 OverloadManagerImpl 时强制校验buffer_factory_config存在，否则直接拒绝启动（见 overload_manager_impl.cc#L518-L524），并注册ResetStreamsCount计数器。

七、Load Shed Points：连接/流生命周期上的卸载决策点

Load Shed Points与过载动作类似，都由触发器驱动，但决定的是 Envoy 在连接或流生命周期的某个关键点是否“卸掉”这段负载。可以把已配置的卸载点理解为一棵决策树：新连接上的请求会在生命周期的各个枢纽（junction）依次过检——即使它通过了前一个枢纽，条件变化后仍可能在更后面的枢纽被卸载。

与过载动作相比，Load Shed Points 的特点：

• 对条件变化更敏感，尤其适合大流量突刺场景；
• 过载动作更适合“Envoy 想卸负载、但 worker 线程并没有在主动处理对应连接/流”的情况，例如reset_high_memory_stream可以重置并不在推进的高内存流；
• 更易于集成自定义扩展：只要扩展能访问 Overload Manager，就可以注册公司内部（company internal）的自定义卸载点。

核心卸载点列表：

源码层面，LoadShedPointImpl 的shouldShedLoad()实现揭示了一个关键细节：卸载是概率式的，而非全有或全无。每个卸载点维护一个原子变量probability_shed_load_，其值取所有触发器状态的最大值；当概率为 1.0 时必然卸载，否则通过random_generator_.bernoulli(probability)做伯努利抽样决定本次是否卸载，并在命中时递增shed_load_count计数器。这意味着在scaling（未饱和）阶段，Envoy 按压力比例“随机丢弃”一部分请求——这正是配置文档所说的“对大流量突刺更敏感”的实现基础，也让压力曲线与卸载强度呈平滑的线性关系。

八、限制全局活跃下游连接数

要限制所有 listener 上的活跃下游连接总数，在 Overload Manager 中配置全局下游连接监控器：

resource_monitors: - name: "envoy.resource_monitors.global_downstream_max_connections" typed_config: "@type": type.googleapis.com/envoy.extensions.resource_monitors.downstream_connections.v3.DownstreamConnectionsConfig max_active_downstream_connections: 1000

要点（均出自配置文档）：

• max_active_downstream_connections不支持 runtime 更新。也可通过 runtime keyoverload.global_downstream_max_connections设置整数值，但该 key 已废弃，将在未来移除；
• 建议连接上限小于系统文件描述符限额的一半，为上游连接、文件和其他 fd 用途留出余量；
• 若未指定该值，全局连接数无上限，Envoy 启动时会打印警告；若不想设置上限又想消除警告，可把该值设得极大（约 2×10⁹）；
• Listener 可通过 Listener.ignore_global_conn_limit 设为true退出该全局限制；Admin listener 同样可用 Admin.ignore_global_conn_limit 退出。退出限制的 listener 仍可用来探测 Envoy 或采集统计（例如其他 listener 已达连接上限时）。注意：退出限制的 listener 的连接仍会被跟踪并计入全局限额；
• 若只想限制某个特定 listener，可用listener 配置中的 per-listener 限额；per-listener 与全局限额可同时指定，且各自独立生效。

仓库中的边缘最佳实践配置 edge best practices 给出了完整组合示例（其示例文件为 edge.yaml）。

九、CPU 密集型负载的 Brownout 保护

envoy.overload_actions.stop_accepting_requests配合envoy.resource_monitors.cpu_utilization监控器，可在请求量意外激增导致 CPU 饱和时，通过低成本的拒绝新请求来保护负载不被“棕化”（brown-out）。真正的根治手段是水平扩容，但过载动作能确保整个机队不会因此进入级联故障模式。部分平台方会默认安装该动作来保护机队，因为配置“目标 CPU 利用率百分比”比为每个负载配置“请求速率”更容易。

CPU 监控器支持两种模式：mode: HOST（默认，主机 CPU 利用率）与mode: CONTAINER（K8s 容器 CPU 利用率）。HOST 模式示例（取自 cpu_utilization_monitor_overload.yaml）：

overload_manager: refresh_interval: 0.25s resource_monitors: - name: "envoy.resource_monitors.cpu_utilization" typed_config: "@type": type.googleapis.com/envoy.extensions.resource_monitors.cpu_utilization.v3.CpuUtilizationConfig actions: - name: "envoy.overload_actions.stop_accepting_requests" triggers: - name: "envoy.resource_monitors.cpu_utilization" scaled: scaling_threshold: 0.80 saturation_threshold: 0.95

这里采用scaled触发器：CPU 利用率低于 80% 时不拒绝；80%–95% 之间按压力比例渐进拒绝（概率式 503）；≥95% 时全部拒绝。

K8s 环境下的负载卸载

在 Kubernetes 中，Envoy 工作负载常与其他应用共享节点资源。与其定义固定请求速率，不如用“目标容器 CPU 利用率百分比”这种更灵活的度量——Envoy 可基于容器级指标动态管理 CPU 使用，而不影响同节点的其他负载。将监控器设为mode: CONTAINER即可（取自 container_cpu_utilization_monitor_overload.yaml）：

overload_manager: refresh_interval: 5s resource_monitors: - name: "envoy.resource_monitors.cpu_utilization" typed_config: "@type": type.googleapis.com/envoy.extensions.resource_monitors.cpu_utilization.v3.CpuUtilizationConfig mode: CONTAINER actions: - name: "envoy.overload_actions.stop_accepting_requests" triggers: - name: "envoy.resource_monitors.cpu_utilization" scaled: scaling_threshold: 0.80 saturation_threshold: 0.95

十、统计指标：观测过载管理器的运行状态

每个已配置的资源监控器都有一棵以overload.<name>.为根的统计树：

每个已配置的过载动作的统计树同样以overload.<name>.为根：

每个已配置 Load Shed Point 的统计树也以overload.<name>.为根：

这些指标正是源码中makeGauge/makeCounter构造的overload. .active 等统计。运维上可以基于pressure与active/scale_percent搭建告警，用shed_load_count评估触发频率是否与容量规划匹配。

十一、源码结构深潜：主循环、线程本地分发与符号表

结合 source/server/overload_manager_impl.h 与实现文件，可以梳理出过载管理器的运行时骨架：

1. 轮询主循环：OverloadManagerImpl持有refresh_interval_（默认 1s）与一个Event::TimerPtr timer_，周期性刷新各资源监控器；每次刷新前后通过time_resources_last_measured_计算间隔并写入refresh_interval_delay直方图。资源更新采用“刷新纪元（flush epoch）”批量语义——Resource内部有pending_update_标志，同一纪元内重复更新会被合并（对应skipped_updates计数），更新最终经flushResourceUpdates()一次性分发给所有动作回调。
2. 动作状态的跨线程分发：动作回调可能注册在任意 worker 线程的 dispatcher 上。OverloadManagerImpl将各动作状态打包进state_updates_to_flush_/callbacks_to_flush_，再通过 ThreadLocal（ThreadLocalOverloadStateImpl）投递到每个 worker 线程，保证状态检查无锁、低开销。
3. 符号表加速热路径：NamedOverloadActionSymbolTable 把动作名字符串映射为从 0 开始顺序编号的符号索引，worker 线程读取状态时按索引取actions_向量，避免热路径上的字符串哈希。
4. 启动期严格校验：动作名必须是已知动作（Unknown Overload Manager Action）、资源名必须已配置（Unknown trigger resource）、动作/监控器不可重名、reduce_timeouts之外的动作不允许携带typed_config（shrink_heap除外）。这些校验全部发生在 OverloadManagerImpl 构造阶段，配置错误会在启动时直接暴露而非运行期。
5. 主动式资源（proactive resources）：除被轮询的资源外，管理器还维护一组“主动式资源”——它们不参与周期性刷新，而是由扩展在分配/释放内存等时机按需调用tryAllocateResource/tryDeallocateResource即时更新压力（见 ThreadLocalOverloadStateImpl），典型用于按 buffer 用量精细跟踪高内存流，这正是reset_high_memory_stream能区分各桶的基础。

十二、配置建议小结

• 阈值分级：先用disable_http_keepalive（较低阈值）排水连接释放资源，再用stop_accepting_requests（较高阈值）拒绝新请求，最后才动用 Load Shed Points 的强断开手段（如http2_server_go_away_and_close_on_dispatch）；
• 优先 scaled 触发器：对 CPU/内存这类连续压力指标，scaled 触发器配合概率式卸载与超时缩放能形成平滑的降级曲线，比 threshold 的“悬崖式”切换对上游更友好；
• K8s 场景：容器化部署优先用cgroup_memory或cpu_utilization(mode: CONTAINER)监控器，避免按主机指标误判同节点其他负载的资源占用；
• 可观测先行：上线前确认overload.*统计已接入监控系统，用shed_load_count与active验证触发行为符合预期；
• 谨慎使用破坏性动作：强制关闭类卸载点和reset_high_memory_stream都会直接中断在途流量，应设置很高的饱和阈值，并先在灰度环境验证。

综上，Envoy 过载管理器以“资源监控器 → 触发器 → 动作/卸载点”的三层可插拔模型，把“保护代理自身”从依赖运维经验的手工限流，变成了可声明、可观测、概率式平滑降级的内建能力；理解其 threshold/scaled 两种触发语义与 Load Shed Points 的概率卸载实现，是把它用对、用好的前提。

【免费下载链接】envoyCloud-native high-performance edge/middle/service proxy项目地址: https://gitcode.com/GitHub_Trending/en/envoy