全球实时支付市场正在经历显著增长。根据 Fortune Business Insights 的数据，2024 年该市场估值为 249.1 亿美元，预计到 2032 年将增长至 2844.9 亿美元，复合年增长率（CAGR）为 35.4%。同样，Grand View Research 报告称，2024 年全球移动支付市场估值为 885.0 亿美元，预计 2025 年至 2030 年的复合年增长率为 38.0%。（免责声明：第三方市场研究和统计数据仅供参考。AWS 和 IBM 不对该信息的准确性作出任何陈述。）

这种快速扩张凸显了金融机构现代化其支付处理基础设施的紧迫性。金融机构通常需要以接近零延迟处理大量交易，以满足严格的服务水平协议（SLA），从而支持激增的移动支付量。

然而，传统支付编排系统通常构建在单体架构之上，因延迟、可用性和可扩展性方面的挑战而难以满足这些需求。此外，它们对本地基础设施的依赖导致成本更高并阻碍创新，进一步强化了现代化改造的必要性。

随着可持续性成为优先事项，各组织正转向基于云的解决方案来优化基础设施、减少碳足迹并提高能源效率。这一转变提供了可扩展性和性能，并与全球可持续发展目标保持一致，保障实时支付的未来。

在本文中，我们讨论实时支付编排框架。它使用事件驱动架构和 AWS 无服务器服务来增强实时支付的弹性、效率和可扩展性。通过将支付处理分解为不同的业务能力，金融机构可以提高模块化和灵活性。实施基于租户的隔离有助于数据隔离和安全性。此外，通过 Amazon Managed Streaming for Apache Kafka（Amazon MSK）采用异步通信可增强可扩展性和弹性。

传统实时支付编排

支付编排作为一种中间件解决方案，简化了跨多种支付方式、网关和金融机构的交易处理。它编排关键业务功能，如支付授权、支付处理、结算与清算、合规与风险管理，以及入站和出站支付流程的账户管理。

下图描绘了支付编排器在各种支付流程中支持的高层业务能力，包括实时支付、数字 disbursement、税务支付、电汇等。

详细流程图描绘了一个包含多个组件的支付处理系统。该图顶部显示了主要支付类型（包括实时支付、数字 disbursement、信用转账和点对点支付），向下流经核心处理阶段，包括支付受理、执行、清算、报告、跟踪、冲正和计费。

许多金融机构采用按地理区域组织的基于租户的方法，因为不同 AWS 区域之间的清算流程、本地化法规和交易要求各不相同。然而，如果没有适当的服务分离，团队往往会继续向现有服务添加特定于区域的逻辑，逐渐增加其单体复杂性，并对所有支付流程使用相同的基础设施。

传统支付系统以线性方式处理交易，每一步都等待前一步完成。然而，对支付工作流的分析揭示了大量并行执行的机会：

• 制裁筛查与欺诈检测——合规与欺诈检查可以与初始路由决策同时运行，而不是顺序阻塞所有后续处理

• 支付路由与授权请求——当基本验证完成后，路由和授权可以并行进行，而不是一个接一个地执行

• 支付执行与账本更新——实际的支付执行不需要等待账本记录更新——这些可以并发发生

• 结算、对账与跟踪——这些交易后流程可以在主交易完成后立即独立启动

与传统的基于队列的系统相比，这种并行方法可以显著提高吞吐量并降低延迟，在传统系统中，操作形成顺序链，延长处理时间并造成瓶颈。

大多数传统支付编排系统严重依赖本地虚拟机（VM），导致若干挑战：

• 多区域灾难恢复和多租户支持导致大量资本支出和运营开销

• 顺序消息处理以及全球分散数据中心之间的延迟导致高延迟和 SLA 问题

• 支付流程的可复用性有限，因为单体架构需要针对本地清算机制和法规进行区域特定更改，增加了复杂性和成本

• 由于资源利用效率低下以及跨区域执行无关逻辑，导致可扩展性挑战和高内存消耗

• 由于清算规则、交易限额和本地法规的差异，导致复杂的跨境支付路由，增加了延迟和路由错误

• 由于传统系统依赖专有标准（例如 ISO 20022、SWIFT MT），导致与多样化数据格式的集成挑战，使数据转换和合规变得复杂

• 由于单体架构需要大量区域特定修改，新支付流程的部署复杂性高，减缓了上市时间

• 本地基础设施消耗过多能源，造成环境影响和高碳足迹，而基于云的方法可提高效率

解决方案概述

为了克服这些挑战，所提出的架构采用以下设计原则，构建面向未来的实时支付编排解决方案：

• 大规模性能——在不同负载条件下处理超过每秒 1,000 笔交易（TPS），并保持一致的 低延迟。

• 高可用性——实现 99.999% 的正常运行时间，以满足金融交易的严格要求。

• 地理韧性——支持具有区域特定合规性的全球运营，同时保持一致性能。

• 成本优化——通过高效资源利用和无服务器技术降低总拥有成本。

• 安全与合规——支持不同司法管辖区内的数据保护和法规遵循。

• 运营简单性——简化整个支付生态系统中的部署、监控和维护。

• 微服务——将支付处理分解为不同的业务能力，使金融机构能够提高模块化和灵活性。这种基于微服务的方法允许关键组件独立扩展和开发。

下图描绘了实时支付的高层解决方案架构。使用同步或异步 API（应用程序编程接口） 的现有渠道可以修改为使用边缘优化端点以降低延迟。

架构图详细展示了基于 AWS 的支付编排平台，利用事件驱动原则。具有跨两个区域的可复用组件，并包含用于支付发起、执行、对账、计费和风险管理的专用模块。实现用于组件间通信的发布/订阅消息模式，并连接到包括会计、合规和分析在内的企业系统。

支付编排采用事件驱动架构，通过发布/订阅模式处理通信。该架构维护持久连接，提高端到端实时支付处理的性能。

用于实时支付处理的事件驱动架构允许使用不同适配器同时执行多个支付操作，而传统系统中的支付流程是顺序的，并通过单一管道流动。支付事件根据其功能（发起、执行、跟踪、结算）分发到专门的支付处理器微服务，使每个微服务能够独立处理，而无需等待其他微服务完成。

由于我们正在从顺序处理过渡到分布式处理，维护事务可追溯性至关重要。上图中展示的支付跟踪适配器连接到企业分析系统，创建了一个专门用于监控事务的层。发布/订阅模型允许将关联 ID 附加到事件上，使系统能够跨不同主题和处理阶段跟踪相关事件。

标准化事件模式是该架构的基础，它在各区域部署之间提供一致性，同时允许在适配器层面进行定制。该模式定义了包含租户特定元数据的统一事件结构，并支持版本控制以适应不断变化的需求。通过将区域特定的差异隔离到适配器层，该解决方案在保持核心功能的同时，通过配置驱动的定制而非代码更改来与多样化的企业系统对接。

对于大多数支付流程，尤其是那些具有可并行运行的独立处理步骤的流程，该架构尽管存在主题切换开销，仍能带来净性能提升，特别是对于需要多个独立验证或处理步骤的复杂事务。

在 AWS 云上部署

该解决方案使用边缘优化的 Amazon API Gateway 作为通道入口。边缘优化的 API 端点将请求路由到最近的 Amazon CloudFront 接入点（POP），这在客户端地理分布广泛的情况下有助于实现各地理区域内的高效路由，通过最小化网络往返来增强全球响应能力，并确保请求在从公共互联网过渡到客户端网络之前走最短路径。

下图展示了实时支付的高层解决方案架构。

全面的 AWS 支付编排解决方案，实现了现代云原生架构原则。核心处理逻辑以 Lambda 函数实现，涵盖发起、执行、对账、计费、跟踪、风险管理和结算工作流。利用 Amazon MSK 在组件之间实现可靠的事件流传输，每个处理阶段都有专用的 Kafka 主题。数据持久化由 Amazon DynamoDB 处理，支持跨区域操作。该架构展示了 AWS 在金融服务领域的最佳实践，包括区域冗余、无服务器计算、托管服务和事件驱动设计模式。系统与外部银行基础设施和企业系统集成，同时通过微服务架构保持关注点分离。通过专用的 Lambda 函数内置了对合规监控、风险管理和支付跟踪的支持。

该解决方案使用 Amazon MSK 实现事件驱动架构，通过 API 请求和异步消息事件高效处理入站和出站通道流量。Amazon MSK 在生产者和消费者之间使用高性能二进制协议进行通信，提供低延迟和高吞吐量。实时支付在地理区域——北美、EMEA、LATAM 和亚太地区——内的多个租户之间进行逻辑分区。

每个实时支付租户遵循主动/主动灾难恢复策略，通过在多个 AWS 区域部署 MSK 集群来实现高可用性和弹性。Amazon MSK 提供无服务器和预置集群两种选项。团队可以根据非功能性需求和团队专业能力决定选择哪一种。Amazon MSK 自动管理分区领导者，主区域中的领导者与辅助区域中的跟随者协同工作。在故障转移期间，领导者会在健康区域中重新选举，旨在帮助在区域事件期间维持处理能力。粘性分区使用一致性哈希实现确定性路由，协作再平衡实现高效故障转移。多可用区部署提供区域冗余，每个区域使用隔离集群，通过编程式 AWS Identity and Access Management (IAM) 和虚拟私有云 (VPC) 边界实现数据主权合规。

为支持无缝跨区域复制并保持消息连续性，使用 Amazon MSK Replicator——Amazon MSK 的一项完全托管功能——来跨集群复制主题并同步消费者组偏移量。MSK Replicator 简化了构建多区域 Kafka 应用程序的过程，无需自定义代码、开源工具配置或基础设施管理。它自动预置和扩展所需资源，使团队能够专注于业务逻辑，同时只需为复制的数据付费。在区域中断或故障转移的情况下，流量可以自动重定向到健康区域，不会造成数据丢失或服务中断，为支付处理器和审计跟踪消费者等下游服务提供接近零的恢复时间目标（RTO）和不间断运营。

除了区域冗余之外，该架构还使用事件驱动架构来实现支付事务的并行和解耦处理。事务发起、验证和结算等事件以异步方式发出，并由各种微服务独立消费，从而大幅降低端到端延迟。

为了大规模处理这些事件，该架构可以根据非功能性需求使用 AWS Lambda、Amazon Elastic Container Service (Amazon ECS) 或 Amazon Elastic Kubernetes Service (Amazon EKS)。自动扩缩容响应 Amazon CloudWatch 指标，带有死信队列（DLQ）的指数退避重试逻辑处理限流场景。断路器在高错误率期间防止级联故障。

该解决方案的关键优势之一是支付流程在不同区域间的可复用性。尽管每个区域都有其独特的合规要求和结算规则，但实时支付的核心功能（支付授权、支付处理、结算和清算）在很大程度上是相似的。这种可复用性使得支付解决方案能够在新区域快速部署，而无需重新架构整个系统。例如，美国和英国的实时支付系统可能在实时全额结算方面共享相似的业务逻辑，但在清算和合规要求上有所不同。该解决方案将这些视为微服务架构中的限界上下文，在提供灵活性的同时确保每个区域能够处理其特定的规则和法规。

可持续性

AWS 在基础设施的设计、构建和运营方面持续创新，以朝着 2040 年实现净零碳排放和 2030 年实现水资源正效益的目标迈进。基于 AWS Graviton 的 Amazon MSK 实例比同类 M5 实例能耗降低多达 60%，帮助您实现可持续发展目标。Lambda 在设计上具有固有的可持续性。其无服务器模式确保仅在需要时使用计算资源，大幅减少闲置基础设施和能源浪费。Lambda 无需为不频繁的任务保持常开服务器，而是按需即时配置计算能力，实现接近零的闲置容量。

金融服务中的安全与合规

鉴于支付交易和金融数据的敏感性，您应根据组织的需求，应用满足金融法规（如 AWS PCI DSS 和 AWS 联邦信息处理标准 (FIPS) 140-3）所需的安全控制措施。

该解决方案应纳入多层安全控制、持续监控和自动化合规审计，以满足银行监管机构和内部风险团队的严格要求。更多信息，请参阅安全指南。

结论

使用事件驱动架构和 AWS 无服务器技术对支付编排系统进行现代化改造，标志着在满足当今快速演变的金融服务格局需求方面取得了重大进展。该解决方案解决了传统支付系统面临的关键挑战，同时在性能、可扩展性、成本优化、全球韧性、可持续性和合规性方面带来了显著收益。通过使用前沿云技术和强大的安全控制，金融机构现在可以构建面向未来的基础架构，在适应不断变化的业务需求的同时，保持最高标准的性能、安全性和可靠性。随着实时支付市场持续爆发式增长，这一现代架构提供的解决方案不仅满足当今需求，也为支持未来的支付创新做好了充分准备。希望对其支付基础设施进行现代化改造的组织可以使用这一蓝图来加速其数字化转型之旅，在日益激烈的全球市场竞争中支持可持续、安全和高效的大规模支付处理。

此处展示的架构仅供参考。IBM 将与您紧密合作，按照行业标准和合规要求部署该解决方案。更多资源，请参阅：

• IBM Consulting on AWS

• AWS for Financial Services

• Transforming transactions: Streamlining PCI compliance using AWS serverless architecture

• Best practices for right-sizing your Apache Kafka clusters to optimize performance and cost

• How to choose the right Amazon MSK cluster type for you

• AWS Shared Responsibility Model

• AWS Federal Information Processing Standard (FIPS) 140-3

• Sustainability with AWS Graviton

• AWS PCI DSS

转载声明：本文为转载整理，原文版权归原作者及原站点所有。

原文来源：AWS Architecture Blog

原创地址：https://aws.amazon.com/blogs/architecture/modernization-of-real-time-payment-orchestration-on-aws/