網際網路架構演進至今，應用層的複雜度早已指數級上升，但處於最前端的全域性流量排程（GSLB），其核心邏輯似乎仍停留在十年前。傳統的 GSLB 更加關注“網路通不通”和“距離近不近”，這在靜態網頁時代或許足夠。但在動態內容為主、算力差異巨大的今天，僅僅依靠網路層的 ICMP 或 TCP 握手來判斷節點的承載能力，無異於隔靴搔癢。這種架構層級上的錯位，使得我們在面對突發流量時，不得不退化為人工介入的“人肉運維”。

這就引出了一個經典的運維場景： 監控面板上，某個邊緣節點的 CPU 負載出現異常爬升，斜率遠超預期。按照標準預案，你登入 DNS 控制檯，將該節點的解析權重從 80 下調至 60。由於 TTL 的存在，十幾分鍾後，流量曲線才開始緩慢回落，但這種滯後的“剎車”導致了另一個節點因承接過多溢位流量而告警。你不得不進行二次修正——但每一次修正，都意味著又要在這個長反饋鏈條中，再煎熬十幾分鍾。

在這樣反覆的微調和等待中，系統總算暫時穩定。但整個過程不僅需要時刻關注監控，還要忍受 DNS 傳播的延遲，在焦慮中等待每一次調整生效。流量切換了，服務也扛住了，但這種依賴手動、反覆試探換來的穩定，過程繁瑣且風險不低，總讓人感覺像是在走鋼絲。問題解決了，但解決問題的方式似乎並不理想。

流量排程的痛點，真的是“配置複雜度”嗎

我們習慣將這類問題歸結為“經驗不足”或“預案不完善”。但作為工程師，我們更應該審視工具本身：現有的排程工具，是否真正適合處理這類連續變化的場景？

想一下我們最常用的幾種排程工具：DNS 權重、健康檢查、甚至是一些簡單的 GSLB。它們有一些共同的特點：

• 離散：權重值是靜態配置，比如 80 或 70。它無法表達“當節點負載達到 75% 時，權重從 80 平滑降低到 75”這類動態、連續的響應策略。
• 二值：健康檢查的結果通常只有“傳統的健康檢查”或者“大多數健康檢查”。一個節點要麼線上，要麼離線，我們無法得知其“亞健康”狀態，比如“節點線上，但響應延遲已經開始飆升”。
• 突變：無論是健康檢查失敗，還是手動將權重降為 0，流量的切換都是斷崖式的。這種突變本身，就可能對使用者體驗和其他節點造成衝擊。

這些工具在設計之初，其核心假設是：伺服器的狀態是相對穩定的，變化是低頻的。但在今天，業務的彈性伸縮、流量的瞬時脈衝、服務的優雅降級，都讓系統狀態變成了一個連續變化的過程。我們試圖用“開關式”的離散工具，去管理一個狀態連續變化的系統。這種工具與場景的錯配，正是運維過程中“不踏實感”的根源。

在“全域性最優”與“故障止損”之間平衡的藝術

一個更理想的全域性流量排程工具，無非是下面三點樸素但關鍵的期望：

1. 平滑遷移：當某個節點的負載升高並呈現“亞健康”狀態時，系統應能自動、漸進地減少其流量，而不是等待人工干預，或節點徹底不可用後才“一刀切”。
2. 自動熔斷：當節點負載超過安全閾值，確實無法處理更多請求時，系統應能自動、快速地將其隔離，停止分發新流量，以保護節點自身和整體服務的穩定性。
3. 可觀測、可追溯：所有排程決策，無論是自動還是手動，都必須有清晰的記錄。我需要能事後審計，在任何時間點，系統到底做了甚麼，以及決策的依據是甚麼。

這三點並非高深的技術指標，而更接近工程師對生產工具的本質要求：將重複、高風險的判斷自動化，同時將最終的控制權和知情權交還給工程師。

從被動響應到“基於反饋迴路”的動態感知

OpenResty Edge 的 GSLB 功能，正是圍繞上述場景設計的。它嘗試用一種更貼近真實負載變化的方式來排程流量。

為甚麼 TCP 層的“探針”已不足以定義“健康”？

傳統的 GSLB 健康檢查多依賴 Ping 或埠探測，這隻能判斷節點“是否存活”，但無法評估其“服務質量”。

OpenResty Edge 將健康檢查的維度從網路層推進到了應用層，允許基於更能反映真實業務壓力的指標進行決策：

• requests per second：應用每秒處理的請求數。
• active connections：當前的活躍連線數。
• 系統分鐘級的平均負載。

這些應用層指標的意義在於，它們不再只關心節點“死活”，而是關心其“服務能力”和“健康度”。當排程系統獲取的資訊更貼近真實業務負載時，其決策自然也更精準。我們並非否定傳統方案，而是在當前複雜的業務場景下，僅有網路層資訊確實不夠用了。

用“動態水位”重構“靜態閾值”的容災邏輯

為了應對“亞健康”狀態，OpenResty Edge GSLB 引入了“高低水線（Watermark）”模型，以替代傳統的單一閾值。

• 低水位：當節點的某個指標（如 CPU 負載）超過低水位時，系統不會立即移除該節點，而是開始按比例調低其流量權重。這提供了一個緩衝區域，透過平滑、漸進地減少流量，給節點一個“喘息”和自我恢復的機會。
• 高水位：當指標繼續惡化並觸及高水位時，系統將觸發熔斷。此時，GSLB 會停止向該節點分發任何新流量，確保它不會被徹底壓垮，並保護整體服務。

這種設計的核心是避免流量在節點間劇烈、突兀地切換，它模擬了一個經驗豐富的工程師的決策過程：先溫和降級，再果斷熔斷。

提供決策的可解釋性

在控制系統中，自動化程度越高，對“狀態透明度”的要求就越嚴苛。對於 GSLB 這種處於流量入口的決策系統，如果運維人員無法在透過日誌或面板反推其決策依據，那麼這種自動化本質上是不可控的風險。

OpenResty Edge 的 GSLB 提供了直觀的視覺化面板，清晰地回答了“為甚麼排程”的問題：

• 計劃對比：系統直觀展示了 原始 DNS 計劃 和經過 GSLB 智慧調整後的 GSLB 計劃 的差異。
• 流量變化方向：我們透過視覺化的權重變化指示，量化了流量遷移的方向與幅度。透過醒目的紅綠箭頭，你能一眼看出系統正在減少哪些節點的流量，又在增加哪些節點的流量。（綠色表示上升，紅色表示下降）
• 歷史回放：系統支援回溯任意歷史時刻的排程快照。能夠精準還原事故發生時的全域性流量分佈與排程器決策。

可觀測性不是自動化的附加功能，而是其前置條件。只有當決策過程可被審計、可被解釋時，自動化排程才能真正被納入生產環境的信任鏈條中。

從“守著報警群”到“確定性的流量治理”

當 GSLB 具備了應用層感知、平滑排程和決策透明的能力後，運維的工作模式也隨之改變。

工程師的角色從被動響應的“執行者”，轉變為主動規劃的“策略制定者”。核心工作變成：

• 定義業務的“健康”模型（選擇合適的應用層指標）。
• 定義系統的干預策略（設定合理的水位線和熔斷條件）。

將排程邏輯固化為程式碼，交由控制平面在毫秒級的時間窗內完成“探測-決策-執行”的閉環。相比於人工介入產生的決策延遲與誤操作風險，系統化的自動化排程能提供工程所需的確定性。這本質上是將運維團隊從重複的熵增對抗中解放出來，使其關注點從透過 SSH 臨時修補，轉向對系統架構的長期治理。

若您的架構面臨以下複雜度挑戰，這種應用層視角的 GSLB 將體現出其設計價值：

• 多地域/多叢集部署：這是 GSLB 的主戰場，能最大化資源利用率和災備能力。
• 業務峰值不可預測：經常有突發流量，需要系統具備快速、自動的彈性排程能力。
• 非線性流量突發：面對脈衝式流量，常規手段的反饋鏈路往往過長。您需要的是一套能在邊緣側即時感知並自動執行降級或削峰策略的控制系統，而非依賴告警觸發的人工流程。

總結

最後，我們對 OpenResty Edge GSLB 的定位做一個技術上的收束。它不應該被視為一個試圖接管決策權的“大腦”，而更像是一個執行在邊緣側、具備應用層視野的執行時。它在你劃定的策略安全域內，透過更短的反饋弧長，以一種更線性的方式處理流量波動，避免了傳統排程“非黑即白”式的生硬切換。

OpenResty Edge GSLB 的核心價值不在於讓排程變得“全自動”，而是讓系統在負載變化時，其反應不再粗糙和滯後。畢竟流量治理的“顆粒度”，往往決定了系統穩定性的天花板。

如果您的業務正在經歷跨地域、高併發的流量挑戰，且苦於現有排程策略過於生硬或缺乏彈性，您可以先和我們的架構師聊聊。申請試用，我們的專家團隊將基於您的實際業務場景，為您拆解如何透過 OpenResty Edge 實現更平滑的流量排程。

如果您希望進一步探究上述排程邏輯在 OpenResty Edge 中的具體實現，或需要驗證其配置的靈活性，可以參考如何使用 OpenResty Edge 中的全域性伺服器負載均衡（GSLB）功能一文。該文件提供了從基礎接入到複雜場景覆蓋的完整操作檢視。

關於 OpenResty Edge

OpenResty Edge 是一款專為微服務和分散式流量架構設計的全能型閘道器軟體，由我們自主研發。它集流量管理、私有 CDN 構建、API 閘道器、安全防護等功能於一體，幫助您輕鬆構建、管理和保護現代應用程式。OpenResty Edge 擁有業界領先的效能和可擴充套件性，能夠滿足高併發、高負載場景下的苛刻需求。它支援排程 K8s 等容器應用流量，並可管理海量域名，輕鬆滿足大型網站和複雜應用的需求。

關於作者

章亦春是開源 OpenResty^® 專案創始人兼 OpenResty Inc. 公司 CEO 和創始人。

章亦春（Github ID: agentzh），生於中國江蘇，現定居美國灣區。他是中國早期開源技術和文化的倡導者和領軍人物，曾供職於多家國際知名的高科技企業，如 Cloudflare、雅虎、阿里巴巴, 是 “邊緣計算“、”動態追蹤 “和 “機器程式設計 “的先驅，擁有超過 22 年的程式設計及 16 年的開源經驗。作為擁有超過 4000 萬全球域名使用者的開源專案的領導者。他基於其 OpenResty^® 開源專案打造的高科技企業 OpenResty Inc. 位於美國矽谷中心。其主打的兩個產品 OpenResty XRay（利用動態追蹤技術的非侵入式的故障剖析和排除工具）和 OpenResty Edge（最適合微服務和分散式流量的全能型閘道器軟體），廣受全球眾多上市及大型企業青睞。在 OpenResty 以外，章亦春為多個開源專案貢獻了累計超過百萬行程式碼，其中包括，Linux 核心、Nginx、LuaJIT、GDB、SystemTap、LLVM、Perl 等，並編寫過 60 多個開源軟體庫。

關注我們

如果您喜歡本文，歡迎關注我們 OpenResty Inc. 公司的部落格網站 。也歡迎掃碼關注我們的微信公眾號：

翻譯

我們提供了英文版原文和中譯版（本文）。我們也歡迎讀者提供其他語言的翻譯版本，只要是全文翻譯不帶省略，我們都將會考慮採用，非常感謝！