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），僅供參考