点击支付后的毫秒内发生了什么

在收银台前，你轻触卡片，一个微小的旋转图标出现不到半秒，然后显示“批准”或“拒绝”。在这短短的时间内，系统必须决定这笔交易是否看起来像你本人所为，还是像六个月前数据泄露中窃取你卡号的人。它需要了解你的消费模式、每日限额，甚至你是否允许跨国交易，并且必须在你不察觉的瞬间完成这一切。这正是 Databricks 博客文章所探讨的内容：当你基于 Databricks 构建这样的系统时，它是什么样的。

文章介绍了一个名为 retail-app 的示例应用（基于 FastAPI 后端和 React 前端，部署为 Databricks App），该应用将两个平台能力结合在一起：具有路由优化的 Model Serving，以及 Lakebase（一个托管 Postgres 服务，用于存储模型预测所需的档案和特征数据）。完整的代码库可在 GitHub 上获取，你可以将其部署到自己的工作空间并亲自体验。

交易流程：模型首先对交易进行评分，然后应用检查用户档案规则。模型运行在前是因为无论结果如何都需要其延迟数据。随后，档案查找（每日消费上限、国际交易开关、居住国家）通过一系列 if 语句进行判断。响应中包含了每一步的时间，让你清楚看到毫秒都花在了哪里。更新档案（如改变每日限额、切换国际交易）是独立操作，更改保存到数据库后，下一次支付就会生效，无需重新部署或缓存失效。

路由优化是关键。当模型部署在 Databricks Model Serving 后端时，应用与推理容器之间存在网络跳转。对于批处理负载，几毫秒的延迟无关紧要，但对于结账体验则至关重要。路由优化缩短了网络路径，启用后，模型推理请求的通信更直接、更快速，从而提高每秒查询数（QPS）并降低延迟。在示例应用中，端点名为 fraud-detection-lakebase，通过数据平面路径使用 OAuth 进行查询，而非个人访问令牌。

Lakebase 作为模型所需数据的 Postgres 存储。欺诈模型不仅看交易本身，还通过信用卡前六位（BIN）查询客户历史特征（如平均交易金额、跨境比例、拒付率、过去 24 小时交易速度）。这些特征存储在名为 customer_features 的 Lakebase Postgres 表中。后端也读取同一表获取档案数据。读取时，后端从连接池借用一个连接，执行参数化 SELECT 查询，并在 finally 块中归还连接。写入时，用户通过 UI 更改每日限额或切换国际交易，后端根据允许编辑的列白名单构建动态 UPDATE 语句，只有白名单上的字段可写入，且立即生效。

连接池和 OAuth 令牌轮换确保延迟稳定。每次交易至少访问 Lakebase 两次（模型特征查找和后端档案检查），如果每次都新建连接，会增加 20-50 毫秒开销。连接池保持少量连接就绪，多数请求可即取即用。由于 Lakebase 通过 OAuth 认证，应用使用服务主体凭据交换访问令牌，并将客户端 ID 作为 Postgres 用户名、令牌作为密码。令牌过期时，需重建连接池。示例代码通过双重检查锁定确保并发安全，并设置 30 秒定时器关闭旧池，让正在进行的查询完成。

模型容器内部也维护自己的 Lakebase 连接池，并在后台刷新令牌。模型返回 fraud_probability、fraud_flag 以及内部计时（lookup_ms、inference_ms、total_ms），后端将这些映射到前端显示延迟瀑布图。业务规则在模型评分后执行：比较交易金额与每日上限，以及检查用户是否启用国际交易。任一规则可覆盖模型的批准，这意味着模型处理统计风险，而档案处理用户偏好。

Lakebase 支持自动扩缩容和缩容至零。在生产环境中，Postgres 实例需要同时处理模型容器的特征查找和后端的档案读取。基准测试显示，稳定负载下单次查找时间在 p50 到 p75 为个位数毫秒，p95 的 13.9 毫秒跳变属于正常波动，自动扩缩容可在其变得用户可见前吸收。启用缩容至零后，无交易时即停止计费。

总体延迟分解如下：model_call_ms 为整个服务调用的墙钟时间，model_lookup_ms 和 model_inference_ms 为模型容器内部分解，business_logic_ms 为档案读取和规则评估。前后端测量的总延迟差异即网络开销和框架开销。在 UI 中，用户可看到模型推理、特征查找和业务逻辑的延迟，直观了解路由优化的效果。

总之，这个示例应用展示了如何通过路由优化、Lakebase 自动扩缩容、连接池和 OAuth 令牌轮换，在毫秒内完成实时欺诈检测，同时保持高可用性和低成本。