金融机构越来越多地采用为云构建的连接模型，以实现与支付网络和金融市场基础设施 (FMI) 的弹性支付连接。但是，当持续付款会话在非高峰期静默中断，或者后端部署断开数千个活跃的授权渠道时，会发生什么？这些是标准连接模式无法解决的运营现实。
我们已经看到，支付平台团队只是在生产事件发生后才发现这些差距：隔夜闲置超时后市场开盘出现重新连接风暴，或者滚动部署触发了整个信用卡网络渠道的重复授权。这篇文章中的模式直接解决了这些场景。在最近的一篇文章《金融市场基础设施的 AWS 云连接模式》中，我们介绍了从客户管理的基础设施到完全云架构的四种连接模式。模式 3（AWS PrivateLink）和 4（VPC 资源网关）使客户无需管理混合网络结构，例如 AWS Transit Gateway、AWS Direct Connect Gateway 或物理路由器。
支付连接跨越了一系列协议模型。现代支付平台，尤其是那些基于 ISO 20022 或 RESTful API 构建的平台，使用具有内置重试和指数等性的短暂请求/响应连接，而标准的 AWS PrivateLink 和资源网关配置可以很好地为这些工作负载提供服务。但是，承载大部分全球实时授权量的信用卡网络和国家借记账凭证在持续会话协议（例如 ISO 8583）上运行。单个传输控制协议 (TCP) 连接保持打开状态数小时或数天，传送连续的交易消息。
这些长时间的会话引入了不同的操作注意事项：非高峰时段的连接生命周期管理、后端维护期间的会话连续性、多租户部署中的租户级流量隔离以及对 FMI 发起的数据流进行主动运行状况监控。
在这篇文章中，我们介绍了四种生产强化模式 (A-D)，它们为运行基于持续会话的协议的支付工作负载扩展了模式 3 和 4。这些模式优化了基础设施层的连接可靠性、维护工作流程、租户隔离和可观察性，使通过 AWS PrivateLink 和 Resource Gateway 连接到传统支付轨道的组织受益。
先决条件
在继续之前，我们假设熟悉金融市场基础设施的 AWS 云连接模式一文中描述的连接模式，以及包括亚马逊 VPC、AWS PrivateLink、网络负载均衡器、亚马逊 EC2 自动扩展和亚马逊 VPC Lattice 在内的 AWS 网络服务。
解决方案概述
四种强化模式层位于基础私有链接（模式 3）和资源网关（模式 4）连接上。模式 A 到 C 强化了 AWS PrivateLink 路径（模式 3 → A、B、C），客户在此路径中开始连接 FMI 托管的服务。模式 D 强化了资源网关路径（模式 4 → D），在该路径中，FMI 开始从参与者环境提取数据。
图 1：解决方案概述 — 两条水平通道代表 AWS FMI 博客中的基本连接路径。顶部显示了由模式 A、B 和 C 强化的客户启动的 AWS PrivateLink 路径（模式 3），底部显示了由模式 D 强化的 FMI 发起的资源网关路径（模式 4）
表 1：模式选择指南
架构师应应用模式 A 作为通用基准，然后根据运营成熟度、租户模型和要求对模式 B 到 D 进行分层。
模式 A — 持续付款会话的连接持久性
图 2：三层连接持久性显示（左）每隔 45 秒使用 sysctl keepalive 探测器的客户端支付网关实例、（中）注释了 350 秒空闲超时边界的 NLB TLS 侦听器，以及（右）支付网络终端节点目标实例。时间轴栏显示相对于 350 年代边界的探测时间。
-ISO 8583 支付协议使支付终端、处理器和支付网络端点之间的 TCP 连接保持开放数小时或数天。在非高峰时段（隔夜批量间隔、周末平静期或授权突发之间），这些连接处于空闲状态。TLS 侦听器的 NLB 空闲超时为 350 秒（固定），TCP 侦听器的 NLB 空闲超时时间为 60 到 6,000 秒（自 2024 年 9 月起可用）。当此超时到期时，NLB 会向客户端和目标端发送 TCP RST，强制关闭连接。对于支付工作负载，了解这个 RST 至关重要：如果它到达交易中期，客户可以在没有熵等密钥的情况下重试，这可能会触发重复授权。让 Keepalive 探测器在超时之前尽早触发，有助于避免流量恢复时进行全面的 TCP 握手和 TLS 重新协商（每个信道 100—300 毫秒）。
-客户端和目标实例上的 Linux TCP keepalive 参数会定期生成远低于 350 秒阈值的探测流量。使用 sysctl 设置 tcp_keepalive_time=45、tcp_keepalive_intvl=45 和 tcp_keepalive_probes=3 会导致内核在空闲时间 45 秒后发送一次 keepalive_probes=3，并每 45 秒重复一次。为了防止 NLB 超时，只有 45 秒的第一次探测很重要；它会在过期之前重置 NLB 空闲计时器。probes 参数控制死对端检测时间，而不是 NLB 保持活动状态。使用 probes=3 时，内核会在 45 + (45×3) = 180 秒未确认的探测后宣布对等方死亡。与 probes=9 相比，这支持更快地检测故障端点，后者将死点检测延迟到 450 秒。运营商应将探测次数与其特定支付网络的保持连接期望保持一致；一些信用卡网络允许在网络端维护期间保持多分钟的沉默，在这种情况下，更高的探测次数可以避免过早重新连接。通过 /etc/sysctl.d/99-keepalive.conf 在支付网关客户端实例和后端支付网络端点目标上持续应用这些设置。
-对于 TCP 侦听器（不是 TLS），增加可配置的空闲超时以匹配预期的最大空闲间隔加上安全余量（例如，结算批处理窗口为 900 秒）。对于 TLS 侦听器，超时时间保持固定在 350 秒，因此在 NLB 终止 TLS 的工作负载应依赖 keepalive 探测器而不是超时调整。
-对于无法使用 SO_KEEPALIVE 的支付堆栈，例如在不公开套接字选项的中间件上运行的传统 ISO 8583 网关，应用程序级心跳消息可作为替代方案。从 NLB 的角度来看，每 60—120 秒发送一次轻量级回声或网络管理消息可保持连接处于活动状态。目标是验证至少有一层（操作系统 keepalive、NLB 超时扩展或应用程序心跳信号）在空闲窗口内生成流量。操作系统级别的 keepalive 是首选的默认设置，因为它不需要更改应用程序代码。
重要：TLS 侦听器的 NLB 空闲超时固定为 350 秒。只有 TCP 侦听器支持 60—6,000 秒的可配置范围。对于在 NLB 终止 TLS 的工作负载，推荐使用保活探测器。
当持续会话支付协议通过 NLB 支持的 AWS PrivateLink 终端节点服务时，尤其是在非高峰时段的空闲间隔超过 60 秒时，请应用此模式。这还有助于降低重新连接期间重放的授权请求的等性风险。NLB RST 可以在没有警告的情况下到达，没有等效密钥的客户端可能会在不知不觉中重播最后一条正在运行的消息。折衷方案是少量的额外探测流量。这对于支付工作负载来说可以忽略不计，但在具有成千上万个持久连接的环境中值得考虑。对于连接池架构（例如基于 Netty 构建的支付网关或维护多个持久连接的类似框架），请为每个池成员应用这些 keepalive 设置。
由于现在可以在空闲窗口中保持持久连接，接下来的考虑因素是维护：如何在不丢弃活动会话的情况下替换后端目标？
模式 B — 使用生命周期挂钩和加权目标群组进行优雅维护
图 3：零停机维护操作时间表：（步骤 1）使用 modify-listener API 将蓝色目标组权重设置为 0。（步骤 2）剩余连接耗尽时的传播窗口。（第 3 步）取消注册流失：现有会话自然完成。（第 4 步）处于终止:等待状态的 EC2 Auto Scaling 生命周期挂钩。（第 5 步）已调用 CompleteLifecycleAction，终止操作继续进行。TG-Green/TG-blue 泳道条显示目标群体在一段时间内的状态。
AWS PrivateLink 背后的支付后端承载有状态的 mTLS/TCP 会话，其中单个连接可以处理数百条连续授权消息。NLB 加权目标组通过为每个目标组分配数字权重 (0—999) 来支持零停机时间维护。关键行为：权重仅适用于新连接。如果正在发送流量，则现有连接将固定到原始目标组中的目标长达一小时，或者直到空闲超时结束为止。这种连接固定行为支持在有状态支付会话中使用加权目标群组。
用于计划部署（权重转移为蓝绿色）
-将新实例部署到绿色目标组并验证运行状况检查是否通过。然后使用带有 forwardConfig.targGroups 的 modify-listener API 将蓝色目标组权重设置为 0。NLB 会在大约三分钟内停止将新连接路由到蓝组，而现有的长寿命的 ISO 8583 或 mTLS 会话在蓝色目标上继续不间断。
-对于支付协议变更的金丝雀部署，例如 EMV 3DS 版本升级，请将权重保持在 95/5 或 90/10 以延长观察窗口，在继续操作之前监控金丝雀目标群体的错误率。
-一旦蓝色组中的所有现有连接自然耗尽（或注销延迟到期），注销蓝色目标并终止。
用于计划外缩容（Auto Scaling 生命周期挂钩）
-当 EC2 Auto Scaling 扩展时，它会首先从负载均衡器中注销终止实例。连接耗尽在此阶段运行。取消注册延迟默认为 300 秒，最多可配置 3,600 秒。对于承载长期 mTLS 会话的支付后端，将此值设置为最大预期会话持续时间（例如，30 分钟结算批处理窗口为 1,800 秒）。只有在取消注册完成后，生命周期挂钩才会将实例置于 Terminating: Wait 状态。
-生命周期挂钩的默认等待状态为一小时（默认 HeartbeatTimeout 为 3,600 秒）。每次调用 RecordLifecycleActionHeartbeat 都会将超时时间延长 HeartbeatTimeout 值，最多延长 172,800 秒（48 小时）或 HeartbeatTimeout 100 倍这两者中较小值。默认心跳超时值为 3,600 秒，有效最大值为 172,800 秒。如果您设置较短的 HeartbeatTimeout（例如 300 秒），则有效的最大值将减少到 30,000 秒（约 8.3 小时）。在此等待状态下，运行自定义清理逻辑：刷新交易状态、检查点，并确认没有正在进行的结算批次剩余。清理完成后，调用 CompleteLifecycleAction 继续终止。
重要排序：取消注册在生命周期挂钩触发之前完成。将注销延迟（0—3,600 秒）调整为最长的预期会话持续时间。生命周期挂钩等待状态在耗尽完成后提供了额外的清理窗口。有效的最大等待时间是 172,800 秒或配置的 HeartbeatTimeout 的 100 倍，取其中的较小值。
应用此模式对承载有状态 TCP/MTLS 会话的支付后端进行定期或自动维护。折衷方案是操作的复杂性：权重转移和生命周期挂钩顺序需要自动化（通过 AWS Step Functions 或 AWS CodeDeploy 挂钩）和监控，以确认在生命周期超时到期之前排空完成。
模式 A 和 B 解决了单个租户连接路径中的操作注意事项。当多个外部租户共享同一个入站基础设施时会发生什么？
模式 C — 通过专用 NLB 进行租户级入站隔离
图 4：并排比较。左侧面板（共享 NLB）：多个租户 VPC 连接到单个共享 NLB，所有租户共享容量。右侧面板（专用 NLB）：每个租户通过自己的接口终端节点连接到注册为单独的 AWS PrivateLink 终端节点服务的专用 NLB，为每个租户提供独立的容量和监控。
-在共享的 NLB 架构中，来自多个支付租户（收单机构、发卡机构、支付处理商）的流量汇聚在单个网络负载均衡器上。虽然 PrivateLink 在消费者 VPC 之间提供网络级隔离，但 NLB 在第 4 层运行，并通过共享容量池为所有连接的租户提供服务。AWS PrivateLink 多租户 SaaS 参考架构指出，流量与其他客户隔离，“AWS PrivateLink、NLB 和 ALB 组件除外”，这使得 NLB 层成为为需要独立容量保障的支付工作负载增加租户级隔离的正确场所。
-为每个支付租户部署专用 NLB，并将每个 NLB 注册为单独的 AWS PrivateLink 终端节点服务。使用自己的 AWS 委托人许可列表来确定每个终端节点服务的范围，将终端节点的创建限制为特定租户的账户 ARN（例如，arn: aws: iam:: account_id: root）。这提供了连接级隔离：每个租户都在自己的 NLB 容量内运行，每个租户 NLB 无需基于标签的筛选即可生成独立的 Amazon CloudWatch 指标，从而简化了容量规划和事件响应。
为什么要专用 NLB 而不是单独的安全组？NLB 于 2023 年 8 月获得了安全组支持，在 NLB 层启用了访问控制（谁可以连接）。但是，安全组和专用 NLB 有不同的用途：安全组控制访问权限（限制哪些 IP 和端口可以访问 NLB），而专用 NLB 提供容量隔离（独立扩展、独立指标、独立故障范围）。对于同时需要访问控制和容量保障的支付工作负载，请在专用的每租户 NLB 上使用安全组。
-配额：在调整专用 NLB 部署规模之前，请查看 NLB 配额和 AWS PrivateLink 配额。关键限制包括每个区域 NLB（默认为 50，可调整）、每个可用区的目标和每个终端的带宽（默认情况下每个可用区 10 Gbps，扩展到 100 Gbps）。跨区域负载均衡处于活动状态时，每个负载均衡器的目标最大值将减少到 500，并且会收取跨可用区数据传输费用。
表 2：成本估算 — 共享与专用 NLB 模型
下表提供了用于比较共享和专用 NLB 架构的定向成本估算。实际成本取决于流量、NLCU 消耗和可用区部署选择。
注意：NLCU 费用基于使用量，因流量模式而异。专用模型提供每个租户的 NLCU 可见性，但对于等效的总流量，NLCU 的总成本相似。要求将配额增加到每个地区超过 50 个 NLB。
-Dedicated-NLB 模式会随着租户数量线性增加 NLB 的小时成本，并消耗 50 NLB 的默认区域配额，需要将配额增加到大约 50 个租户以上。混合方法平衡成本与隔离：对流量模式可预测的低容量内部租户使用共享 NLB，为需要独立容量保障的高价值或高风险外部租户使用专用 NLB。
在运营租户是外部支付网络参与者或需要独立容量保证的多租户支付平台时，应用此模式。权衡是线性成本乘法和配额消耗。将其与租户级隔离的运营价值进行权衡。
模式 A 到 C 强化了客户到 FMI 的路径。最终的模式改变了方向：FMI 发起的数据提取需要哪些生产控制？
模式 D — 针对 FMI 发起的连接进行资源网关强化
图 5：FMI VPC（左）包含通过 VPC 莱迪思服务网络连接到参与者的资源网关（中）的资源终端节点。三项最佳生产实践说明：(1) CloudWatch Synthetics Canary 使用 Route 53 故障转移路由探测数据终端节点；(2) 资源网关安全组出站规则范围限于特定端口；(3) 使用并行资源网关部署进行多区域故障转移。
-与消费者启动与服务提供商连接的 AWS PrivateLink 不同，资源网关允许 FMI（作为消费者）访问参与者的 VPC 中的特定资源，而无需参与者运行 NLB 或终端节点服务。FMI 连接博客中的模式 4 使用此模型：客户部署资源网关，通过 IP 地址、域名系统 (DNS) 名称或 ARN 注册特定资源，并通过 AWS 资源访问管理器 (AWS RAM) 与 FMI 账户共享网关。然后，FMI 在其 VPC 中创建资源终端节点以访问注册的资源。资源网关是 VPC Lattice 的一个组件。它出现在 AWS PrivateLink 文档和 VPC Lattice 文档中，因为它桥接了两种服务，但它本质上是 VPC Lattice 架构的一部分。资源网关支持每个 VPC 最多 100 个网关，每个区域每个账户支持多达 2,000 个资源配置，每个可用区 100 Gbps 带宽，这对于大多数支付对账工作负载来说非常充足，但值得在大批量结算周期之前主动监控。
-VPC Lattice 运行状况检查适用于具有可配置的 HTTP/HTTPS 检查的目标群组（服务）：间隔 5—300 秒，超时 1—120 秒，运行状况阈值 2—10，不健康阈值 2—10。资源配置使用仅限 TCP 的协议，因此添加外部运行状况监控可提供应用程序级别的可见性。部署 Route 53 运行状况检查或 Amazon CloudWatch Synthetics Canaries，直接探测实际数据终端节点，独立于资源网关触发 DNS 故障转移。
-VPC Lattice 通过三个安全层提供深度防御：明确的 VPC/终端关联、安全组和网络 ACL 以及可选的身份验证策略。对于资源配置，安全组和 IAM/RAM 控制是主要的执行点。资源网关安全组控制从网关到注册资源的出站流量（网关到资源方向）。这与典型的入站安全组规则不同。将这些出站规则锁定到特定的数据库或文件服务端口（例如，TCP 3306、5432 或 443），并将目标 CIDR 限制在注册资源的 IP 范围内，从而确保参与者 VPC 内的精确访问控制。
-资源网关是区域范围的：绑定到单个区域内的 VPC 及其子网。对于需要对账和结算数据提取进行故障转移的多区域支付部署，请在每个目标区域部署并行资源网关和资源配置，并使用 Route 53 故障转移路由将 FMI 客户端定向到活动区域。AWS RAM 共享治理支持参与者与 FMI 账户共享资源配置。在 AWS 组织内，消费者可以自动访问；在组织外部，他们必须接受邀请。如果没有参与者的明确重新共享，FMI 无法将访问权限重新共享给第三方。
重要：VPC Lattice 服务网络上的身份验证策略适用于服务，但不适用于资源配置。安全组（出站规则）和 IAM/RAM 控制是资源配置的主要执行点。将出站安全组 (SG) 规则的范围限定为特定端口和目标 CIDR。
当 FMI 需要从参与者环境中提取对账数据、结算文件或监管报告时，尤其是在避免部署和管理 NLB 和端点服务的运营开销时，应采用这种模式。折衷方案是外部监控基础设施和 SG 规则管理的额外运营开销，但这提供了生产支付工作负载所需的应用程序级可见性和访问控制精度。
安全注意事项
传输过程中的加密在这些模式中分两层运行。对于将 AWS Direct Connect 作为迁移路径或混合架构的一部分运营的组织，MacSec（IEEE 802.1AE）在特定位置的专用连接上提供第 2 层点对点加密，速度为 10 Gbps、100 Gbps 和 400 Gbps。TLS 保护通过 AWS PrivateLink 边界的流量，NLB 支持 TCP 直通，以在负载均衡器上保留端到端 TLS 或 TLS 终止。对于通过直接连接的支付流，完整的加密链是：
本地支付路由器 → (MacSec) → Direct Connect Edge →（AWS 物理层加密）→ VPC 终端节点 ENI → (TLS) → NLB → 支付后端目标。
对于没有直接连接的部署，跨越 AWS PrivateLink 边界的 TLS 提供了加密层，而 AWS 物理层加密则保护了在 AWS 设施之间传输的数据。
对于 DNS 解析和故障转移，在接口终端节点上启用私有 DNS 会创建 AWS 管理的 Route 53 私有托管区域，该区域会覆盖该服务的公有 DNS 名称，以解析到 VPC 内的终端节点 ENI 私有 IP。区域 DNS 名称（例如 vpce-xxx.us-east-1a.vpce-svc-xxx...）支持 AZ 感知路由。Route 53 运行状况检查间隔为 10 秒，故障阈值为三分之二，可提供符合付款 SLA 要求的不到一分钟的故障转移检测。支付工作负载应首选区域 DNS 解析，以避免将交易路由到受损的可用区。
AWS PrivateLink 每隔 1 分钟发布一次亚马逊 CloudWatch 指标，包括 ActiveConnections、BytesProcessed、newConnections、PacketsDropped 和 RstPackets 最后一个指标对于监控模式 A 中描述的连接生命周期行为特别有价值。NLB 访问日志可以传输到 Amazon CloudWatch Logs、Amazon S3 或 Amazon Data Firehose，用于实时分析连接模式和 TLS 握手细节。VPC Flow Logs v3 字段捕获 PrivateLink ENI 流量，包括 pkt-srcaddr、pkt-dstaddr 和 tcp 标志，用于连接级别分析。
表 3：可观测性 — 每个模式的关键指标和警报阈值
结论
在这篇文章中，我们介绍了将 AWS PrivateLink 和资源网关连接从参考架构转移到生产级支付基础设施的四种模式：
-模式 A（连接持久性）：任何穿过 NLB 支持的 AWS PrivateLink 的持久会话协议的通用基准。无需更改架构，只需配置 sysctl 即可。
-模式 B（平滑维护）：对需要会话连续性的有状态支付后端进行零停机部署。
-模式 C（租户隔离）：连接级隔离，多租户平台的每个租户具有独立容量。
-模式 D（资源网关强化）：针对 FMI 发起的数据提取进行生产级运行状况监控和访问控制精度。
每种模式均可独立采用。首先使用模式 A 作为即时运营改进，然后根据您的运营成熟度、租户模型和特定要求对模式 B 到 D 进行分层。通过对照实验验证每种情况：观察空闲窗口 (A) 上的连接行为，在暂存环境 (B) 中执行权重转移顺序，确认负载下的租户隔离 (C)，以及测试多区域故障转移 (D)。
这些模式共同为架构师和网络工程师提供了从第一天起在 AWS 上运行生产支付连接的操作手册。
如果您有任何疑问或想分享实施这些模式的经验，请在下面发表评论。有关更多信息，请参阅以下资源：
-金融市场基础设施的 AWS 云连接模式（必备博客文章）
-AWS 私有链接文档
-亚马逊 VPC Lattice 文档
-网络负载均衡器文档
-EC2 Auto Scaling 生命周期挂钩