微服务架构下Stripe Webhook无法路由至对应API网关的处理方案

完全不需要搭中心化业务处理节点，以下两个方案都适配纯分布式拓扑，没有单点风险：

方案1：元数据透传+无状态四层转发（改造成本最低） #

• 用户发起/checkout请求落到对应API网关时，网关调用Stripe创建PaymentIntent/Checkout Session的环节，直接在Stripe的metadata字段里写入当前网关的唯一标识，比如origin_gw_id: api-gw-cn-east-2-07，这个字段Stripe会在后续所有关联的Webhook事件中原样返回，不会篡改或丢失。
• 所有API网关统一保留同路径的Webhook接收接口https://{apiid}.globalurl.com/stripe/webhook，前端只需要加一层无状态四层负载均衡（仅做网络转发，不存储业务数据、不处理业务逻辑，不属于中心化业务节点）承接Stripe的所有Webhook推送，这层只做两个操作：
  • 第一时间校验Stripe Webhook签名，过滤伪造请求
  • 解析合法请求payload里的origin_gw_id字段，把原始请求原封不动转发到对应ID的API网关，转发完成立刻释放连接，不做任何持久化
• 整个流程里业务处理逻辑全在原有分布式API网关上完成，转发层无状态可以任意扩缩容，不存在单点故障风险，改造成本极低，适合大多数集群规模场景。

方案2：网关自注册专属Webhook端点（零转发层，纯分布式） #

• 每个API网关实例启动时，自动生成自己独有的Webhook接收路径，格式为https://{apiid}.globalurl.com/stripe/webhook/{instance_random_token}，同时调用Stripe开放接口注册这个专属端点，配置好需要接收的事件类型，把自身网关ID和端点做绑定。
• 当用户请求落到某台API网关发起结账流程时，网关在创建Stripe支付对象的参数里，直接指定关联自己注册的专属Webhook端点，后续这笔订单产生的所有Webhook事件，Stripe会直接推送到对应的网关地址，完全不需要中间转发节点。
• 配套做个简单的生命周期钩子就行：网关实例正常下线前，自动调用Stripe接口删除自己注册的专属Webhook端点，避免产生无效推送；Stripe单账号默认支持的Webhook端点配额足够支撑百级规模的网关集群，超大规模可以直接找Stripe提额，没有硬限制。

避坑提醒：不管用哪个方案，Webhook请求到达最终处理的API网关后，必须重新做一次Stripe签名校验，不能因为前置层做过校验就跳过这个步骤，避免转发链路被篡改引发安全问题。不要在转发层写任何业务逻辑，否则本质上还是退化成了中心化节点，违背分布式架构的初衷。

内容的提问来源于stack exchange，提问作者JeanJacquesGourdin