OpenResty Edge™ 概覽

# 概覽

本文件描述 OpenResty Inc. 提供的 OpenResty Edge 商業產品的要求。

這份文件同時還定義 OpenResty Inc. 內部以及 OpenResty Inc. 與其客戶之間有效溝通的術語。

當前的 OpenResty Edge 並未實現所有本文描述的特性。如果有疑問，請聯絡 OpenResty Inc. 以獲取更多細節。

# 目標

OpenResty Edge 是一個基於開源 OpenResty web 平臺的軟體平臺，用於提供動態負載均衡、和反向代理叢集。 整個產品或者其中一些核心部件可以用於內容分佈網路 (CDN) 和其他以 web 為基礎的業務 (用於 web 閘道器)。

雖然 OpenResty 是構架在 NGINX 和 LuaJIT 的基礎之上，但是 OpenResty Edge 的使用者不需要有 NGINX 或者 Lua 的背景知識。大多數常見的配置和操作可以很容易的在 web UI 中處理，不需要編碼，也不需要很多配置檔案的編輯。 它的設計理念是在一箇中心 web 控制檯中，很容易的控制和管理一個大型的網路叢集。

那些有複雜客戶化需求的高階使用者，也可以透過 Edge 這個業務定義語言寫出特殊的規則，然後 Admin 節點會自動把這些規則編譯成高度最佳化的 Lua，C 以及其他可用 JIT 的程式碼並且推送給閘道器叢集 (也就是 edge) 中部分或者全部機器。

OpenRest Edge 網路控制檯的所有標準功能和 web 表單最終會轉化為 Edge 語言規則，這些規則享有完全相同標準的最佳化。

技術前沿的使用者更可以透過書寫 Lua 或者 C 程式碼擴充套件、或者定製 OpenResty Edge 平臺，比如給 OpenResty 引入定製化的 Lua 庫或者裝載客戶定製的 NGINX C 模組。

# Edge 管理員控制檯 & 日誌伺服器

我們定義閘道器為一組 (或者一群) 直接面對外 (也就是網際網路、或者是私有內網中面對所有終使用者) 的機器，因為 邊緣/edge 這個詞已經在 OpenResty Edge 產品中有許多使用，所以我們在本文中用 閘道器叢集 來表示面對外的叢集。

閘道器叢集可以部署在 Amazon Web Services 和 Google Cloud Platform 等公共雲上，也可以部署在私有資料中心或者客戶自有的機器上。

我們定義管理站 (admin site) 為執行 OpenResty Edge 管理站的中心節點或 web 控制器。我們允許多個部署多個 web 管理節點，但是這些管理節點都在後端共享相同的後端資料庫 (無論是 PostgreSQL 或者 MySQL) 或一個資料庫叢集。管理節點通常不執行在閘道器節點上，而是在使用者自己的專用網路（LAN）中執行。如果你願意，管理節點也可以部署在一個閘道器叢集中，與工作節點共享伺服器。

管理站接收使用者發出的指令或配置，然後以接近實時的方式，直接或者間接地給閘道器叢集節點推送這些變更。

閘道器節點按照閘道器群集或僅群集進行分組。有關群集的更多詳細資訊，請參見下文。

# 全域性配置

閘道器節點透過加密連線（受 TLS 保護）連線到管理站點以進行通訊，Admin 站點監聽特殊的 TCP 埠。 閘道器節點之間使用隨機生成或使用者提供的 SSL 伺服器和客戶端證書對來驗證管理站點客戶端。 新閘道器節點必須在管理站點上被批准，才能加入閘道器網路中的特定閘道器叢集。

閘道器節點還連線到特殊的日誌伺服器，以實時提供錯誤日誌和指標資料。

也可以在群集設定中配置管理站點僅與每個群集的一個或多個“主節點”通訊，而不是使管理站點直接與所有閘道器節點通訊。 然後，每個群集的主節點將相應地將配置廣播到同一群集中的其餘節點。 這樣我們就不用開啟所有閘道器節點到管理站點的連線，只需要開啟“主節點”的即可。 在這種配置下，每個叢集必須至少有一個“主節點”，但也可以宣告多個“主節點”用於冗餘。（注意：這個特性還沒有實現。現在，所有閘道器節點都直接與管理站點通訊。）

每個閘道器節點的 OpenResty/NGINX 程序都有自己的基於高速記憶體對映資料庫 (LMDB) 永久儲存後端，可以用於儲存管理站或者本叢集主節點推送過來的配置。

因此，即使一個閘道器節點短時下線，然後再上線，它也只需要從當前叢集的主節點獲取和同步它下線以來最新的配置變化即可。 這些新上線的節點自動從當前叢集的主節點同步程式碼和資料。如果是主節點上線，那麼它會從同叢集其他節點同步或者直接從管理站同步 (如果存在與管理站之間的路由的話)。

因為每個閘道器節點都有自己的本地永久儲存可以儲存所有配置資料 (或者說後設資料)，所以即使在管理站點或者當前叢集的主節點下線或者無法連線的情況下，它也可以很好地處理自己的網際網路流量。 在這種異常情況下，雲工作節點只是用不上最新版本的配置資料而已。換句話說，我們的雲工作節點是自包含的。

日誌伺服器還將從所有或部分閘道器節點收集日誌資料。它可以以類似的方式配置，但方向相反。也就是說，所有閘道器節點都會把訪問日誌和錯誤日誌資料傳送到當前閘道器叢集中的當前主節點，並且每個閘道器叢集的主節點將資料傳送回日誌伺服器。

使用者可以可以配置成只把統計處理後的訪問日誌傳送給主節點，這樣可以大大節約資料收集的頻寬使用。同樣的，在邊緣節點上，錯誤日誌也可以透過合併類似的錯誤日誌來聚合。

日誌伺服器通常部署在與閘道器節點和 Admin 站點不同的專用伺服器中。

管理站點控制收集邊緣節點上的哪些資料，以及如何處理這些資料。 因此管理站會盡量不去收集那些當前使用者配置不需要收集的資料，並且使用者可以隨時在每個雲工作節點上增加探針，用以收集更多的資料。 所有這些動作都是自動發生，不需要使用者手工修改任何閘道器節點。

Admin 站點的 web UI 完全執行在使用者的瀏覽器中，而 web UI 透過 REST API 與管理站點的伺服器通訊。 因此，使用者可以根據自身需要把 Admin 站點的功能整合到自己的 Web UI 或者自己的工具鏈 (比如命令列工具) 中。

使用者可以在人類可讀的報告中，顯示當前應用程式配置（或任何早期版本的頂部）的快照。 此報告可以儲存為外部的純文字檔案，以後可以在管理站點中匯入和還原相應的配置。（注意：這仍有待實施。）

# 伺服器過載 & 程式碼熱替換

管理站點推送作給閘道器節點的大多數配置都不需要閘道器節點的過載，相反，它在每個單獨的伺服器程序內執行程式碼和資料的熱替換。 比如，在大多數配置和程式碼更新的時候，我們不需要給 NGINX 程序傳送 HUP 過載訊號。 大多數程式碼都是實時安全替換的，並不需要把當前的 NGINX 工作程序替換成新的程序 (通常在向 NGINX 守護程序傳送 HUP 訊號的時候會發生的事情)。 這就意味著我們對當前長期執行的客戶端和連線的影響為 0，而對一個應用的配置推送不會影響叢集中其他同一個 NGINX 工作程序服務的 Edge 應用。

的確還有一些配置變更需要伺服器過載或者重啟操作，比如增加一個帶有新的監聽埠 (或者服務埠) 的應用。在這種場合下，管理站點會在 web UI 上通知使用者需要進行伺服器程序的過載，並且在目標閘道器節點上安排自動過載。 只有超級使用者可以推送需要伺服器過載或者 (0 當機時間) 的重啟。超級使用者可以選擇特定的閘道器節點過載或者重啟的計劃，以最小化線上的影響。

管理站也可以給閘道器節點傳送命令進行完整的 OpenResty Edge 產品的自更新。顯然，這樣的軟體更新也要求一個全面的服務重啟操作。

# 守護程序 & 程序

OpenResty Edge 產品只在閘道器節點和管理站點上執行 OpenResty 版本的 NGINX 程序。 另外，管理站點要求一個關係型資料庫 (PostgreSQL 或者 MySQL) 作為後臺儲存。 在閘道器節點上不需要執行關聯式資料庫。

除了 OpenResty/NGINX 程序 (包括閘道器節點和管理站點) 以及管理站點的關係型資料庫之外，不需要執行 FastCGI 或者任何其它守護程序。

閘道器中的 OpenResty / NGINX 程序還可以使用 Memcached 或 Redis 協議，並使用 NGINX 的共享記憶體儲存，以及可選的基於 LMDB 磁碟作為後端。 這意味著相同的 OpenResty 程序可以充當分散式記憶體快取系統，而無需額外的守護程序。 這些快取節點具備 OpenResty Edge 產品提供的所有其它靈活性，包括靈活的統計和 Edge 語言的指令碼能力。

# 應用

應用是針對一個或多個域名的、帶著一套服務埠的配置集合。

應用程式由至少一個域名（比如 api.foo.com）指定。對於 *.foo.com 這樣的萬用字元域名，就包含 foo.com 及其所有子域名。

一個應用也可以使用一套服務埠 (或者監聽埠) 宣告得更明確。比如，api.foo.com:8080​ 可以使一個內部 API 服務的特殊應用，這樣就可以跟公開的服務 api.foo.com:80​ 區分開。

應用可以選擇下列服務協議之一 (也就是，用於服務客戶端的協議):

• HTTP/HTTPS
• TCP
• UDP
• DNS

服務協議定義應用的型別。它也可以定義應用使用的預設服務埠。比如，HTTP 通常使 用 80 埠，而 DNS 通常使用 53 埠。

應用的概念非常類似 Apache 和 NGINX 那樣的 HTTP 伺服器中“虛擬主機”或者“虛擬伺服器”的概念。

應用定義 OpenResty Edge 配置的最小的粒度。每個應用都可以獨立配置，但是一個應用可以選擇從其它應用繼承配置，這樣就可以只需要增量定義自己需要覆蓋的配置。

應用繼承可以只是在建立“子應用”的時候對“基礎應用”的一個快照，或者在“子應用”建立後的全生命週期裡跟隨所有“基礎應用”的新變更。應用繼承通常發生在一個子域名希望繼承所有根域名現有的配置的時候，比如 api​.​foo.com​ vs ​foo.com​。在網站中，跨多個不同的子域名共享多個公共的配置是一個很方便的做法。

使用者輸入賬號名和密碼登入 Admin 站點，然後選擇自己想操作的應用。另外，已登入的使用者可以透過宣告域名和可選的監聽服務埠號 (或者多個埠號) 的方法來建立應用。

# 閘道器叢集

閘道器叢集就是一組執行 Edge 的機器叢集 (參考前面 Edge 的定義)。管理站會嘗試管理閘道器叢集中所有的機器。 管理站點自己也可以是一個叢集的節點，不過 (通常) 管理站並不執行在雲叢集中。

使用者需要在中心的管理站上自行輸入所有機器的細節 (比如主機名)，然後根據他們的物理位置或者使用者自己的標準分組。

如果給予了足夠的許可權，閘道器叢集的機器可以在多個不同應用之間共享。所以多個使用者天生就可以看到同一個的叢集的資訊。

# 使用者 & 角色

使用者是管理站點的登入賬號。每個使用者可以授予一個或多個“角色“。 一個角色是一系列可以授予使用者的訪問規則。比如，我們可以有一個使用者管理員角色和一個超級管理員角色。

一個超級管理員可以建立更多使用者，並且授予他們不同的訪問許可權和不同的角色。 一個超級管理員角色擁有使用所有管理站所支援操作的許可權。我們在本文件裡把超級管理員角色稱為超級使用者。

比如，一個有足夠許可權的使用者可以給一個應用 (或者多個應用) 建立只讀角色。使用者也可以定義一個只能配置特定應用的角色。

通常，只有超級使用者可以推送那些需要伺服器過載或者重啟閘道器叢集的配置變更。普通使用者仍然可以做出這些變更，他們只是不能推送。

# 版本 & 釋出

Admin 站點具有對大多數閘道器配置的內建版本控制支援。我們使用自己的增強演算法，這些演算法來自 patch 理論學科的最新學術研究。

當使用者更改了配置（無論它有多小）後，一個新的變更就在管理站點中的當前配置集之上生成了。 從未釋出的變更稱為 pending changes。

使用者還可以建立包含所有 pending changes 的版本。版本只是修訂本身的標籤。

使用者可以自由地恢復（或回滾）到任何歷史版本。他還可以自由地將當前版本推送到當前應用程式可見的所有閘道器節點，或僅推送到閘道器節點或閘道器群集的指定子集。 這種不同版本配置的閘道器節點子集稱為分割槽。

此類分割槽通常用於為企業客戶分離外部和內部 Web 應用，或者保留一組專用節點用於新配置（或客戶自己的後端應用）的 A/B 測試。

使用者可以比較不同版本的差別，管理站可以給出差別的人類可讀的形式。版本歷史資訊自身總是隻讀的。

如果多個使用者嘗試同時編輯同一個應用，管理站點的 web UI 會給出一個警告資訊。（注意：這個特性還沒有實現）

# 測試

Admin 站點允許使用者建立自定義測試用例，以便向所有或選定的閘道器節點子集發出測試請求，並根據使用者定義的標準自動檢查響應。 允許兩種不同的方式：

1. 使用 Web 表單指定請求 URI，方法，正文，標題等，以及預期的響應功能，如 200 狀態程式碼，響應正文中某些關鍵字的存在，Content-Type 的特定值、響應標題等；
2. 使用 TestML 可以在基於 Web 的程式碼編輯器（甚至是完整的 Web IDE）中輕鬆指定許多此類測試用例。

有關 TestML 語言的更多詳細資訊，請參見下文：

www.testml.org

這些測試是管理站點配置的一部分，也可透過變更和釋出進行版本控制。

可以為 A/B 測試配置專用的閘道器叢集（稱為分割槽）。

測試用例可用於針對使用者選擇的特定閘道器節點啟動負載測試。 使用者可以指定要傳送的請求總數以及負載測試中使用的併發連線數。 類似於 Apache httpd 的 ab 工具，但都在 Admin 站點內。 負載測試報告可以報告吞吐量（req/sec，bytes/sec）以及請求延遲。 此類基準測試結果也將保留在當前配置變更中，以供將來參考和比較使用。

也可以使用實際流量測試新配置，但不會對真實客戶端使用者產生任何影響。 管理站點使用者可以配置一些特定的閘道器節點（稱為閘道器叢集分割槽）以自動複製其部分或全部傳入流量，並將重複的流量重定向到專用於測試的某些離線閘道器群集。 這些線上閘道器節點也將以靜默方式和非同步方式丟棄來自這些離線閘道器群集的任何響應。 這類似於 tcpcopy 之類的工具，但直接在 OpenResty / Nginx 程序內的七層級別上執行。與四層流量複製工具（如 tcpcopy）不同，OpenResty Edge 的七層方法也可以毫無問題地與 SSL 流量一起使用。(注意：這個特性還沒有實現）

# Edge 語言

OpenResty Edge 給使用者提供 DSL (領域定義語言)，叫 Edge (或者 edgelang)，用於指令碼化複雜規則，或者直接在雲服務節點中實現商業邏輯。

Edge 語言是一種規則為基礎的語言，用來宣告那些可以在閘道器節點上執行的規則。

使用者直接在管理站點輸入 Edge 語言規則 (透過 web 程式碼編輯器)，然後管理站把 Edge 語言原始碼編譯成最佳化過的 Lua 程式碼和資料，並把它們直接或者間接的推送給閘道器節點。

管理站點也給使用者提供 web 表單，用於新增簡單的規則，而不用瞭解 Edge 語言，也不用寫任何指令碼。

Edge 語言規則也是應用配置的一部分，也會接受變更和釋出的版本管理過程。

在幕後，許多標準管理功能模組也是以 Edge 語言（或 Edge 語言程式碼模板）實現。

Admin 站點為 Edge 語言指令碼和除錯提供了一個簡單的基於 Web 的 IDE。這可以與上面測試部分中提到的 TestML 中指定的測試套件整合。

它還支援在 Edge 語言原始碼中使用 Perl 的 TT2 模板語言語法，實質上是建立模板化的 Edge 語言程式。管理站點可以從這些 Edge 程式碼模板自動生成 RESTful API 和新的 Web UI，允許使用者透過將引數資料提供到這些模板中來重用這些模板。 此外，模板層（如宏層）可用於生成許多類似但仍然不同的 Edge 語言規則，而無需重複程式碼。 未來版本的 edgelang 可以採用完整的整合宏語言功能，而無需任何類似前處理器的模板層。

高階使用者可以客戶化和/或透過定義他們自己的判斷函式、動作函式和其他 Edge 語言層面的原語來擴充套件 Edge 語言。而無需變更 Edge 語言的編譯器。使用者可以用 Edge 語言自 行定義新的原語，甚至新的 Edge 庫。超級使用者甚至可以在 Edge 語言環境裡頭呼叫外部 Lua 過程或者庫函式。也可以透過擴充套件 Lua 呼叫外部的 C 庫函式 API，因為 LuaJIT 支援 透過其標準的 FFI 擴充套件呼叫外部 C API。 超級使用者也可以定義執行在管理站內部的 Edge 語言規則，在雲叢集的實時執行統計的基礎上，在雲叢集裡頭自動分配雲規則和資料。 請參考 Edge 語言使用者手冊獲取更多細節。

高階使用者可以透過在 Edge 語言級別定義自己的謂詞函式，操作函式和其他基元來自定義和/或擴充套件 Edge 語言。不需要更改 Edge 語言編譯器。使用者可以使用 Edge 語言自己定義新的基元甚至是新的 Edge 庫。 超級使用者甚至可以從 Edge 語言中呼叫外部 Lua 例程或庫。由於 LuaJIT 支援透過其標準 FFI 擴充套件呼叫任意外部 C API，因此外部 Lua 呼叫也支援呼叫外部 C 庫 API。

超級使用者還可以定義要在管理站點執行的 Edge 語言規則，以根據來自閘道器的實時指標自動在閘道器上分發閘道器規則和資料。

有關更多詳細資訊，請參閱 Edge 語言使用者手冊。

# SSL 伺服器

即使 TLS 更合適，我們也會在本文件中使用術語 SSL。

使用者可以透過管理站點為當前應用程式中的 SSL 伺服器新增 SSL 證書和私鑰，並將其與其他應用程式配置一起推送。

使用者可以在當前的閘道器叢集節點上配置 SSL 會話資料共享（僅適用於 SSL 會話 ID）（叢集間共享需要非同步資料分發，如 Datanet，否則延遲將失控）。 SSL session 資料共享對於不支援 TLS session tickets 的舊 HTTPS 客戶端非常重要，並且可以顯著減少昂貴的 SSL 握手數量。

使用者可以無條件地或有條件地配置當前客戶端 SSL 連線允許哪種 SSL 協議和 SSL 密碼。是否啟用 OCSP 裝訂和嚴格的 OCSP 裝訂驗證。

對於啟用 HTTPS 的應用程式，管理站點將定期將隨機生成的 TLS 會話票證金鑰分發到所有閘道器節點（或閘道器叢集的主節點）。 將每小時生成 TLS session tickets 金鑰，可以將其配置為任何其他時間段。將在整個閘道器節點中維護最多 12 個 TLS session tickets 金鑰的陣列。 較舊的 session tickets 金鑰將逐步淘汰並被丟棄。維護的 TLS 會話票證金鑰的大小也是可配置的。 因此，使用者可以選擇保留過去 24 小時內生成的所有金鑰， 例如，當他將陣列大小設定為 24 並將新金鑰週期設定為 1 小時。 TLS session tickets 對於減少 Edge 上昂貴的 SSL 握手也至關重要。並且跨邊緣共享 session tickets 金鑰非常重要。

使用者還可以啟用或禁用準實時資料分析，以分析 SSL 會話恢復率（在 SSL 會話 ID 或 TLS session tickets 上），SSL 協議使用分配，SS L 密碼使用分配以及 Edge 上的其他指標。

自定義速率限制和併發限制規則也可以在 SSL 握手請求中指定，可以是 Web 表單，也可以是自定義 Edge 語言規則。可以為流量控制的實際效果配置預定義或自定義線上指標。

HTTP/2 也可以由使用者配置。

# WAF

OpenResty Edge 主要基於 ModSecurity 的核心規則集（CRS）提供 Web 應用程式防火牆（WAF）產品。這些 CRS 規則作為 Edge 語言規則實現，不過是從其原始的 ModSecurity 配置檔案生成的。

規則集模組或單個規則可以啟用或禁用 WAF 規則。還為一些 WAF 規則命中的請求提供準實時資料分析，以便使用者分析 Edge 上的惡意請求。

使用者還可以透過提交 Web 表單或直接新增新的 Edge 語言規則來新增新的 WAF 規則。 或者，使用者可以透過編輯 Web 表單欄位或底層 Edge 語言原始碼來編輯現有的 WAF 規則。

還支援僅在某些客戶端請求上啟用 WAF 的自定義規則，例如僅在 POST 請求上啟用 WAF，或僅在具有特定模式的 URL 上啟用 WAF。

使用者可以配置 WAF 阻止或拒絕請求時採取的操作。例如，使用者可以選擇顯示帶有驗證碼挑戰的自定義錯誤頁面。 一旦客戶端透過驗證碼挑戰，就會植入一個特殊的 cookie，以便在可配置的時間段內為客戶提供免費通行證。 被 WAF 阻止的小型客戶端請求也可以臨時快取在伺服器端，並且一旦客戶端在指定的時間段內透過驗證碼質詢，就可以自動重放。

# 請求過濾 & 改寫

使用者可以指定自定義規則（透過 Web 表單或 Edge 指令碼）來過濾和/或重寫在 Edge 上提供的某些客戶端請求。

例如，使用者可以檢查和/或重寫 URL 路徑，以重寫 URL 查詢字串或單個 URI 引數。使用者還可以輕鬆地重寫請求方法，請求頭，cookie，請求正文資料（包括 URL 編碼的 POST 引數）。

當某些條件符合當前客戶端請求時，使用者可以選擇執行重定向（如 301, 302 和 307 重定向），或者僅提供自定義錯誤頁面或直接中止連線。

從客戶端 IP 地址派生的地理資訊也可以用在使用者規則條件中，例如從特定城市，國家或地區過濾掉客戶端。 如果使用者開啟了請求過濾和改寫的自動資料分析，那麼也可以得到相關的資料。對應的資料收集程式碼會同時自動部署到 Edge 裡的每個使用者規則。這樣，當具體的請求命中該規則的時候，使用者就可以看到某個規則命中了多少次 (或者是未命中多少次)，這些資料是軟實時地發生。

在這個階段，我們也可以開啟速率控制，流量定製和併發控制。使用者同時可以以不同標準和/或顆粒度來配置每個請求。

目前版本的 OpenResty Edge 只在例項級別做流量控制 (就是在所有 NGINX 的 worker 程序上)。未來版本將基於 CRDT 演算法支援叢集範圍乃至全域性範圍的流量控制。

# 響應過濾 & 改寫

與請求過濾和重寫類似，只是這些使用者規則可以應用於響應。

最終我們可以允許使用者在相當大的響應體上宣告 Perl 相容的正規表示式，進行流式替換，類似開源的 ngx_replace_filter NGINX 模組，但具備更大的靈活性和更強的動態性，並且快非常多。

OpenResty Edge 整合了 OpenResty Inc. 自己的專有正規表示式引擎，sregex2，它能保證以 O(n) 的時間複雜度 (這裡的 n 是資料流的長度) 和 O(1) 的空間複雜度 (只要正規表示式模式是固定的)。sregex2 引擎也可以用於其它請求過濾機制，比如上面提到的 WAF。

這裡我們也可以用 sregex2 提供預定義的過濾器，比如有條件或者無條件的 Gzip 壓縮、以及在動態內容上簡單的 CSS/HTML/JavaScript 最佳化 (執行時刪除額外的空白和註釋，並且是流式進行)。

在這個場景下，也可以開啟自動的資料採集和分析。

輸出資料速率限制也可以有條件地或無條件地應用於響應級別，並且還可以在單​​個響應中動態地改變，例如僅在單個響應中傳送 1MB 響應資料之後進行限制。

# 靜態資源

使用者可以提交靜態資源讓 Edge 提供服務。使用者可以選擇直接用 Edge 機器的記憶體進行資源服務 (最快)，或者是如果靜態資源太大了記憶體放不下，那麼就可以存在每個閘道器節點的本地磁碟系統裡。

同時還支援靜態資源的 gzip 壓縮。

# 反向代理 & 負載均衡

使用者可以為 Edge 上的反向代理或負載均衡器配置源站（或後端伺服器）。每個伺服器都有主機名，機器 ID，服務埠等。

預定義的負載均衡策略，比如權重輪轉，權重一致性雜湊，模除雜湊，最少連線，使用者可以從中選擇一個。

使用者可以透過 web 表單或者 Edge 指令碼定義自己的專用的負載均衡規則。

當檢測到指定數量的連續故障時，可以切換後端伺服器。還可以指定或自定義自動後端重試策略。 例如，當 500 發生時，根據某些規則自動重試另一個後端伺服器。

每個後端伺服器的連線、讀取、傳送超時設定都可以設定。可以是請求級別，並且可以是有條件的。

可以開啟後端伺服器的主動健康檢查。使用者可以配置自定義的 health-check (健康檢查) 和定義複雜的響應檢查請求。

負載均衡器和反向代理機制是整合在 Edge 語言裡的。它支援複雜的多層 CDN 類網路的分層緩衝和請求路由。

# 快取

我們可以允許配置 NGINX 的 HTTP 快取，它是基於檔案系統和檔案的。 各種常用的 NGINX proxy_cache 配置也在管理站 UI 中。

使用者可以選擇開啟 ngx_srcache 模組提供的子請求為基礎的快取，這樣響應可以由外部 Memcached 或者 Redis 服務快取起來。

最終 OpenResty Edge 會發售自己的基於 OpenResty 的 CDN 級別的快取軟體，它將既可以處理巨型資料流 (比如影片)，也可以處理小型資料碎片 (比如小型的 API 的 JSON 響應)。

使用者還可以透過管理站點提交軟實時快取清除請求。例如，使用者可以指定 URI 模式或其他自定義條件，以跨閘道器叢集清除那些匹配請求的快取版本。

可以配置跨閘道器叢集節點的分散式快取。 使用者還可以從一組預定義的雜湊策略中進行選擇，例如加權一致性雜湊，加權模數雜湊，加權迴圈和最小連線。此外，使用者可以使用簡單的 Web 表單或 Edge 語言指令碼指定自己的雜湊演算法或例外規則。

使用者可以宣告重要資源的或者熱點資源，讓系統主動地預抓取，用以預熱每個雲叢集的快取。

OpenResty Edge 產品也可以配置成與使用者自己的快取軟體一起工作，即使這些軟體與 NGINX 或者 OpenResty 毫無關係也可以。

# DNS

OpenResty Edge 不僅提供 HTTP/HTTPS 服務的支援，還有對 UDP 和 TCP 的 DNS 服務的支援。

OpenResty DNS 也執行在閘道器節點上，甚至可以跟其它 HTTP/HTTPS/TCP/UDP 型別的應用並存。他們甚至還分享同一個 OpenResty/NGINX 伺服器程序。

每個 DNS 服務都有自己的應用。DNS 服務應用可以被其它 HTTP/HTTPS/TCP/UDP 應用引用。 每個 HTTP/HTTPS/TCP/UDP 應用可以選擇在那些執行在 Edge 裡的指定的 DNS 服務上保留一個位置。 叢集通常使用的 DNS 服務通常是在 DNS 自己的應用裡獨立配置的，它和那些用於 HTTP/HTTPS 的雲叢集可能是不同的。

同樣的原則適用於裸的 TCP/UDP 型別應用。 使用者可以為與當前應用相關的域名定義各種 DNS 記錄。這些記錄可以是有條件的，比如基於原始的 DNS 請求和當前的時間戳定義的前提要求。也支援高階的 DNS 特性，比如 DNSSEC。

使用者可以選擇在 OpenResty DNS 伺服器中開啟基於 DPDK 或者 Snabb 的使用者空間的網路實現，這樣可以繞開作業系統的網路協議棧，通常可以獲得更好的效能，但是也要求自己實現所有的網路功能。

# TCP/UDP 伺服器

與 HTTP/HTTPS 伺服器類似，但只是代理或負載平衡任意 TCP 或 UDP 流量。因此，特定 HTTP/HTTPS 的概念（如請求 URI 和請求標頭）不適用於此上下文。

應用程式可以在其建立過程中選擇其型別為 TCP 或 UDP。

# 錯誤日誌

閘道器節點可以生成 NGINX 錯誤日誌。 這些錯誤日誌的收集方式與訪問日誌類似，應該（軟）實時向上收集到管理站點。

管理站點可以自動將錯誤日誌對映到相應的面板，甚至是對應到相應的使用者配置檔案的對應規則的對應版本上。

管理站點在任何有預期的錯誤資訊上自動生成標籤，這樣管理站就可以在稍後進行自動對映，而不用人工協助。

管理站點還提供了人性化的解釋，甚至是有關常見 NGINX 錯誤日誌訊息的建議。 一些建議甚至可以觸發 Trace 子系統提供的線上跟蹤分析（請參閱下面的 Trace 部分）。

使用者可以編寫自己的錯誤日誌分類器和計數器，管理站點將自動執行。

# 跟蹤 & 除錯

管理站點可以指示指定的閘道器節點（甚至管理站點節點）動態跟蹤其自己的服務程序，以進行線上效能分析和/或故障排除。 將使用基於 SystemTap，Linux eBPF 等動態跟蹤工具，因此可以安全地線上上具有真實生產流量的節點中使用。

可以用跟蹤命令生成 on CPU 火焰圖，用於分析特定閘道器節點中的高 CPU 使用率的問題。 類似地，可以生成一個 off CPU 的火焰圖，來分析被大量阻塞的 NGINX 工作程序。 例如，管理站點可以透過自動分析生成的火焰圖來提供可操作的建議。 而其他 Trace 工具可以提供有關整個軟體堆疊到 Linux 核心的更多執行時詳細資訊。

也可以透過管理站點對 OpenResty/NGINX 程序（甚至其他外來程序）的 core dump 檔案進行離線分析。 這對於自動分析線上崩潰或僅處理特定閘道器節點上仍在執行的 OpenResty/NGINX 工作程序的空間快照非常有用。 與線上分析一樣，此類離線分析利用 OpenResty Edge 附帶的高階工具（基於 GDB 或 LLDB）。

大多數線上和離線分析工具都會向使用者提供可操作的建議，以進行最佳化或修復錯誤。

使用者可以選擇將線上和離線分析報告提交給 OpenResty Inc. 的工程團隊進行進一步分析。

管理站點還提供 Y 語言（一種用於通用除錯和跟蹤的 DSL），以建立可在閘道器網路上即時啟用的自定義動態跟蹤工具。 Y 跟蹤程式可以編譯為 Systemtap 指令碼甚至 GDB Python 指令碼，用於線上分析（使用 Systemtap）和離線核心轉儲檔案分析（使用 GDB）。但只有超級使用者才能使用 Y 語言提供自己的跟蹤工具。

Edge 語言指令碼和 OpenResty Edge 的大多數核心模組都帶有一種特殊的除錯模式， 使用者可以使用該模式收集特定異常請求或請求的詳細除錯資訊。 顯而易見，除錯模式的確會拖慢線上處理速度，所以只是根據使用者需求來控制開關。

# API 過濾器

管理站允許使用者提供 JSON 模式以及 SchemaType 給 JSON/YAML/CSV 資料流宣告資料結構 (在請求體或者響應體裡，前者通常更有用)。這些資料格式通常用在 RESTful 的 API 或者其它 web 服務裡。

參考 www.schematype.org/docs/home/ 獲取更多關於 SchemaType 的資訊。

管理站點也可以允許使用者書寫 jq 語言程式碼在 HTTP/HTTPS 反向代理的過程中做 JSON 資料轉換。 jq 是一種 DSL，用於轉換結構化資料流，比如那些 JSON。參考下面的連結獲取更多 jq 語言細節： stedolan.GitHub.io/jq/manual

# Serverless 指令碼

允許使用者使用 Perl 6，JavaScript，Python 或 PHP 的子集或方言來編寫可以直接在 Edge 上執行的簡單 Web 應用程式。

Admin 站點提供了一個簡單的 Web IDE，可以用它處理那些通用目的的語言指令碼或者實現那些可以用於 Edge 語言指令碼的專用的函式。

這些通用語言子集或方言將被編譯為高度最佳化的 Lua 程式碼，就像 Edge 語言一樣。並且使用“編譯時沙箱”來確保這些指令碼不會執行太長時間，或者使用比配置限制的更多的記憶體。

這樣的通用指令碼肯定比 Edge 語言指令碼效率低得多。

注意：雖然我們已經有一個名為 fanlang 的 Perl 6 方言實現，OpenResty 公司已經大量使用它來構建 Edge 產品本身。

# Metrics & 資料分析

OpenResty Edge 產品中的每個 Edge 語言規則和預定義功能都可以具有軟實時 metrics。 許多預定義的產品功能都帶有可在管理站點上切換的內建指標。使用者可以透過標記 Edge 語言規則，或指定的 Edge 語言規則條件，來定義自己的 metrics，或者編寫專用的 Edge 語言規則來建立自定義 metrics。

使用與訪問和錯誤日誌資料相同的資料管道收集 metrics 資料，並將其作為彙總結果（如總和，計數，平均值等）反饋給管理站點。 這些 metrics 結果可用於提供和驅動 Edge 語言規則在管理站點中執行，以超級使用者指示的某些方式自動控制閘道器網路，例如使用閘道器的實時指標，自動在相應的閘道器節點或閘道器群集中修改路由和負載平衡策略。

OpenResty Edge 提供了一個成熟的資料分析平臺，可以對歷史和實時訪問日誌資料進行常見的，自定義的複雜分析和聚合，具有複雜的資料包告和資料視覺化方法以及訪問所有內容的 Web 介面。

類似於 SQL 的域特定語言（名為 ORSQL）可用於建立將以分散式方式執行的自定義資料查詢。注意：這個還未實現。

所有這些仍然執行在 OpenResty 的技術棧上。

但是，使用者可以選擇將線上日誌資料流提供給其他第三方資料分析或日誌處理系統。