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）是性能躍遷的關鍵。
• 灰度驗證 + 熔斷限流是零停機的護城河。
• 監控可觀測性是快速排障的生死線。