初级运维现代 BFF 架构评估指南¶
English · GitHub source English version: README.md
本指南帮助运维评估一条常见 Web 请求链，不假定任何特定生产环境的事实：
浏览器 -> 边缘网关 -> Node.js BFF -> OpenResty/Lua 或下游服务
这个模式没有过时。BFF 仍适合处理面向浏览器的授权、请求适配与聚合；Nginx/OpenResty 仍适合在边缘处理 TLS、路由、限流和边界清晰的 Lua 扩展。真正可能落后的是运维方式：人工管理主机、可变发布包、进程内状态、长期共享凭据，以及事故发生时没有可用证据。
先收集证据，不先迁移¶
不要从一台主机或一份进程列表推断完整拓扑。选择平台前，先由服务 owner 确认下表。未知项只是待发现项，不是“该能力不存在”的证据。
| 范围 | 需要收集的证据 | 为什么影响决策 |
|---|---|---|
| 请求路径 | DNS/LB/网关 owner、路由、超时、认证边界 | 避免迁错层或绕过既有控制。 |
| 运行时 | Node 版本、PM2/systemd 配置、Worker 数、退出行为、资源使用 | 判断 BFF 是否真正无状态、能否安全重启。 |
| 交付 | 制品来源、lockfile、镜像/签名策略、回滚时间和成功记录 | 判断是否应先解决发布风险，而非先换托管平台。 |
| 可靠性 | 流量、延迟、错误、依赖失败、RTO/RPO、事故历史 | 判断扩缩容和高可用需求是否足以支持平台改造。 |
| 安全 | 身份、密钥交付、网络策略、审计记录、依赖 owner | 优先发现长期凭据和无人负责的暴露面。 |
应在一个有代表性的周期内收集度量，并覆盖一次正常发布。公开文档绝不能包含真实主机名、端口、令牌、客户数据或内部路由。
哪些应保留，哪些应改进¶
| 组件或实践 | 评估 | 现代化方向 |
|---|---|---|
| Node.js BFF | 面向浏览器的职责边界清晰时仍然有效。 | Worker 无状态化；定义 owner、超时、错误映射与 API 兼容策略。 |
| VM 上的 PM2 cluster | 服务少且稳定、流量可预测、主机 owner 清晰时仍可使用。 | 仅在具备非 root 运行、不可变发布、优雅退出、自动回滚和容量实测时保留。 |
| OpenResty/Lua | 适合网关策略和靠近边缘的请求处理。 | Lua 模块保持小、可测试、可观测、可版本化；不应无限扩张为应用服务的替代品。 |
| 人工 SSH 发布 | 运维能力薄弱，不是平台。 | 在 CI 构建一次；提升同一不可变制品；记录并演练回滚。 |
| 文件中的静态凭据 | 高风险技术债。 | 优先采用平台或工作负载身份与短期凭据；密钥应独立于源码和镜像。 |
| 无关联日志 | 不足以排查多跳调用。 | 使用一个请求关联 ID 输出结构化日志、指标与追踪。 |
PM2 cluster 可以作为合理的过渡方案，但优雅 reload 依赖应用正确处理终止信号。它不能替代高可用设计或发布控制面。参阅 PM2 cluster 官方文档。
选择满足证据的最小平台¶
| 选项 | 适合条件 | 不应仅因为 |
|---|---|---|
| VM + systemd/PM2 | 服务少且稳定、流量可预测、主机 owner 明确，并已能自动发布和回滚。 | 容器或 Kubernetes 流行。 |
| 托管容器平台 | BFF 无状态，需要可重复镜像和简单弹性，团队不需要自行运维 Kubernetes 基础能力。 | 误以为它自动提供 SLO、API 安全或下游韧性。 |
| Kubernetes | 多服务/多团队/多环境需要统一工作负载策略、路由和扩缩容，且有明确的平台 owner。 | 服务很少，或无人能处理集群升级、网络与事故。 |
对于 Kubernetes，Gateway API 为基础设施、网关和路由 owner 提供角色化模型。当这些角色与控制真实存在时，它是合适目标；单个 BFF 并不因此必须采用它。参阅 Kubernetes Gateway API 官方文档。
现代且可渐进落地的参考架构¶
这是目标模型，不是对任何现网的断言。
Internet
-> CDN/WAF 与托管负载均衡
-> 网关策略（Gateway API 或同类托管能力）
-> 无状态 Node.js BFF 副本
-> OpenResty/Lua 网关功能与已批准下游服务
-> 托管数据与身份服务
每一跳 -> 可关联日志、指标、追踪、发布元数据
CI -> 已测试不可变制品 -> 渐进发布 -> 受监控回滚
- BFF 保持面向浏览器的职责：认证并适配客户端请求；不要让它演变成无边界的业务逻辑收容器。
- 先只容器化可独立发布、无状态的 BFF。带状态服务必须另行设计数据、备份与恢复。
- OpenResty 的网关功能已被证明有价值时可保留。仅在测试、owner、发布安全或扩展性的证据要求时，再迁移或重写 Lua。
- 用 readiness 决定副本何时可接收流量；初始化慢时使用 startup probe；liveness 只用于“重启能修复”的故障。错误的 liveness probe 会制造重启循环。参阅 Kubernetes probes。
- 每个工作负载应有身份，并经批准平台取得短期凭据。SPIFFE 是一种可互操作的工作负载身份标准；是否采用必须适配组织现有身份系统。参阅 SPIFFE 概览。
- BFF 使用兼容 OpenTelemetry 的追踪和指标；JavaScript 的 traces 与 metrics 是稳定信号，但 logs 支持状态应以项目最新资料复核。参阅 OpenTelemetry JavaScript。
迁移前必须具备的最小运行契约¶
以下契约应先在当前平台落地。它既能让未来迁移更安全，也能立即改善 VM 部署。
| 契约 | 最低行为 |
|---|---|
| 健康检查 | 分离 liveness 和 readiness。实例终止前，readiness 应先变为不健康，停止接收新流量。 |
| 退出 | 收到 SIGTERM/SIGINT 后停止接收新请求，在限定时间内完成在途工作、关闭已批准客户端；超过期限则非零退出。 |
| 状态 | Session、上传、任务和权威业务状态不得只保存在某个 Worker 内存。 |
| 下游依赖 | 明确连接/读取/写入超时；只对安全、有界、幂等的操作重试；依赖失败必须可见。 |
| 可观测性 | 关联 ID 跨越网关、BFF 和下游调用；日志结构化并脱敏；可查询 RED 指标与发布版本。 |
| 交付 | 单一不可变制品、依赖校验、部署前验证、渐进暴露、明确回滚负责人和已演练的回滚路径。 |
将来迁移的决策门槛¶
在服务 owner 能回答前述问题且以下门槛全部通过前，不应启动平台迁移：
- 已批准有代表性的请求路径和依赖关系图。
- BFF 可在受控重启中通过验证，不造成用户可见的数据丢失或不安全的重复副作用。
- 一次发布能从源码版本追溯到制品和运行版本，并能在约定恢复目标内回滚。
- 已有错误率、延迟、资源使用和依赖行为基线；在金丝雀发布前已写明新平台的成功阈值。
- 目标平台的网络、身份、密钥轮换、日志保留、on-call owner 与事故升级路径均已批准。
如果门槛未通过，应先改善当前平台。这同样是现代化成果，而不是“没有上 Kubernetes”。