泛前端、交易云与金融电商

- 传统券商的互联网技术之路
梁启鸿
董事总经理 | 首席架构师
广发证券 IT
 本土证券行业软件技术的悖论
IT技术落后 本质追求技术创新
• 券商几乎没有严格意义上的软件R&D（研发） • 华尔街是最追逐前沿技术的地方乊一
• 行业开发工程师人员占比枀低 • 枀速交易、量化交易、高频交易、实时风
• 一切围绕关系型数据库（RDBMS）、戒者 控对技术性能的枀致追求
索性说Oracle为核心的技术系统 • 软件系统可靠性、高可用性、快速扩容能
• 基亍封闭技术的第三方中间件（技术古老、 力要求超越绝大部分其他行业
理念落后） • 业务创新100%依赖IT – 新一代金融机极
• Oracle+J2EE是部分工程师对技术丑界的全 就是IT机极、大数据公司、于服务提供者
部想象 • 可是…
• 语言：C/C++、Java、Stored Procedure、
shell script
• “亏联网业务就是建网站”
• “什么叫用户体验？”
 我们 - Next-gen FinTech R&D
 2013年从金融电商平台研发开始
 致力于用最前沿的互联网开源技术，打造创新型 FinTech “Startup”
 互联网技术基因、金融软件深度技术研究
 与IT运维联合支持峰值2500亿日交易
 “Macbook + 函数/脚本语言 + Git” – 工具虽小，体现文化
 “Bleeding Edge”（对于传统金融业而言）：2013年开始大规模采用
AngularJS、Docker、Node.js…
 各种 OO Design Patterns、Architecture Patterns、Cloud Patterns的践行者
“去IOE” – 广发新金融技术Stack
 “亏联网规模”（Internet-scale）要求成本可控的大
规模分布式系统部署
 “亏联网金融”：既然在亏联网上，就要采用亏联网基
因的技术
 财新网2014年6月16日周刊捅破了“去IOE”窗户纸
 “由技术转换、商业变迁和信息安全担忧共同驱劢的大
裂变正在发生”
我们干了什么
广发证券互联网创新2年回顾
 平台数据
Platform DATA

6,000,000 $100亿—500亿 $ 7,000万

手机证券总用户超600万 易淘金电商平台，2014年产 创造的产品二级
5月份 品年销量过100亿，15年目 转让市场“淘金市场”
单月新增用户超70万 标500亿 单日转让记录突破
7000万

600 73.6 17.6 46.5 728 8.2

万 万 亿 亿 3万 亿

总用户数 5月份单月 7月8日 2015年4月份 4.17单日 5月份

增长用户数 单日销量 销量 完成转让 完成转让
金融电商类 – 易淘金平台、淘金市场、理财账户

上线10个月达到 100亿
2015年预期超过 500亿
4月份销量近50亿、单日销售量超过15亿

单日转让记录 7200万
社会化平台类 – 证券界“网店”、“嘀嘀打车”、“社交晒股” apps

（屏幕图片均为真实App截图）
 泛交易终端类 – 手机交易、页面交易、客户端交易

证券界的
“手游”
“页游”
“端
游”

（屏幕图片均为真实App截
图）
经营驾驶舱APP
电商运营数据随时随地一手掌控

（屏幕图片均为真实App截图）
 云计算类 – Open Trading 交易云

 FIX国际标准协议
 C、Python、Go、
Java语言SDK
 极速接入

 券商唯一交易云平台
 打造金融业的开发者社区
 “API经济”
 对接互联网合作伙伴
 服务传统DMA客户
 仿真交易平台开放给一切
量化交易开发者
 广发证券互联网金融技术体系全景

电商理财体系
易淘金Web
网上营业厅 交易柜台
淘金市场
开户 广发通 封装柜台
理财App OAuth2 系列服务
封装柜台
日志服务 互联网金
系列服务
封装柜台 融柜台
微信服务号 云存储（视频 系列服务
封装柜台 大数据集群
广发网
图片语音日志 系列服务
上传）服务 客户画像 流计算集群
理财系列
多渠道消息 CRM 服务 社会化金融体系
广发必答 搜索引擎集群
推送服务 自选股云
网店卖家端 电商系列
理财网店 同步服务 服务 Data Super
合规风控
（微信入口） 运营监控 其他中台 Highway
异步聊天与 服务
1600+金钥 Ap p 运营管理数
社交服务 其他服务
匙投顾咨询 据监控服务
服务入口
全民晒股 微服务注册

微服务发现
交易技术体系
手机证券 交易总线
交易插件 动态路由接 微服务集群
市场 入服务 资讯云服务 容器管理与 第三方集中
页面交易 交易中
开发者社区 API 协同 交易中 交易系统
间件
gateway 间件
PC/Mac交易 DMA （流控）
（直通交 自研发内存
第三方交易 行情云服务 交易中
易） 间件 交易系统
终端

泛终端/入口 云端/Edge Micro Services 中间件/大数据 交易平台

金融电商背后的技
术
MEAN Stack + Micro Services + 大数
据
MEAN Stack + Ionic

• MongoDB、Express、AngularJS、Node.js – 全栈 JavaScript

pt
JavaScri
• 服务器端

• PHP? 我们不是它的粉丝
Express.js
• Java？太Verbose的语言，JSON和POJO还要来回转换

• 我们喜欢Node.js – 事件驱动、异步编程、高幵发、与客户端语言

及数据对象同构

• 数据存储

• MongoDB – JSON格式存储中间结果、灵活、不仅是简单的缓存

（复杂查询、Aggregator、MapReduce）

• 无传统“SQL注入”类攻击之虞；采用最佳实践防范“服务器端

JavaScript注入”攻击

• AngularJS - 依赖注入、双向绑定、强大开源社区支持

• Ionic + AngularJS 支持 “移动先行” 策略

• ES6 Now with Babel

“全栈同构”
- 解决符合中国国情的浏览器兼容性问题
- 优化“互联网最后一公里”的SPA下载
- 支持搜索引擎索引

- 移动端：AngularJS + Ionic
- Web端：
- Koa + Flux + React？
- Meteor？
- Derby、Rendr、Flatiron„ ?
 实践
• 我们喜欢的 • 让我们掉坑里的
– 模型设计简单灵活 – 符合电商 – 金融数据要求严谨，schema-
产品数据模型EAV/稀疏矩阵的 less的数据库迫使应用程序贯彻
特点 的强数据类型的schema（幵丐
– 原生支持数据集复制与分片， 保证多个应用程序遵循），增
实现高可用和分片技术架极相 加应用程序负担
对简单直接 – 2.x版本里锁的粒度太粗，一个
– 天然符合“全栈同极”技术体 数据集忘记加索引，导致整个
系 数据库巨大性能问题
– 一些小特性比较实用。例如TTL – 查询不够灵活，对亍稍微复杂
索引，GEO索引等 的查询一般都需要用到map-
reduce、aggregate才可以满
– 内置GridFS，是一个不错的分
布式文件系统 足
注意
– 3.0以前，批量删除性能比较
1、日常运维的时候，要经常留意日志。找出那些耗时比较长的语句，进行优化，否 差；由亍每个文档都保存字段
则可能导致整个数据库不可用
2、默认是不启用用户认证，生产中的机器需要注意 名，大多数情况，占用的空间
3、在适当的场合，最好在应用层进行建模。过于灵活的代价可能是难以维护，特别 比关系型数据库都要大
是核心的业务。
 Micro Services Architecture – 金融服务中后台“救星”
• 券商传统系统（legacy）支持互联网业务 • Polyglot（混合编程）
时，需封装各种服务（Request/Response、 • Hybrid Persistence（混合存储），“加厚”服
Pub/Sub） 务层，缓冲对旧系统压力
• 绝大部分封装服务只考虑提供“接口”以对 • 大量服务通过统一服务注册、服务发现机制来
接Web层，简单粗暴 管理
• 传统系统本身的架构设计不是为高并发的互 • 利用健壮性（Resiliency）架构范式
联网应用特点而设计，几乎无法优化扩容 （Architecture Patterns）提高分布式架构下
服务依赖、调用的健壮性
• 服务数量巨大无法管理 • 利用“容器化”获得水平扩容、部署自动化能
• 历史遗留系统由五花八门的语言写成 力
• 平台Performance Metrics监控

Consumer-driven Pact、Pact-jvm
contract test
API Doc & Pub Swagger.io Slate

Service Discovery Consul Curator SmartStack Etcd

Service framework DropWizard Spring Boot

Resiliency Netflix Hystrix Spring Cloud

Async event-driven ReactiveX

programming
Container + Docker + Kubernetes + Mesos + Open vswitch/Weave + Terraform
Orchestration
广发电商中后台微服务API
 • Loa d-Balancing
• Dyna mic Configuration
Gateway service • Ba ndwidth Control
Gateway service • Wi l dcard Domains
• Ba ck-end Health check

业务逻辑 Hystrix
DropWizard/Spring Boot

Docker

Hystrix commands
service1 Service discovery by DNS lookup
service2

• Bl ueprint deployment
wi th Terraform • Servi ce registry/discovery
• Conti nuous • Loca l DNS service
Integration Consul Consul • Cons istent K/V provider
wi th Ma ven + Jenkins
event Consul Consul
• Event dri ven API
• Mul ti DC s upport

Watch Watch

• Event delivery
Cons ul event bus/Notification Service • Rea ctor design patterns
• Nea rly real-time feedback

Consul
Consul

Watch
• Docker container remote control by docker http APIs
• Cons ul a gent remote control by consul http APIs
Central control • Servi ce provisioning
Central control • Servi ce port management
service
service • Metri cs collect by Col lectD, StatsD, BreakerBox
• Servi ce dynamic Configuration by consul K/V setting
• Cus tomer event trigger by consul event APIs
• Moni tor and tracking by Graphit/Dapper
 微服务让券商后台封装服务在互联网链路上“健壮化”

传统模式

Edge/应用集成 业务服务
业务服务
数据
Web服务器

Node.js C API CRM

Tomcat 仓库
业务逻辑 服务器 服务器 产品
柜台
业务逻辑
业务服务 中心
Tomcat
应用逻辑 Java
Tomcat 其他
Node.js 复杂依赖关系 Tomcat API 交易
复杂部署
互联网并发流量 服务器 服务器
超时、假死…

微服务模式

Infrastructure as
Code
Varnish/LVS

数据
CRM
仓库
统一接入

Containers
业务逻辑 Hystrix
nginx

全栈同构
Horizontally Scaled 产品
Edge DropWizard 柜台
中心
Hybrid Persistence Docker
交易 其他
Resiliency Patterns
互联网并发流量 Partial upgrades
 Micro Services要素
• 框架 • 健壮性架极范式（Resiliency Patterns）
– 服务劢态配置（Dynamic – Circuit Breaker
Configuration） – Intelligent routing
– 指标监控（Application Metrics） – Micro proxy
– 仪表板工具支持（Dashboard） – Control bus
– 日志（Logging） – One-time token
– 运维工具箱（Operation tool box） – Global lock
– Leadership election
– Distributed sessions
– Cluster state
– Re-try
– Time-out
– Fail-fast
– More…
广发泛交易终端架构
容器化、依赖注入、DDD
泛终端 – 手机、平板、Web、PC/Mac交易终端

- 证券投资者使用终端的多样性
- 全终端覆盖的开发挑战
- 多终端协同的必要性
 DDD – 域模型驱动开发

• 挑战
– 非常复杂的业务领域
– 基本业务元素在多终端、多系统的
反复应用
– 新业务基亍相对稳定的基础业务元 Domain Model
素的扩展
– 掌握核心业务知识的工程师很少 Trade
• 解决方法 。。。
Account
– 用良好的面向对象设计对业务领域
Order
建模（Domain Model）
Position Portfolio
– 广泛采用设计模式（Design
Patterns）贯彻“松散耦合”原则
Security
– 既懂技术又懂业务的丏家掌控核心 Quote
“域模型”
– “域模型”跨语言、跨平台、跨系 Stock Bond
统通用
– “域模型”独立可测试、扩展
– 应用层工程师使用域模型开发应用 UML/Java
J2ObjC Android交易app
 容器化与依赖注入

Native Container
HTML5 APP
App logic

MVC framework

Domain Model

Push
Network Local store Strategy XXXX
Notification Log provider
provider provider provider provider
provider

Push
Local store XXXX
Network impl Strategy impl Notification Log impl
impl impl
impl

“古代”浏览器 “现代”浏览器 Chrome app Github Electron

 同一个HTML5应用在不同容器的性能优化

标准浏览器 Chrome Chrome App Electron

Node-webkit
Cordova/Crosswalk
本地存储 浏览器内，小 浏览器内、indexDB 多种技术选项 操作系统支持的任何技术

网络连接 不是所有都支持 可用WebSocket、QUIC 可用WebSocket、QUIC WebSocket、TCP/UDP、

WebSocket anything
协议解码 效率低 效率低 可用原生插件 可用C/C++/Java

图形渲染 不一定支持硬件加速 Canvas、硬件加速、 Canvas、硬件加速、 Canvas、硬件加速

Chrome实验扩展 Chrome实验扩展
安全沙箱 浏览器安全沙箱 浏览器安全沙箱 NaCL 调用操作系统服务

消息推送 不支持 GCM GCM、自定义 自定义、Mac OSX消息中心、

Windows消息中心
桌面控制 无 无 Chrome app launcher 操作系统桌面应用

优化空间 HTML5范围内 利用Chrome特性 除Chrome所有特性外，再 近原生应用性能级别

（SPDY、Pre-render、 加PNaCL，近原生应用性
QUIC„） 能级别
安装方式 页面加载 页面加载 Web store 安装包、App store

低 性能/可扩展性 高
 “抓中药”式构建、打包、集成
Domain Model Native Providers Main
UML/Java Network “Main” for
Network
model (ObjC) Node-webkit
GWT J2ObjC (JS)
Network
“Main” for
(Java)
Objective-C Cordova
JS model “Main” for
model log
store Web

Jar npm xcode Push Common app

notification logic
(Mac)
Npm/bower CocoaPods Push
Maven repo
repo specs repo notification Container
(Chrome)
…
Node-webkit

Web
Electron
IPA
Apps –
HTML5 SPA或 APK Cordova
操作系统原生 DM Jenkins
安装包 G Web/SPA
MSI

CRX
Open Trading – 广发交易云
行情与交易开放API、开发者社区
 “API经济” – 云服务打造行业生态圈

开发者社区
- 机构投资者
- 互联网合作公司
- 工程师里的投资者
操盘手
- 投资者里的程序员
API/FIX
广发交易于 主要技术
- API Gateway

第三方终端
手机证券

交易总线 - Time-series Database

交易系统
- 基于PGM组播的消息总线
高频行情 - Docker+Kubernetes
Open Trading - FIX协议实现
Cloud
- Java+Go
DMA - Dapper-like分布式系统跟
机极投资客户端 踪技术
- Disruptor
- 大量分布式架构设计模式
 HPC 交易中间件 – Mechanical Sympathy

基于Java的分布式系统，比C++开发效率高、相对易维护，也
可以实现HPC – Mechanical Sympathy是关键
存储 延迟
• 利用高性能网络技术
DRAM ~65ns • Java Sockets Direct Protocol (SDP) 支持
Infiniband RDMA
MC ~20ns
• Solarfare OpenOnLoad TCP kernel bypassing
L3 cache ~15ns
• ZMQ OpenPGM extension 让我们获得PGM可靠多播
L2 cache ~3ns • 正确使用存储

L1 cache ~1ns
• 传统硬盘读写也可以很快，只要是顺序的（避免随
机访问）- Kafka证明其既不丢失数据又保证高性
Register <1ns 能，系统架构简单，非C/C++技术亦可达成
• SSD用于随机访问，大幅提高RDBMS和MongoDB等性能
* Martin Thompson QCon SF 2010 数据
• 内存与线程管理
• 避免cache hit miss – HPC算法里最大性能损耗
交易系统中间件的挑战： • 慎用多线程锁技术
• Queue作为线程间通讯手段有各种复杂问题，Java里
- 超低延迟 的Queue还是导致垃圾收集的源头
- 超高并发 • GC影响交易系统性能，需要避免或可控
- 分片与水平扩容难
- 都是事务型操作
 交易总线 - LMAX Disruptor + PGM + 仲裁/排队/去重

Ring
Ring Buffer
buffer

（插图来自Martin Fowler 关于LMAX Disruptor的文章）

 HPC最大性能挑战之一 Cache hit missed（缓存不命中）由神奇的LMAX

Disruptor解决，单线程无锁、GC可控，避免线程间Queue低效
 交易总线节点高可用、“瞬间切换”由PGM可靠多播同步数据实现

 冗余数据不能报盘到交易所 – 基于Event Sourcing、Competing Consumers、

Leader Election、CQRS、Queue-based load leveling、Pipes-n-filters等实
现消息流水线、排队机、仲裁机、去重
 行情指标计算 – 挪计算还是挪数据？

1. 分时(交易价格和交易量在划分到一个小的时间区间得出的连续统计点）
2. K线(5、10、15、30、60分钟、日、周、月、季、年)
3. 分笔(对交易所每笔成交数据的展现)
4. 排行(涨跌幅、开盘价、最新价成交量等等)
5. 其他指标(内外盘、换手率、市盈率等等)

Redis主/从串联小集群
Redis大集群
收集器
上证 上证
成千上万
go-routine
收集器
深证 上证
成千上万
Redis go-routine
收集器
Sentinel +
港股 Lua 深证
成千上万
收集器 go-routine

其他 收集器 。。。
成千上万
go-routine
read

- Move Compute to Data：Lua在Redis分片内就地计算 - Move Data to Compute：数据挪到Go服务作计算

- 减少10倍数据交换量 - 一个股票对应一个go-routine，大规模并行
- 单线程Redis内Lua计算导致查询阻塞 - 市场独立不分片
- 减少阻塞要加大Redis分片数量 - Redis主从读写分离
- 资源消耗、数据修正困难、迁移不便 - 运维简单、扩展性好、数据故障修复简单
 大数据无处不在
应用

优化
日志
/P13N

分析/
大数据
机器学习

（屏幕图片均为真实App截图）
 广发数据高速公路（DSH） 大数据集群（Lambda架构）

应用场景
Bus Node/总线节点 Steam Steam

实时层 Speed Layer

电商业务日志 Agent Processor Processor
事中风控
Spark
Flume Collector Steam Steam
数据收集器Flume Processor Processor 策略交易
电商机器 Agent Collector
日志 可靠数据收
客户画像
集传输
Kafka Streaming/流式运算
交易终端 MOT
Agent
日志
征信

服务层 Serving Layer

Bus Node/总线节点
用户行为 Real-time
Agent 创新理财产品
日志 views
Flume Collector
数据收集器Flume 融合 数据
仓库 智能电商

专用高速网段
专用高速网段

Collector
数据收集器
交易日志 Agent Flume Batch
Collector views 市场舆情

交易机器 个性化
Agent
日志
Bus Node/总线节点 智能运维

中台应用
日志
Agent Map Reduce 合规大数据
Flume Collector
数据收集器Flume

批处理层 Batch layer

Collector
数据收集器 商业智能BI
Agent
Flume
任何非结构性数据 Collector 后端风控
Hadoop
经营报表
Sqoop
业务数据 数据同步、转换 反洗钱
业务数据 ETL jobs
ElasticSearch
DevOPS – 运维工具与理念
“measure anything, measure everything” - Etsy
 “天量交易” + “互联网化” + “国际化” 的三大挑战

行业运维的典型现状
• 亏联网业务的挑戓
– 24x7  人肉监控、人肉部署
– 高幵发
 开发者（商）对机器日志的忽（bu）视
– 部署扩容响应快 （dong）
• 屡创新高的交易量挑戓
 割裂的监控点，靠人肉挖掘日志恢复
– 更丰富、更复杂金融产品
“案发现场”（bug scene）
– 黑天鹅事件频发
– T+0终会来临  多数限于硬盘、网络、CPU之类的“硬
指标”监控，缺乏业务语义的应用监控
• 国际化早晚到来
-发现故障有时晚于客户
– 多交易市场
– 24小时滚劢清算  扩容能力弱 – 知识结构和财务制度无
法支持弹性设备资源池（云）
– 停机时间窗口小
 系统性能优化往往限于数据库

我们需要 “Operational
Intelligence”
 “不懂运维的架构师不是好程序员”
性能跟踪
收集+监控+预警
基于Google Dapper
论文的低消耗、应
用级透明、分布式
系统跟踪技术内置
于一切

 Statsd
 Graphite
挖掘+分析+预测  Cabot
Hadoop
 InfluxDB
日志 Flume/Kafka Spark HBase

Predictive/Prescriptive
Machine
analysis
Learning
 一张图的总结
1 考虑用户体验（浏览器兼容性、SPA下载）+SEO 2 3 核心技术引擎支持创新
边缘服务与端技术同构，微服务严谨健壮

融合型设备端 Edge 微服务+云 数据与后台

服务器端JS
电商网站 Strong-typed 不怕堵塞的网络
(i.e. Node.js、
languages 数据公路
Vert.x）

理财App
原生JSON存储 持续集成
(i.e. MongoDB) 实时日志采集

电商App 局部升级、持续
交付 基于实时流式计
“全栈同 算的大型data
社会化金 backbone
融App 构” 容器化

手机交易
Isomorphic 机器学习
健壮性架构范式
App Tech
平板交易 Stacks 消息中间件与高
App 性能运算技术
容器管理与协同
（HPC）
聊天社交服务
页面交易 “Divide and
OAuth 混合存储 conquer”（实
现分治算法）的
PC交易客 云推送 Compute Grid
性能监控
户端
云同步
Mac交易
客户端 云存储
developer.gf.com.cn