Go语言在证券期货行情系统中的实践

1 .Go语言在证券期货 行情系统中的实践 金大师 张泽武 

2 . 目录 CONTENTS 项目故事 行情系统 接入服务 

3 .项目故事 l 项目启动 l 团队组建 l 项目计划 

4 . 接入二级平台或交易所的数据 启动 提供高速实时行情数据服务 提供分时、K线、指标等数据服务 开发一套行情系统 接入服务单节点并发10000 最短的时间交付？ 十一假前交付 满足大量并发请求？ 低延时？ 3个月的开发时间 指标、计算服务？ 组建团队 

5 . 团队 有证券、期货从业经验 C++ 组建一个团队 有服务器开发经验 团队的主开发语言？ 自己炒过股的 证券、期货经验？ 服务端开发经验？ 有golang开发经验或喜欢golang的 炒股吗？ 

6 . C++工程师 团队 15.06.09 2年证券C++开发经验 1年证券C++服务端开发经验 15.06.29 C++工程师 3年C++服务端开发经验 无Golang，无证券、期货行情经验 组建一个团队 C++工程师 7年C++开发经验 团队的主开发语言？ 无服务端开发经验 无Golang，无证券、期货行情经验 证券、期货经验？ 服务端开发经验？ 15.08.10 C++工程师 3年游戏C++服务端开发经验 炒股吗？ 无Golang开发经验 

7 . 2015.05 启动 计划 讨论业务框架，确定需求范围，工期 2015.06 组建团队 招人，业务接洽，技术方案、框架准备 2015.07 研发 基础服务开发，数据接入 开发一套行情系统 集成、联调 2015.08 服务集成，联调测试 马上启动 尽快招人 2015.09 预发布 测试、发布 对接数据服务商 开发框架 …… …… 

8 .行情系统 l 行情系统 l 基本要求 l 服务设计 l 框架设计 

9 . 行情 1 需求：上菜场买土豆 2 询价：老板，土豆多少钱一斤？ 3 报价：土豆3块一斤？ 行情是什么？ 4 行情：老板，报价变了通知我一下 合约品种的即时报价 合约品种的历史报价统计 5 并发：好多人同时问老板 合约品种的历史报价的加工处理 6 服务：问完土豆，还有青菜、黄瓜… 

10 .行情服务 快 行情要足够快 的基本要求 响应快，延时低 准 数据不能有偏差 处理要准确 稳 服务要稳定 可用性99.99% 

11 .系统设计 当随着用户规模变大时，系统 并发 的特性要求 应该要具备弹性伸缩能力 一旦出现故障时，系统能否把 容错 故障的影响范围控制在局部， 不影响整体服务 故障 一旦出现故障，且无法控制在 响应 局部时，能不能快速恢复？ 

12 .服务设计 接入 面向客户端 服务 实现高并发、高在线的需求 框架内部服务化， 计算 加工行情数据 使得各模块专注 服务 按特性组织管理数据 于自身的服务定 位，易于实现 采集 从行情源采集数据 服务 异构数据转换为同构数据 

13 . 1 main.go 服务启动器 框架设计 2 Frame 行情应用框架 3 Status 统计库 开发框架化，抽象出基 4 Command 命令框架 本 服 务 进 行 go 库 化 ， 既然快速开发，同时还 5 Dispatcher 调度框架 能统一管理服务 Config 配置库 6 7 utils 工具库 8 基础业务库 

14 . main.go 服务启动 器 1 解耦 utils 基础 Status 统计框 2 对象化/组件化 业务库 工具库 架 Dispat 3 服务化 cher 调 度框架 

15 . 1 协议库 2 第三方数据源go化封装及协议转换库 基础业务库 3 交易日处理库 4 多路行情源竞争库 开发人员可以专注在业 5 分时、K线、逐笔、分价算法库 务需求的开发实现上 其 他 语 言 转 Golang 的 6 指标算法库 技术难度也能大幅降低 7 行情数据压缩算法库 8 数据缓存策略库 9 其他，根据需求增加…… 

16 .接入服务 l 服务设计 l 服务去状态 l 故障恢复 l 负载均衡 l 测试数据 

17 . 解耦业务，与具体业务无关，固化接入服务， 接入服务 保证接入服务在完成交付后，持续稳定 提供服务注册功能，由后端业务服务程序注册 到接入服务，任何业务都可以注册到接入服务 可同时注册多个同一业务的服务程序，并提供多 播策略和多策略负载均衡服务 稳定及时的优质服务 提供业务路由服务，按请求协议中的业务路由 到服务提供者 如何长期保持接入业务稳定？ 提供业务状态寄存服务，自动收录注册成功的 如何保证及时的服务响应？ 业务服务的上下文状态，当服务异常时转发至 正常服务节点用于恢复服务，使客户无感 当服务异常时使客户端无感？ 支持路由策略、多播策略、负载均衡策略的扩展 如何支持新增服务弹性上线？ 

18 .接入服务设计 1 Network 收、发网络模块 2 Process 服务调度模块 转发服务 服务去状态 3 Route 路由模块 故障恢复 4 Service 服务管理模块 负载均衡 策略控制 5 Context 状态寄存模块 6 Command 命令处理模块 

19 .转发服务 业务请求 转发请求 业务 客户端 接入服务 服务 转发结果 返回结果 

20 . 服务去状态 Context Empty Status 业务请求 Context 业务服务 返回结果1 返回结果1 客户端 Status 1 （无状态） … 返回结果n Context Status n 

21 .故障恢复 故障服务 Context Status n 正常服务 

22 . 服务 负载均衡&动态上线 1 服务 … Service 服务 服务列 n Route 更新 路由表 表和负 路由表 载 新增 服务 

23 .策略控制 Route 路由表 命令 策略 Command 客户端 命令模块 Service 服务列表 

24 .测试场景 场景 说明 连接数 能承载的并发client连接数量 接收模块能力 并发接收client数据包数量 接收+发送模块能力（少客户端） 并发接收client数据包，通过路由，再发送到对 应server端；（客户端50以内） 接收+发送模块能力（多客户端） 与上述相比，客户端数量为5000,10000,20000等 接收+发送+回复 并发接收client数据包，通过路由，再发送到对 应server端，server处理并返回，再转发至client 数据延时 延时数据统计 队列 为了测试内部队列数量对性能的影响，做了相 关的测试 本测试使用的数据包大小为200 Byte，在1000mbps网络环境下 

25 .示例 Client Server 

26 . 接收能力 Client 1 接入 服务 场景 1接收，pkg/s 1接收，Mb/s 队列 CPU 内存，MB 延时，s Go ver. 说明 500,000+ 900+ 4&8&16 640/800 80 0 1.4 达到网卡上限 接收能力测试 1.6版本下，CPU 500,000+ 900+ 4&8&16 400/800 80 0 1.6 耗费降低了200 

27 . 转发测试 1 接入 2 Client Server 服务 场景 接收pkg/s 1接收Mb/s 2发送Mb/s 队列 CPU 内存 MB 延时 s Go ver. 说明 接收&发送 250,000+ 400+ 400+ 4&8&16 690/800 50 0 1.6 CPU 达上限* 能力测试 500,000+ 900+ 900+ 24 1300/2400 100 0 1.6 网络达上限* *4核8线程，由于其他服务也会运行于测试服务器上，占据一个线程左右。所以700左右的CPU已经到达到达瓶颈， 此时网络流量为400+，未达到网卡上限。 * 12核24线程机器，网络先到达瓶颈，无内存积压，无延时，数据几乎实时到达服务端。 

28 . 多客户端测试 1 接入 2 Client Server 服务 场景 Client Pkg/s 1接收Mb/s 2发送Mb/s 队列 CPU /800 内存 MB 延时 s Go ver. 说明 5000 10 100 100 8 150 50 - 10000 10 200 200 8 300 100 - 接收发送 10000 20 380 380 8 580 2.4G - 1.6 能力测试 20000 10 360 360 8 580 4G - 10000 25 430 430 8 630 6.3G - CPU 达上限 25000 10 430 430 8 630 7G - CPU 达上限 

29 . 请求应答测试 1 2 接入 Client Server 服务 4 3 1 接收 2发送 3接收 4发送 内存 场景 client server server client 队列 CPU 延时 s Go Ver. 说明 MB Mb/s Mb/s Mb/s Mb/s 接收回复 450+ 450+ 450+ 450+ 24 1300/2400 100 0* 1.6 *达到网卡上限