DutchBud：从 Laravel API 到 Go、OTAP CI 和 ACC 回归网关

发布日期：2026年7月 · 3DN基础设施笔记

DutchBud 是我们的个人银行伴侣——一个与 bank.dutchie.org 通过 JSON API 交互的 Android 应用。从“在我的笔记本电脑上运行”到“在 02:00 通过 WireGuard 在我的手机上运行”，这一过程涉及 DNS、OTAP 部署流水线、有意的 Laravel 转 Go API 分割，以及一个回归测试工具，该工具将每个 Acceptatie 版本与生产数据进行比较。这篇文章就是这次演出的记录。

连接到本地银行基础设施的智能手机上的 DutchBud 应用 — 手机上的 DutchBud；背后的 API 和 OTAP 栈在我们控制的金属上。

端到端设置 DutchBud

该栈故意设计得乏味——这是一个赞美：

Android 客户端——使用令牌认证的 Kotlin 应用，针对 /api/* 端点。
Laravel Web 应用——仍然为浏览器 UI、迁移和 OTAP 部署脚本提供服务，每个环境都有一个专门的 Web 根目录。
Go bank-api——生产环境 JSON API 在配对的应用服务器上作为 systemd 服务运行；Nginx 通过 HAProxy 将 /api/ 路由到 Go，而 Laravel 保留其他所有内容。
边缘访问——WireGuard 客户端通过我们的权威 DNS 解析内部名称；bank.dutchie.org 在私有网络上到达泰国 DMZ 前端。

早期的手机测试揭示了一个经典的运营陷阱：网关上的一个恶意 BIND 实例在 DNS 响应中表现出错误的 AAAA 行为，因此 WireGuard 解析看起来很好，直到它不是。将客户端指向正确的权威解析器，停止流浪服务，修复端口转发恢复了可预测的解析。登录 422 证明是可达性问题，而不是凭证问题——一旦 DNS 和路由变得诚实，应用就恢复了。

深夜开发桌，有 Android 手机和终端 — 移动银行业务的无魅力部分：DNS、令牌，以及足够多的咖啡来阅读 API 服务日志。

为什么我们将 API 从 Laravel 转到 Go

Laravel 在产品速度方面表现优异。当每个 API 调用在 Android 应用多次访问的路径上支付完整的 PHP 框架引导税时，它就不那么出色了。我们在此之前在相同的主机上进行了测量：

仅 Laravel 框架引导：~100 ms 在您的控制器运行之前。
Go GET /api/bank-accounts: ~12 ms 在本地服务器上。
Go GET /api/payments?page=1: ~150 ms (数据库绑定，不是框架绑定)。
Go POST /api/login: ~280 ms — bcrypt 仍然占主导地位；胜利在其他地方。

决策标准是实际的，不是意识形态的：

热门 JSON 路径的延迟 — 账户和列表端点在移动设备上必须感觉即时。
内存占用 — 每个节点的小型 Go 二进制文件优于 PHP-FPM 池，适合读密集型 API。
操作简便性 — 一个静态二进制文件，结构化日志记录，API 主机上的配置。
保持 Laravel 的优势 — Blade UI、Eloquent 迁移、现有 OTAP 策略不变。

证明分割的测量比较：Go 在 /api/，Laravel 在网络表面。

OTAP CI — 从开发推送到生产门

银行应用程序是我们的 OTAP 试点。专用运行器上的 GitLab CI 部署分支：

dev → Ontwikkel，然后快速前进 tst → 测试。
提交必须携带 Refs #N；管道在链接的问题上发布 “准备测试”。
acc → 在测试上客户批准后手动部署 Acceptatie。
master → 手动 Productie。

部署是在应用程序主机上进行的加固 SSH git checkout：获取，硬重置到管道 SHA，修复权限，运行环境设置（如果存在）。没有 rsync 神秘之处 — 每个阶段都只有 git 的真相。

包括我们在 acc 分支添加的 ACC 回归阶段的 OTAP 流。

回归测试在真实生产形状上

Acceptatie 不是玩具数据库。手动 deploy:acceptatie 后，CI 运行：

sync:prod-db-to-acc — 将生产数据复制到验收数据库，并同步收据存储。
migrate:acc — 在 ACC 上应用 Laravel 迁移。
regression:check — 猛击实时 ACC API，并与提交的基线进行比较。

该测试用例位于 bank-api 仓库中。四个场景——登录、银行账户、预算帖子、支付页面 1——每个场景都运行了20个连续迭代(~总共6秒)。对于每个场景，我们记录 HTTP 状态、JSON 负载的形状哈希（结构和键，而不是易失值）和 p95 延迟。生产同步后的初始基线：登录 p95 598 ms，银行账户 116 ms，预算帖子 184 ms，支付 178 ms，对比 58 个支付和 3 个账户。

如果形状发生变化或 p95 超过基线 × 容差（默认 1.25×，登录 1.5×），检查任务将失败。在故意更改 API 后需要一个新的基线？运行手动 regression:capture，并在 bank-api 仓库中提交更新的基线。结果将出现在 GitLab 任务日志中——无需外部 SaaS。

生产型 ACC 数据 → 编剧化 API 探针 → 提交基线门槛。

我们学到了什么

移动应用会惩罚小的基础设施错误。几乎起作用的 DNS 比明显失败的 DNS 更糟糕。当边界是 nginx 并且合同是 JSON 时，分割 API 运行时是可以的。OTAP 只有在测试和接受阶段在机械上不同时才能赢得信任——手动推广加上在生产型数据上自动回归就是这种不同。

DutchBud 是个人软件，运行在专业轨道上。下次你看到一个绿色账户屏幕在 WireGuard 上在一秒钟内加载，那就是 Go、PowerDNS、GitLab CI 和一个基线文件说“仍然与昨天相同形状”。

对我们的基础设施或托管方法有疑问？联系我们。