**发布时间:** 2025-09-24
**厂商:** AWS
**类型:** BLOG
**原始链接:** https://aws.amazon.com/blogs/networking-and-content-delivery/building-a-high-performance-exchange-market-data-broadcasting-platform-on-aws/
---
<!-- AI_TASK_START: AI标题翻译 -->
[解决方案] 基于 AWS 打造高性能交易所行情数据广播平台
<!-- AI_TASK_END: AI标题翻译 -->
<!-- AI_TASK_START: AI竞争分析 -->
# 解决方案分析
## 解决方案概述
SMC Global Securities (SMC) 与 AWS 合作,构建了一个高性能、可扩展的金融市场数据广播平台,以现代化其零售交易基础设施。该解决方案的核心目标是解决其原有本地基础设施在处理来自印度各大交易所(NSE, BSE, MCX, NCDEX)的海量实时行情数据时面临的**可扩展性瓶颈**和**性能问题**。
该方案的技术亮点在于,它创新性地解决了将外部**组播网络 (multicast networking)** 数据直接引入AWS云环境的行业性难题。传统方案通常在本地将组播流转换为单播流再传输至云端,效率较低。SMC的架构通过结合使用 **AWS Transit Gateway** 的原生组播支持和 **Fortinet SD-WAN** 覆盖网络方案,在 **AWS Direct Connect** 专线上建立 **通用路由封装 (GRE)** 隧道,成功地将来自本地数据中心的实时组播行情数据直接、高效地引入AWS VPC,为上层应用的低延迟处理奠定了基础。
## 关键设计原则与实现
1. **混合云网络连接与组播上云**
- **连接基础**: 使用 **AWS Direct Connect** 在本地数据中心和AWS之间建立高带宽、低延迟的私有网络连接。
- **组播传输**: 为满足合规要求,行情数据在本地数据中心接入。通过部署 **Fortinet SD-WAN** 设备,将原始的组播数据包封装在 **GRE隧道** 中,再通过Direct Connect专线传输至AWS。
- **云端路由**: 在AWS端,**AWS Transit Gateway** 作为云网络路由器,其配置的组播域能够识别并路由解封后的组播流量,将其高效分发给VPC内订阅了该组播组的后端应用实例。
2. **高性能应用架构设计**
- **优先保证数据新鲜度**: 为实现极致的实时性,系统设计为可丢弃陈旧的中间状态事件(例如,一个股票价格在1秒内多次变动,只推送最新的价格),优先保证用户看到的是最新行情。
- **数据对账与补全机制**: 针对可能丢失或丢弃的数据,设计了一套独立的、基于 **Amazon ECS** 微服务的实时记录与对账系统。
- 使用 **Amazon ElastiCache** 高速缓存最新的数据包,用于快速访问。
- 使用 **Amazon RDS PostgreSQL** 进行长期数据存储和批量对账,确保数据的最终完整性。
- **高吞吐并行处理**: 在所有关键路径上采用多线程处理。为突破单个实例的网络带宽限制,在节点间建立多个TCP连接以并行传输数据流。
- **保证数据处理顺序**: 开发了一个自定义的按时间顺序处理组件,部署在数据呈现给用户之前,以解决多线程环境下可能出现的乱序问题。
3. **大规模客户端连接管理**
- **实时推送**: 采用 **WebSocket** 技术向Web和移动客户端进行实时、双向的数据推送,以降低延迟和网络开销。
- **应对连接挑战**:
- **连接管理**: WebSocket的持久连接特性给传统负载均衡和弹性伸缩带来挑战。
- **惊群效应 (Thundering Herd)**: 开盘或系统维护后,大量客户端同时重连可能压垮服务器。
- **解决方案**:
- 通过自定义 **Amazon CloudWatch** 告警实现基于连接数的弹性伸缩。
- 在客户端实施带**指数退避和抖动 (exponential backoff and jitter)** 的交错重连机制,避免瞬时冲击。
4. **生产级韧性与可观测性**
- **环境治理**: 采用 **AWS Control Tower** 建立和治理一个安全、合规的多账户AWS环境(Landing Zone)。
- **监控体系**: 部署了定制化的LGTM技术栈(**Loki**日志, **Grafana**可视化, **Tempo**追踪, **Mimir**指标)进行全面的监控和观测。
- **事件管理**: 与 **AWS Systems Manager Incident Manager** 集成,实现集中的事件通知、管理与快速恢复。
## 方案客户价值
- **显著的性能提升**: 实现了端到端延迟_降低约60%_,为交易者提供了近乎实时的市场数据,极大地改善了用户交易体验。
- **高可扩展性与弹性**: 系统能够平稳处理每秒超过**10万条**消息和数万名并发用户。利用云的弹性,在交易高峰期自动扩容,盘后自动缩容,有效优化了成本。
- **卓越的系统可靠性**: 实现了**零停机时间**的运行目标。通过完善的架构设计、全面的可观测性及事件管理系统,确保了平台的稳定性和快速故障恢复能力。
- **加速业务创新**: 将技术团队从繁琐的基础设施运维(如手动扩容、系统补丁)中解放出来,使其能更专注于业务逻辑和产品功能的创新。
## 涉及的相关产品
- **AWS 服务**
- `AWS Transit Gateway`: 核心网络枢纽,提供云上原生的组播路由功能。
- `AWS Direct Connect`: 在本地数据中心和AWS之间建立私有、高带宽的网络连接。
- `Amazon ECS`: 容器编排服务,用于运行数据处理和WebSocket应用等微服务。
- `Amazon ElastiCache`: 内存数据存储,用于高速缓存最新数据包以加速访问。
- `Amazon RDS for PostgreSQL`: 托管关系数据库,用于长期数据存储和批量对账。
- `AWS Control Tower`: 建立和治理安全、合规的多账户AWS环境。
- `Amazon CloudWatch`: 监控服务,用于实现基于连接数的自定义告警和弹性伸缩。
- `AWS Systems Manager Incident Manager`: 集中化事件管理和响应。
- **第三方产品**
- `Fortinet SD-WAN`: 作为覆盖网络解决方案,通过GRE隧道将本地组播流量延伸至AWS。
- `LGTM Stack (Loki, Grafana, Tempo, Mimir)`: 用于构建全面的日志、监控、追踪和指标系统。
## 技术评估
- **优势**
- **架构创新性**: 巧妙地结合AWS原生服务(Transit Gateway)和第三方SD-WAN,解决了金融行业将外部组播数据引入云的核心痛点,具有很强的行业示范效应。
- **极致性能导向**: 架构设计中处处体现了对性能的追求,如优先保证数据新鲜度、多线程处理、WebSocket推送等,完全满足金融交易场景的严苛要求。
- **端到端完整性**: 方案覆盖了从网络接入、数据处理、客户端推送到治理和可观测性的完整生命周期,考虑周全,系统韧性高。
- **云原生实践**: 充分利用了AWS的托管服务(ECS, ElastiCache, RDS),显著降低了运维复杂性,实现了高度自动化和弹性。
- **可能的限制**
- **实施复杂性**: 该方案整合了AWS服务和第三方网络设备,对网络和应用架构团队的技术能力要求较高,实施和维护具有一定复杂性。
- **成本考量**: 方案依赖于AWS Direct Connect、Transit Gateway和第三方商业SD-WAN产品,对于小型机构而言,初始投入和持续成本可能较高。
- **厂商依赖**: 对Fortinet SD-WAN的依赖可能在一定程度上造成技术栈锁定,尽管其核心逻辑可被其他支持GRE隧道的SD-WAN方案替代。
<!-- AI_TASK_END: AI竞争分析 -->
<!-- AI_TASK_START: AI全文翻译 -->
# 在 AWS 上构建高性能交易所行情数据广播平台
**原始链接:** [https://aws.amazon.com/blogs/networking-and-content-delivery/building-a-high-performance-exchange-market-data-broadcasting-platform-on-aws/](https://aws.amazon.com/blogs/networking-and-content-delivery/building-a-high-performance-exchange-market-data-broadcasting-platform-on-aws/)
**发布时间:** 2025-09-24
**厂商:** AWS
**类型:** BLOG
---
*本文由 SMC Global Securities Ltd. 的首席产品和技术官 Abhishek Chawla、云工程总监 Kartik Manimuthu 以及应用工程总监 Digvijay 联合撰写。*
[SMC Global Securities Ltd.](https://www.smctradeonline.com/) (SMC) 成立于 1990 年,是印度领先的金融服务公司,为散户投资者、企业和高净值个人提供交易、财富咨询和金融产品分销服务。
SMC Global Securities (SMC) 与 [Amazon Web Services (AWS)](https://aws.amazon.com/) 合作,对其零售交易基础设施进行了现代化改造。作为该计划的一部分,SMC 在 AWS 上构建了一个强大的金融数据分发系统,能够高效处理来自印度主要交易所 (NSE、BSE、MCX 和 NCDEX) 的实时市场行情。该平台利用 [组播 (Multicast) 网络技术](https://en.wikipedia.org/wiki/Multicast) 直接捕获和广播市场价格数据,实现了高性能和高可扩展性。
许多 AWS 用户在云上运行核心金融系统,通常处理来自其本地基础设施的单播 (Unicast) 数据。这通常涉及在将组播 (Multicast) 源数据通过 [AWS Direct Connect](https://aws.amazon.com/directconnect/) 传输到 AWS 之前,将其转换为单播 (Unicast)。然而,直接在 AWS 上接收外部组播 (Multicast) 数据对许多组织来说一直是个挑战。本文探讨了 SMC 为克服这些障碍而采用的创新方法。我们展示了 SMC 如何利用 [AWS Transit Gateway](https://aws.amazon.com/transit-gateway/) 内置的组播 (Multicast) 支持,在 [Amazon Virtual Private Cloud](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html) (Amazon VPC) 环境中进行通信,并结合 [Fortinet SD-WAN](https://www.fortinet.com/content/dam/fortinet/assets/data-sheets/fortinet_secure_sdwan.pdf) 作为覆盖解决方案。该设置使 SMC 能够通过 Direct Connect 建立 [通用路由封装 (Generic Routing Encapsulation, GRE)](https://www.rfc-editor.org/rfc/rfc2784) 隧道,成功地将来自其本地系统的组播 (Multicast) 价格行情直接引入 AWS 云。
#### **AWS Transit Gateway 概述**
AWS Transit Gateway 是一个网络中转枢纽 (network transit hub),通过中心辐射模型 (hub and spoke model) 互连多个 VPC 和本地网络,从而简化连接。它支持多种连接类型,如 VPC、[SD-WAN 设备](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-connect.html)、Direct Connect 网关、VPN 连接以及其他 Transit Gateway。这消除了对复杂的点对点连接的需求。其一项关键功能是原生支持 [组播 (Multicast) 通信](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-multicast-overview.html),它可以自动处理复杂的组播 (Multicast) 路由,适用于将流量发送到同一组播 (Multicast) 组中多个接收实例的场景。
### 挑战
SMC 开启其 AWS 之旅的核心理念是为终端用户提供“快速无缝的交易体验”。拥有一个高性能的广播平台是实现这一体验的关键。这是因为广播平台从证券交易所接收事件并将其发送给交易员,使其成为现代零售交易应用的关键组成部分。
SMC 需要一个能够向交易员提供近乎实时的金融市场数据且对丢包 (packet loss) 零容忍的系统,因为即使丢失一个交易数据包也可能导致显示错误的关键市场信息 (例如 52 周新高)。这可能会给交易员带来重大的经济损失,并损害客户的信任。SMC 现有的本地广播基础设施面临可扩展性挑战,无法满足其现代金融交易应用苛刻的性能要求,导致其关键基础设施频繁停机和性能下降。
### 解决方案概述
组织需要混合网络连接 (hybrid network connectivity) 来无缝连接其本地数据中心、远程位置和云基础设施。AWS 为混合架构提供了 [多种连接选项](https://docs.aws.amazon.com/whitepapers/latest/hybrid-connectivity/hybrid-network-connections.html),例如 Direct Connect 和 AWS [Site-to-Site VPN](https://docs.aws.amazon.com/vpn/latest/s2svpn/VPC_VPN.html),以安全地连接本地资源与 AWS。
SMC 所在的金融业务领域受到严格监管,因此当他们开始在 AWS 云上设计其混合金融广播平台时,设定了四个主要目标:
- 可扩展性
- 可靠性
- 性能
- 安全性
为了大规模地实现这些目标,SMC 采用 [AWS Control Tower](https://aws.amazon.com/controltower/) 在 AWS 上部署其工作负载。AWS Control Tower 提供了一种清晰高效的方式来建立和治理一个安全的多账户 AWS 环境。它基于最佳实践蓝图建立一个 [登录区 (landing zone)](https://docs.aws.amazon.com/prescriptive-guidance/latest/migration-aws-environment/understanding-landing-zones.html),并使用预打包列表中的 [控件 (controls)](https://docs.aws.amazon.com/controltower/latest/userguide/controls.html) 提供治理。该登录区 (landing zone) 是一个遵循 AWS 最佳实践、[架构完善 (well-architected)](https://docs.aws.amazon.com/wellarchitected/latest/framework/welcome.html) 的多账户基准。
#### 设计考量
为了满足传统交易所要求行情数据价格源网络连接必须终止于本地位置的合规要求,SMC 评估了两种架构方案:
1. 在数据中心终止交易所的组播 (Multicast) 价格行情,将其转换为单播 (Unicast),然后将现有的广播解决方案重新托管到 AWS。虽然这种方法更快、所需工作量更少,但 SMC 需要将现有解决方案的低效问题作为技术债务带到云上。
2. 在数据中心终止交易所的组播 (Multicast) 价格行情,并直接将组播 (Multicast) 源发送到 AWS。这使得可以使用 AWS 原生服务重新设计广播解决方案。
经过仔细评估,SMC 决定在 AWS 上彻底重新构建其系统。这一战略决策由两个关键目标驱动:
1. 构建一个面向未来的架构
2. 利用 AWS 原生服务最大化收益
为实现这些目标,平台设计采用了以下核心原则:
**优先保证事件的新鲜度而非完整性**
为了性能和实时相关性,系统应丢弃过时的事件。例如,如果某证券 XYZ 的 [最新成交价 (Last Traded Price, LTP)](https://d2908q01vomqb2.cloudfront.net/5b384ce32d8cdef02bc3a139d4cac0a22bb029e8/2025/09/24/Figure1-1.png) 在时间 T1、T2 和 T3 分别为 100、101 和 102,那么系统可以丢弃价格 100 和 101,直接显示价格 102。用户在查询 LTP 时主要关心当前价格,而不是过时的历史价格。

图 1 – 最新成交价
然而,历史价格对于分析趋势至关重要,例如 12 周高/低点、52 周高/低点或查看聚合订单列表。

图 2 – 价格列表高低点
因此,该解决方案需要一个近乎实时的所有最新价格数据视图,以及一个理想的机制来通过备用路径对账被丢弃/丢失的数据包。为了解决这个问题,一个实时记录和对账系统被开发出来,并作为独立且可扩展的微服务 (microservices) 部署在 [Amazon Elastic Container Service](https://aws.amazon.com/ecs/) (Amazon ECS) 集群上,利用 AWS 原生服务进行消息处理:
- [Amazon ElastiCache](https://aws.amazon.com/elasticache/) 用于缓存和反映最新记录的数据包,以实现更快的访问
- [Amazon RDS PostgreSQL](https://aws.amazon.com/rds/postgresql/) 用于长期数据存储和批量对账

图 3 – 价格记录与对账
**采用多线程处理实现高吞吐量**
由于市场数据量巨大,所有可行的组件路径都采用了多线程处理 (multi-threading processing)。为了进一步减少因实例特定网络带宽限制而导致的节点间网络数据包丢失,我们在每个实例的不同端口上建立了多个 TCP 连接,作为并行发送数据流的优化策略。
这种多线程方法的一个挑战是维持正确的订单处理顺序。例如,如果证券 XYZ 在一秒内更新两次——M1 (价格变为 100) 和 M2 (价格变为 101)——在多线程环境中先处理 M2 再处理 M1 可能是灾难性的。为了处理顺序问题,我们开发了一个自定义的时间顺序组件,并将其置于数据呈现给用户视图之前的路径中。

图 4 – 按时间顺序排列数据
**大规模管理 WebSocket 连接**
WebSocket 技术实现了客户端和服务器之间的实时双向通信,使其成为向 Web 和移动界面广播市场数据的理想选择。与传统的 HTTP 请求不同,WebSocket 连接:
- 维持持久连接,减少延迟
- 通过消除重复握手来最小化网络开销
- 支持服务器推送更新,这对于实时市场数据交付至关重要
- 与基于轮询的方法相比,可减少服务器负载
SMC 在其 Web 和移动应用界面上实现了运行在 ECS 集群上的 WebSocket 连接,以利用这些优势。然而,大规模运营基于 WebSocket 的系统也带来了独特的挑战:
1. 连接管理挑战
建立连接后,WebSocket 客户端会与特定的服务器实例保持持久连接。这给传统的负载均衡方法带来了复杂性,尤其是在 Amazon ECS 扩展事件期间,因为现有连接由于其状态性而无法轻易地重新分配到新实例。
2. WebSocket 惊群效应挑战
在交易时段,成千上万的交易员会同时尝试建立 WebSocket 连接,尤其是在开市或系统维护后。这种“惊群效应 (thundering herd)”会使服务器不堪重负,并导致连接失败。此外,当容器在扩展事件中被替换时,多个客户端同时尝试重新连接也会给系统带来类似的压力。
为了应对这些挑战,我们实施了一套全面的连接管理策略。这包括通过 [自定义 Amazon CloudWatch 警报](https://docs.aws.amazon.com/managedservices/latest/userguide/custom-cloudwatch-events.html) 实现基于连接的扩展,以及使用 [指数退避和抖动 (exponential backoff and jitter)](https://aws.amazon.com/blogs/architecture/exponential-backoff-and-jitter/) 来错开客户端的重新连接。为了实现长期可扩展性,团队还评估了其他方法,例如使用 [ElastiCache](https://aws.amazon.com/elasticache/redis/) 进行外部状态管理,以存储连接状态,实现客户端在容器间的无缝过渡,以及采用有控制间隔的 [渐进式扩展 (progressive scaling)](https://aws.amazon.com/blogs/containers/scale-your-amazon-ecs-using-different-aws-native-services/) 来防止连接激增。
**生产环境的弹性和可观测性**
为确保广播系统的可靠性,SMC 使用 LGTM 技术栈实现了一套自定义工具,用于全面的监控和可观测性 (observability),该技术栈结合了四个关键工具:用于日志的 [Loki](https://grafana.com/oss/loki/)、用于可视化的 [Grafana](https://grafana.com/docs/grafana/latest/panels-visualizations/visualizations/)、用于追踪的 [Tempo](https://grafana.com/oss/tempo/) 和用于指标的 [Mimir](https://grafana.com/oss/mimir/)。这与一个使用 [AWS Systems Manager Incident Manager](https://docs.aws.amazon.com/incident-manager/latest/userguide/what-is-incident-manager.html) 的集中式事件通知和管理系统集成,以快速缓解和恢复影响托管在 AWS 上应用程序的事件。

图 5 – 集成的 Incident Manager
### **解决方案架构**
以下高级参考架构展示了 SMC 如何部署其广播平台。AWS Transit Gateway 在此架构中扮演着关键角色,作为一个云路由器 (cloud router),它简化了网络拓扑,同时实现了跨多个 VPC 的组播 (Multicast) 路由。它集中了 VPC 和本地网络之间的连接,同时支持高带宽、低延迟的连接。
使用 AWS Transit Gateway 使 SMC 能够在添加新的 VPC 或本地位置时扩展其网络,跨所有连接的网络实施一致的网络策略,并减少连接多个 VPC 和本地网络所需的连接点数量。
SMC 使用 Fortinet 防火墙通过 Amazon VPC 内的 GRE 隧道接收组播 (Multicast) 数据。他们将其 FortiGate SD-WAN Hub 与 AWS Transit Gateway 集成,以在本地和 AWS 环境之间建立安全、高性能的连接,实现组播 (Multicast) 市场数据源在多个 VPC 之间的高效分发,简化复杂网络架构的管理,并减少管理多 VPC 网络的运营开销。
如何配置 [FortiGate SD-WAN](https://docs.fortinet.com/document/fortigate/7.4.0/administration-guide/504287/sd-wan-designs-and-architectures) 超出了本文的讨论范围,但完整细节可在此处查看 [here](https://aws.amazon.com/blogs/apn/how-to-quickly-and-securely-connect-to-aws-using-fortinet-sd-wan/)。

图 6 – 广播系统架构
### **解决方案成果**
SMC 在 AWS 上新设计的系统意味着其广播系统现在可以处理数万并发用户。它可以每秒处理来自多个证券交易所的 10 万多条消息,且无停机时间。AWS 允许 SMC 在业务高峰时段扩展其平台以满足增长的业务需求,从而获得更好的性能和更低的延迟 (约 60% 的改进),并在非高峰时段无缝缩减以节省成本。

图 7 – 系统延迟指标
### 结论
SMC 从本地部署到云原生广播平台的历程,展示了金融机构如何通过战略性地采用 AWS 来克服传统基础设施的限制。这一转型需要大胆的架构决策——选择重新构建而非迁移——并证明了通过周密的规划、合适的 AWS 服务以及对现代化的承诺,金融服务公司可以构建既能满足当今苛刻要求,又能为未来机遇扩展的基础设施。
> *在 [SMC Global Securities](https://www.smctradeonline.com/) (以及 [Stoxkart](https://www.stoxkart.com/)),我们与 AWS 的数字化转型之旅显著增强了平台的稳定性、性能和运营敏捷性。从本地迁移到云端,我们不再需要手动扩展、打补丁和升级基础设施——这让我们的团队能够专注于创新。凭借改进的控制、可见性以及在交易高峰时段自动扩展的能力,我们构建了一个富有弹性、面向未来的经纪生态系统,为我们的客户提供了无缝的体验。*
>
> *– Abhishek Chawla (SMC, CTO)*
### 关于作者

### Abhishek Sarolia
Abhishek Sarolia 是 AWS 的一名高级解决方案架构师。他与 AWS 用户合作,通过使用最新的云技术设计安全、高性能和可扩展的解决方案来应对他们的业务挑战。他对技术充满热情,喜欢构建和试验 AI/ML 和 IoT。工作之余,他喜欢旅行、阅读非小说类书籍以及与家人共度时光。

### Abhishek Chawla (特邀作者)
Abhishek Chawla 是 SMC Global Securities 的集团首席产品和技术官 (CPTO),负责领导多个业务部门的技术和产品战略,包括全服务经纪业务 (SMC)、折扣经纪业务 (Stoxkart)、财富和分销业务。Abhishek 在金融科技、教育科技、医疗保健和旅游等领域拥有近二十年的经验,通过基础设施现代化、构建云原生平台和扩展高性能工程团队,成功推动了大规模的数字化转型。他与 CEO 们密切合作,将技术举措与业务目标相结合,通过创新、效率和客户至上的方法实现可衡量的影响。

### Kartik Manimuthu (特邀作者)
Kartik Manimuthu 是 SMC Global Securities 的云工程总监。他怀着通过技术解决复杂业务问题的深厚热情,领导工程团队设计创新且稳健的解决方案,以推动公司的数字化转型。Kartik 专注于云采用、企业基础设施现代化以及构建与业务目标一致的可扩展平台。工作之余,他喜欢探索新技术和阅读。

### Digvijay (特邀作者)
Digvijay 是领先经纪公司 SMC 的工程总监,在过去两年中一直推动技术战略和产品创新。Digvijay 在软件行业拥有超过 10 年的经验,在构建可扩展系统和领导高性能工程团队方面拥有深厚的专业知识。在加入 SMC 之前,Digvijay 曾在微软和 Expedia 担任关键工程职位,为大规模、面向客户的平台做出了贡献。他的领导力将坚实的技术基础与对金融服务领域的敏锐理解相结合。

### Avanish Yadav
Avanish Yadav 是 AWS 的一名高级网络解决方案架构师。他对网络技术充满热情,喜欢创新并帮助用户通过创建安全、可扩展的云架构来解决复杂的技术挑战。当他不与用户合作以提供满足其需求的专业解决方案时,他常常在工作之余打板球。LinkedIn: /avanish-yadav-93b8a947/。
<!-- AI_TASK_END: AI全文翻译 -->