ghcr.io/openfaas/of-watchdog:5d4cadcaf595f3d3d213e08cdd38a310c5bb3066

of-watchdog

用于使用 STDIO/HTTP 的函数的反向代理/中间件

of-watchdog 实现了一个监听端口 8080 的 HTTP 服务器，并作为运行中函数和微服务的反向代理。它可以独立使用，也可以作为 OpenFaaS 容器的入口点。

of-watchdog 此版本的 OpenFaaS 看门狗增加了对 HTTP 代理和 STDIO 的支持，这实现了内存重用和极快的请求服务。它不旨在替代 Classic Watchdog，而是为需要这些功能的用户提供另一种选择。

可通过 GitHub releases 下载，但该看门狗旨在通过多阶段构建从发布到 ghcr.io 的容器镜像中复制：

FROM --platform=${TARGETPLATFORM:-linux/amd64} ghcr.io/openfaas/of-watchdog:0.9.11 as watchdog
FROM --platform=${TARGETPLATFORM:-linux/amd64} node:18-alpine as ship

COPY --from=watchdog /fwatchdog /usr/bin/fwatchdog

参见示例模板

目标

• 通过使用 HTTP 保持函数进程活跃，以实现更低延迟、缓存和持久连接
• 支持从函数流式传输大型响应，超出容器的 RAM 或磁盘容量
• 为每种“模式”提供更清晰的抽象

模式

of-watchdog 提供多种模式，这些模式会改变它与微服务或函数代码的交互方式。

三种看门狗模式的比较。左上角 - Classic Watchdog，右上角：afterburn（已弃用），左下角 - of-watchdog 的 HTTP 模式。

三种看门狗模式的比较。左上角 - Classic Watchdog，右上角：afterburn（已弃用），左下角 - of-watchdog 的 HTTP 模式。

• HTTP 模式 - 默认且最高效的选项，如果目标语言有 HTTP 服务器实现，所有模板作者都应考虑此选项。
• 序列化模式 - 当不存在 HTTP 服务器实现时，STDIO 被读入内存，然后发送到一个 fork 的进程中。
• 流式模式 - 与序列化模式类似，但请求和响应均采用流式传输，而非在函数开始运行前完全缓冲到内存中。

API

由看门狗提供的私有端点：

• /_/health - 当进程启动时返回 true，或者如果使用了锁文件，则当该文件存在时返回 true。 /_/health
• //ready - 与 //health 类似，但如果 max_inflight 配置为非零值，且达到最大连接数，则返回 429 状态 /_/ready``/_/health``max_inflight

其他所有 HTTP 请求：

• /* 任何其他路径和 HTTP 谓词都发送到函数 /*

1. HTTP (mode=http)

1.1 状态

对于目标语言有可用 HTTP 服务器实现的所有模板，推荐使用 HTTP 模式。

参见一些不同的模板示例，更多模板可通过 faas-cli template store list 获取，例如 golang-middleware、python3-http 和 node*。

faas-cli template store list``golang-middleware``python3-http``node*

要获取特定模板的仓库，请使用 faas-cli template store describe NAME。

faas-cli template store describe NAME

1.2 描述

看门狗启动时会 fork 一个进程，然后将传入看门狗的所有请求转发到容器内的 HTTP 端口。

优点：

• 高并发和高吞吐量的最快选项
• 与 fork 模型相比，并发和 RAM 使用更高效
• 数据库连接可在容器生命周期内保持持久
• 文件或模型可作为一次性初始化任务获取并存储在 /tmp/ 中，供之后的所有请求使用 /tmp/
• 不需要像 afterburn 那样的新/自定义客户端库，而是使用长期运行的守护进程，如 Node 的 Express.js 或 Python 的 Flask

测试示例用法：

• 转发到 Nginx 容器：

$ go build && mode=http port=8081 fprocess="docker run -p 80:80 --name nginx -t nginx" upstream_url=http://127.0.0.1:80 ./of-watchdog

• 转发到 Node.js / Express.js hello-world 应用：

$ go build && mode=http port=8081 fprocess="node expressjs-hello-world.js" upstream_url=http://127.0.0.1:3000 ./of-watchdog

缺点：

• 客户端和函数之间的链中多了一次 HTTP 跳转
• 像 express/flask/sinatra 这样的守护进程以这种方式使用时可能不可预测，因此可能需要额外配置
• 与 fork 模型相比，调用之间可能会占用额外内存

1.3 结构化日志

目前无法将看门狗自身的消息以 JSON 格式输出：

2024/04/25 17:29:06 Listening on port: 8080
2024/04/25 17:29:06 Writing lock-file to: /tmp/.lock
2024/04/25 17:29:06 Metrics listening on port: 8081
2024/04/25 17:29:08 GET / - 301 Moved Permanently - ContentLength: 39B (0.0049s) [test]

不过，您可以用 JSON 编写自己的日志行。只需将 prefix_logs 环境变量设置为 false，即可移除看门狗原本会添加的默认前缀。

prefix_logs``false

启用 prefix_logs 时：

prefix_logs

2024-04-24T21:00:04Z {"msg": "unable to connect to database"}

禁用 prefix_logs 时：

prefix_logs

{"msg": "unable to connect to database"}

1.4 追踪/关联 ID

网关会发送 X-Call-Id 头，您应在自己的日志记录器中使用该头来关联和追踪请求。

X-Call-Id

在 HTTP 模式下，如果将 log_callid 环境变量设置为 true，看门狗会将 X-Call-Id 附加到其自己的 HTTP 日志消息的方括号中：

log_callid

2024/04/25 17:29:58 GET / - 301 Moved Permanently - ContentLength: 39B (0.0037s) [079d9ff9-d7b7-4e37-b195-5ad520e6f797]

1.5 缩短超时时间

如果函数通过 exec_timeout 设置了较大的超时时间（如 1h），但您需要单个请求提前超时（例如 1m），则可以通过 HTTP 头 X-Timeout 传递 Go 持续时间来覆盖此行为。

exec_timeout``1h``1m``X-Timeout

X-Timeout 的值必须等于或短于 exec_timeout 环境变量。

X-Timeout``exec_timeout

当 exec_timeout 设置为 0 或未指定时，无法设置 X-Timeout。

X-Timeout``exec_timeout

由于输入/输出直接连接到响应以实现流式传输效率，函数开始执行后无法发送HTTP headers。除非进程分叉出现问题，否则响应码始终为200。中途错误必须由客户端捕获。多线程。

3. 流式派生（mode=streaming）- 默认模式

每个请求派生一个进程，能够处理大于内存容量的请求体——例如，512MB内存的虚拟机可以处理多个GB的视频。

由于输入/输出直接连接到响应以实现流式传输效率，函数开始执行后无法发送HTTP头。响应代码始终为200，除非派生进程时出现问题。中途错误必须由客户端检测。多线程。

• 执行进程将输出打印到stdout后，输入会立即发送回客户端。
• 可以预先设置静态Content-type。
• 执行超时：支持。

4. 静态模式（mode=static）

此模式启动一个HTTP文件服务器，用于提供static_path指定目录中的静态内容。

请参见Hugo博客文章中的示例。