PayFi 聚合网关 API 异步化：5 天高并发改造实战

引言

随着链上支付场景的井喷式增长，PayFi（Payment Finance）平台每天需要处理数百万笔跨链交易。我们团队在 2025 年 8 月接到一个硬指标：把聚合网关的单日峰值并发从 3k TPS 提升到 15k TPS，且只允许 5 天改造窗口。本文将完整复盘这次“5 天冲刺”——从瓶颈定位、技术选型、代码落地到灰度验证，全程干货、可落地、可复现。

1. 背景与业务挑战

挑战：

• 旧系统基于 Spring Cloud Gateway + JDBC 同步阻塞，连接池极易被占满。
• 下游 30+ 渠道方接口延迟不均，同步模型造成级联阻塞。
• 运维要求零停机发布，且必须可回滚。

2. 现状：一次压测暴露的 4 个瓶颈

数据来源：2025-08-19 内部压测报告《PayFi-Gateway-LoadTest-v3.1》。

3. 技术选型：为什么选 Vert.x

核心原因：

• Vert.x 提供 EventBus、SharedData，天然适合聚合网关的多协议转发。
• 支持 Kotlin 协程 与 RxJava，团队已有 Kotlin 技术栈沉淀。
• 官方基准 Vert.x Benchmark 显示 50k TPS 场景下 CPU 仅为 60%。

4. 5 天冲刺排期（甘特图）

5. 核心改造 3 步曲

5.1 网络层：Spring Cloud Gateway ➜ Vert.x Gateway

关键代码片段（Kotlin）：

val router = Router.router(vertx)
router.route("/pay/:channel").handler(BodyHandler.create())
router.route("/pay/:channel").handler { ctx ->
    eventBus.request<JsonObject>("channel.${ctx.pathParam("channel")}", ctx.bodyAsJson)
        .onSuccess { ctx.end(it.body().encode()) }
        .onFailure { ctx.fail(502, it) }
}

5.2 数据层：JDBC 同步 ➜ Reactive PostgreSQL Client

• 引入 Vert.x PostgreSQL Client（官方文档）。
• 连接池参数：
  • maxSize = 50
  • idleTimeout = 30 s
• 通过 RowStream 流式读取，内存占用从 300 MB 降至 40 MB。

5.3 容错层：引入 Resilience4j 反应式熔断

代码片段：

val cb = CircuitBreaker.of("channelX", CircuitBreakerConfig.custom()
    .failureRateThreshold(50)
    .waitDurationInOpenState(Duration.ofSeconds(10))
    .build())

6. 全链路灰度验证

灰度工具：

• Argo Rollouts 做 Kubernetes 灰度。
• Prometheus + Grafana 实时看板。

7. 性能数据对比表

数据来源：2025-08-24 生产压测报告《PayFi-Prod-LoadTest-v4.0》。

8. 踩坑与回滚记录

🏁 总结

通过 5 天极限改造，我们把 PayFi 聚合网关的并发能力提升了 5 倍，延迟下降近 80%，并保持零事故回滚。这次实战证明：

• 选对异步框架（Vert.x）是性能跃迁的关键。
• 灰度验证 + 熔断限流是零停机的护城河。
• 监控可观测性是快速排障的生死线。