亚马逊AWS官方博客

海外互联网券商网络参考架构

浏览本文需要约 10 分钟,建议按照章节分段阅读。

前言

随着海外互联网券商国际化的进程, 海外互联网券商对构建全球网络的需求越来越大, 这篇文章借此介绍一下海外互联网券商的网络参考架构。

此文分为几个部分:

  • 第一部分:关于互联网券商海外网络需求的介绍;
  • 第二部分:关于构建全球网络架构;
  • 第三部分:关于几个网络优化场景和参考架构。

1. 海外互联网券商的网络需求

经济全球化的过程中,全球有很多投资者(机构或个人)在不同的证券交易所进行投资美股,港股等作为全球头部的证券交易市场在这个领域就占有很大的比重。为方便这些投资服务,互联网券商以及其合作伙伴会在全球不同市场进行展业并提供数字化服务,参与方包括监管机构、证券交易所、资讯服务商、行情服务商、个人客户、机构客户、市场企业客户等,这些参与方在在展业的过程中会涉及到几个网络的需求:

a. 多地部署,应不同国家地区监管要求,业务系统会部署在不同的国家和地区,多地部署后各地之间网络互通;

b. 交易柜台系统与交易所/Broker 的对接;

c. 交易所/行情供应商的对接;

d. 清算银行对接;

e. 机构服务对接。

这些需求转化为网络的架构设计就演变成了下面几种网络场景:

1. 全球骨干网的设计(同机构不同实体之间)

2. 云上与多个IDC(相同或不同机构)之间的网络设计

3. 同为云上不同机构之间的网络设计

2. 构建全球网络架构设计

以一个在美国,新加坡和香港三地都有业务的券商为例,这家券商需要在新加坡和香港部署业务系统,比如用户、账户管理、订单管理、行情、产品等系统,需要在美国部署 Brokage 和 Clearing 系统,这些系统都已经容器化,并可以部署在容器托管平台 Managed Kubernetes Service – Amazon EKS;三地的网络都互相独立,又能按需互通;这是一个多地多 VPC 的设计,各地还有一个集中化的 ingress 和 egress VPC,专门用来管理站点进出流量。这里推荐一个最优的全球网络设计, 如下图:

这首先得益于一个可扩展的安全的多 VPC 的网络设计,多 VPC 的设计的优势可以参考这篇文章 Building a Scalable and Secure Multi-VPC AWS Network Infrastructure。该文章详细描述了多 VPC 设计的优势,本文就不赘述。多 VPC 设计也是海外互联网券商的常见设计,比如在 RobinHood 的网络设计中可以看到类似设计:

网络设计如何做到更简单却更容易管理,其中就涉及到包括 TGW(Transit Gateway),DXGW(Direct Connect Gateway)两个网络服务,主要也是利用这两个服务来构建跨国企业的全球网络互联的架构

TGWTransit Gateway连接多个 VPC 以及其他的网络,这可以很好的编排同账号或跨账号的 VPC2VPC 以及 IDC2VPC 之间的典型多云&混合云的网络链接及路由,并利用不同的 VPC 来创建安全隔离区/边界以达到网络隔离的目的(TGW 通过控制 VPC 之间的路由来创建隔离区);还支持 Bring Your Own Firewall 的模式来更好的管理南北流向以及东西流向的流量等。TGW 本质是一个高度可扩展的云路由器,不会有因为多个 VPC Peering 而带来的管理上的复杂性,还带来很多优势:

  • 简化架构,以便随其复杂程度的增加而对其进行有效管理。
  • 更好地了解和控制虚拟私有云和边缘连接。
  • 利用区域间对等加密提高 AWS 全球私有网络的安全性。
  • 将本地金融和视频组播应用程序直接迁移到云。

TGW 还可以很方便的接入不同的网络连接, 这可以很好的支持多云&混合云的架构:

比如用 TGW peering 把不同地区的 TGW 配接起来构建全球骨干网,用 VPC attach 接入同一个或不同账号之间的 VPC;可以接 VPN connection 来对接 VPN 网络,可以接入第三方的 Virtual Appliance 设备来对接 SD-WAN 等,并对接 IDC+Other Cloud 以此来构建全球一张网的架构。

DXGW(Direct Connect Gateway)通过标准的以太网光纤电缆将内部网络链接到 AWS Direct Connect PoP点。电缆的一端接到 IDC 的路由器,另一端接到 Direct Connect 路由器。有了这个连接就可以创建虚拟接口直接公有公有访问 Amazon Web Services 的服务(例如到 Amazon S3 或 Amazon VPC)。

另外在券商领域很常见的一点是云与其他云或 IDC 对接,可以通过 DXGW+专线来对接:

如上面架构所示:TGW 一边可通过 TGW 连接不同的 VPC 网络,另一边可以通过专线对接 IDC 或其他云,这使得通过 DXGW 接入的网络也可以通过 TGW 来享有更好的网络互通与管理的能力。

这种设计不仅仅适用互联网券商的网络,也同样适用于互联网券商与交易所之间的网络,甚至在一些知名交易所内部也是使用这种设计,比如 Nasdaq 也是使用 DX GW 把 Amazon Web Services 上的网络与其 IDC 里的网络打通。Nasdaq 还更往前一步,其部署 Outposts 来替代部分 IDC 的计算资源用,甚至把关键任务,低时延的工作负载也部署在 Outposts 上,并用其内部的低延时网络来对接 IDC 资源,如下图所示:

这也给互联网券商或相关参与方(比如数据供应商,量化交易机构等)一个启发,在一些交易所密切相关的低时延要求的场景,可以将 Outposts 部署到交易所机房内来提高基础资源技术栈的一致性(Outposts 是一系列完全托管式解决方案,可为几乎任何本地或边缘站点提供 AWS 基础设施和服务,以获得真正一致的混合云体验:使用熟悉的 AWS 服务、工具和 API 在本地运行应用程序和工作负载);降低与交易所之间的时延(如实时行情获取,高频交易场景等,Outposts 以低延迟访问本地系统、本地数据处理、数据驻留以及具有本地系统相互依赖性的应用程序迁移的工作负载和设备)。

3. 网络优化场景和参考架构

网络优化之 Virtual Private Gateway Association

当然在一些特定的场景,比如在大流量的券商行情推送处理分发的场景(数据流是从行情供应商 IDC 到云上的场景),因为用 TGW 的接入可能会带来一些成本上的增加,可以在一些特定的网段,通过 DXGW 使用 Virtual Private Gateway Association 接入 VPC,这时网络就变成 IDC-DXGW-VPC,从而节省 TGW 的流量费。一般不建议这么设计,因为这种模式一旦接入数量多就会导致网络管理错综复杂而无力改变,建议大部分场景都是通过 TGW 来中转管理。

网络优化之 DXGW SiteLink

如前面所述,大部分互联网券商都会通过专线接入不同的第三方,比如交易所、行情供应商、资讯供应商、企业服务的机构等,而这些机构或者 IDC 之间又可能有相互联通的需求,特别是同一个实体的多个 IDC 之间。这种场景推荐使用 DXGW 的 SiteLink 功能。设计如下图所示:

Before SiteLink 场景:两个 IDC(Customer Data Center 1 和 Customer Data Center 2)的互通,这时候券商当然可以直接拉多一条专线打通两个 IDC 之间的网络(除了与 Amazon Web Services 相连的专线之外);或者在 Amazon Web Services 上用 TGW 来管理不同 IDC 之间的连接;或者直接通过公网对接。这些方案要不就意味着成本会增加(拉多一条专线或 TGW 的流量费,或 DTO 费用),要不就要经过公网带来网络暴露公网的一些安全问题。而使用 SiteLink 后,如在上图所示 After SiteLink 的场景就可以很简单的让数据的流通从一个 DX 接入点到另一个 DX 接入点,中间可以通过 Amazon Web Services 的高速网络而不进入到 Amazon Web Services 的 region 里,节省了 DTO 费用并降低时延。其中通过 TGW 或不通过 TGW 都是支持的,IDC 之间通或者不通都可以控制,可以根据需求来制定设计,更多内容可以参考这里

网络优化之 PrivateLink

现在也有越来越多的金融机构在 Amazon Web Services 上面直接提供服务,当数据的供应商和数据的消费者都同在 Amazon Web Services 的时候,这些机构之间是否还需要拉一条专线来对接网络,还是直接走公网去访问,还是 TGW/VPC peering 来打通呢?

这里有个更好的服务来支持:AWS PrivateLink 可在虚拟私有云(VPC)、支持的 AWS 服务和本地网络之间提供专用连接,不会将流量公开暴露到公共互联网。通过由 PrivateLink 提供支持的接口 VPC 端点,可以访问 AWS 客户,合作伙伴托管的服务以及 AWS Marketplace 中提供的支持解决方案。

以 Bloomberg 为例,其在 B-PIPE 产品里提供了以 PrivateLink 方式接入的方案(Bloomberg Market Data Feed (B-PIPE)):

以 Refinitiv 为例,在 RTO 产品里也提供了 PriviteLink 的接入方式(Refinitiv RTO 更多资料可以参考这里):

除了 Bloomberg 和 Refinitiv,也有越来越多金融机构提供 PrivateLink 的接入方式,这为数据的接入节省了专线的实施时间,降低了成本,降低了时延(甚至可以达到零点几 ms 的级别)。

4. 总结

通过上面简单的例子参考架构,我们可以快速了解到 Amazon Web Services 在互联网券商行业在各种场景下可以提供的网络服务。

此文讲解了如何并且借助 Transit Gateway 接入到不同的 AWS 区域的不同 VPC,利用 AWS Direct Connect Gateway 将本地网络接入到 AWS 的区域,有效解决全球南北流量(IDC2Cloud)的通行,也解决了东西流量(VPC2VPC)的通行,很大程度上减少了管理的复杂度。TGW 是云上的路由器,可以很好支持跨区域的 Peering,方便做路由控制和流量控制,本身也是高可用的来承载非常高的流量,还可以巧妙利用 TGW 和 AWS 的全球骨干网来减少企业网的全球网络部署成本以及 MPLS 上的线路支出。另外也针对互联网券商以及合作伙伴的网络场景,利用一些新的网络功能(SiteLink,PrivateLink 等)让各参与方之间之间可以更好的对接,以满足各种需求。

互联网券商受益于能够访问实时金融/市场数据,以实现更先进的数据消费、生产和分发,给最终用户更快的行情,交易等。Amazon Web Services 辅助互联网券商通过降低复杂性和简化实施,优化基础设施,降低网络时延,也最大限度地提高合规性。有了这些方案,互联网券商可以实施一种可管理的、可扩展的网络来改善运营效率。

5. 参考资料

[1] Building a Scalable and Secure Multi-VPC AWS Network Infrastructure

[2] Transit Gateway

[3] Route Tables in AWS Transit Gateway

[4] 利用 Direct Connect Gateway 和 Transit Gateway 打造跨国企业网络环境

[5] SiteLink Introduction

[6] Hybrid Connectivity

[7] Nasdaq Moving mission-critical low-latency workloads to AWS

[8] RobinHood Network & Network Firewall

[9] Bloomberg B-PIPE

[10] Refinitiv Real-Time-Optimized

本篇作者

何润宁

亚马逊云解决方案架构师,负责云计算方案的咨询与架构设计,同时致力于金融行业的研究。在加入亚马逊云科技之前曾在金融行业 IT 部门负责传统金融系统的现代化改造,对传统应用的改造,对 AI/ML 场景具有丰富经验。