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 的技术栈上。

但是，用户可以选择将在线日志数据流提供给其他第三方数据分析或日志处理系统。