/tags/idempotency/ Recent content in idempotency on Hugo -- gohugo.io en Thu, 09 Apr 2026 10:00:00 +0800 /posts/stripe-payment-integration/ Thu, 09 Apr 2026 10:00:00 +0800 /posts/stripe-payment-integration/ 📦 本文基于的完整项目源码：https://github.com/meirongdev/shop 电商系统接入支付时，第一步通常不是“把所有 webhook 和退款补偿一次做完”，而是先把支付入口、provider 边界和返回模型抽清楚。Shop Platform 当前已经完成的是这条基线：buyer-bff 统一调用 wallet-service，wallet-service 再按支付方式路由到 Stripe / PayPal / Klarna / 内部 Wallet。 更准确地说，当前仓库已经具备： 统一的 WalletApi.PAYMENT_INTENT / PAYMENT_METHODS 合约 PaymentProviderService 里的 provider routing Stripe 真/假网关切换（StripePaymentGateway / MockPaymentGateway） buyer-bff 对 clientSecret / redirectUrl 的透传 但还没有把 Stripe webhook、Stripe Refund API、事件幂等表、Payment Element 前端确认链路真正提交进来。所以这篇文章也应该按“已落地基线 + 明确演进方向”来写，而不是把未来设计写成现状。 当前支付架构 flowchart TD Client["客户端 / SSR Portal"] BFF["buyer-bff"] Wallet["wallet-service"] Provider["PaymentProviderService"] Stripe["StripeGateway"] Paypal["PayPal Orders API"] Klarna["Klarna Sessions API"] Internal["WalletApplicationService"] Client -->|"checkout / payment intent" /posts/shop-platform-event-driven/ Sat, 04 Apr 2026 10:00:00 +0800 /posts/shop-platform-event-driven/ 在之前的文章中，我们看了同步请求链路上的 Gateway → BFF → 领域服务。但微服务架构中并不是所有交互都适合同步发生。事件驱动架构让服务之间通过异步消息协作，在不少场景下用最终一致性换取更低耦合和更好的链路弹性。 📦 本文基于的完整项目源码：https://github.com/meirongdev/shop 上一篇：（四）领域服务设计 2026-04 实践更新 当前主线仓库已经把 IdempotencyGuard + Redis Bloom Filter、补偿任务重试、以及关键 Kafka consumer 的幂等保护补齐到 Phase 1 基线；本文整体设计仍然准确，但“待补齐”的幂等链路请以当前 main 分支实现为准。 为什么用事件驱动 在 Shop Platform 中，异步事件主要用来承接那些不必阻塞用户请求、但又需要可靠传播的业务事实。例如： flowchart TD Order["用户下单order-service"] Stock["扣库存marketplace-service"] Points["发积分loyalty-service"] Email["发邮件通知notification-service"] Webhook["推送外部订阅webhook-service"] Order -->|"同步 需要立即确认"| Stock Order -.->|"异步 可以延迟"| Points Order -.->|"异步"| Email Order -.->|"异步"| Webhook 如果全部走同步 HTTP 调用： 下单接口响应时间 = 最慢下游服务的响应时间 任意下游服务不可用 → 下单失败 服务间耦合紧，新增消费者需要修改生产者 事件驱动的方式： flowchart LR OS["order-service写入订单 + outbox同一事务"] Pub["Outbox Publisher"] Kafka["Kafkaorder.events.v1"] L["