Go在广发证券分布式行情和交易系统的应用和实践

作者简介：罗意，广发证券 IT 中后台系统架构师。2013 年初加入腾讯，主要负责腾讯微博的转发评论的逻辑层和存储层，后期负责微博后台的基础组件研发。2016 年加入广发证券信息技术部，主要负责行情、交易等中后台业务的系统架构设计和研发工作。在高性能、高可用后台系统架构设计方面经验丰富。目前专注于金融 IT 系统、FinTech 等相关技术的应用，关注互联网技术和金融系统的深度融合。

---

目录

1. 证券行情和交易系统服务架构

2. 如何做到高并发、高性能？

3. 如何做到高质量推送？

4. 如何做到高可用、可扩展？

5. 遇到的挑战点

        广发证券是最早在自研系统中使用Go语言的券商之一，我们大概有接近3年的使用经验。现在广发自研的分布式系统以及一些高性能的系统或者对性能优要求的系统，基本上都是用Go实现的。

      我们团队使用Go语言自研的系统有：

      1、行情云系统，要求高性能。

      2、分布式交易中台系统，要求安全、稳定。

      今天主要和大家交流这两个基于Go改造的系统。

证券行情和交易系统的特点

• 行情用户连接并发峰值高

• 行情数据时效性要求高

• 行情数据推送流量大

• 行情指标计算量大

• 安全、稳定、快速

行情和交易系统有各自的特点：

  1、行情用户连接并发数高。9点到11点半开盘期间，用户在线时间比较长，而且是长链接。

  2、行情数据时效性要求高。用户要求我们的行情数据更新速度要尽量快，来自于交易所（深交所、上交所）的行情数据，大概是3秒一个更新数据快照，要求券商系统尽快将交易所的最新行情数据送达用户终端。我们要采用的是行情数据由后台主动推送的方式。

   3、行情数据推送流量大。广发证券作为第一梯队券商有约1800万用户，牛市时最高同时在线约50-80万。一个用户平均订阅自选股约10个，这样同时对外的行情推送量就很大，约200万左右QPS，实际是100万QPS左右。高峰时刻在9点30开盘和13点开盘的那会儿，流量非常大。     

   4、行情数据指标的计算量大。从交易所快照行情数据到行情指标数据，需要经过大量计算工作。以十种K线计算为例，证券数约2W，每天开市4小时，每3秒刷新一次行情，共需计算7.2亿次。再加上实时，分时，市盈率，涨跌幅，委比，委差等十几项指标计算，每日计算量在10亿级别以上。

   5、主管部门对于券商管控比较严。交易系统的安全、稳定就显得非常重要的。虽然我们用互联网思维解决这些问题，但还是需要有适应性来适应券商的环境，不能做得像互联网那么灵活，比如说用户无感升级，比如说扩容，服务器和网络成本。其实针对灵活性、成本、安全、稳定等指标会有一些平衡性的取舍。一旦有一个用户下单没有成功或者下错单了，下单没成功我们系统需要尽快让用户知道是否成功与否，而不应去做重试了，以避免系统下错单。再者就是交易速度要快，在牛市的时候，很多券商下不了单，也就是处理速度和稳定性存在问题的。我们需要在交易速度快的同时也进行过载保护等措施。

1.证券行情和交易系统服务架构



       广发行情云系统从外包转向自研，我们做的事情是改变后台设计架构，以适当高并发、高推送流量的稳定可靠的系统要求。首先，我们对整个行情和交易业务进行梳理拆分：

       一是横向拆分，借鉴于微服务或分布式相关理念来进行业务拆分。依据功能完整、数据同构、职责单一的原则进行横向拆分为实时行情、K线行情、分时行情、分笔行情、板块行情、资金流向、代码链、鉴权服务、交易服务、期权期货、基金债券和Lv2行情。

       二是纵向拆分，依据合理分层，剥离逻辑和存储的原则将行情云系统进行纵向拆分为接入网关、读逻辑层、数据存储层、写逻辑层、行情转码层。将交易系统拆分为接入层、逻辑层、柜台接入层、柜台交易层。

证券行情和交易系统服务架构图

交易系统架构