广发证券副总经理/首席架构师 梁启鸿——泛前端、交易云与金融电商-传统券商的互联网技术之路

ArchSummit全球架构师峰会是InfoQ中国团队推出的面向高端技术管理者、架构师的技术大会,参会者中超过50%拥有8年以上的工作经验。ArchSummit秉承“侧重业务场景,引领技术趋势”的原则,展示新技术在行业应用中的最新实践,技术在企业转型中的加速作用,帮助企业技术管理者、CTO、架构师做好技术选型、技术团队组建与管理,并确立技术对于产品和业务的关键作用。

3. 泛前端、交易云与金融电商 - 传统券商的互联网技术之路 梁启鸿 董事总经理 首席架构师 广发证券 IT
4. 本土证券行业软件技术的悖论 IT技术落后 本质追求技术创新 • 券商几乎没有严格意义上的软件R&D(研发) • 华尔街是最追逐前沿技术的地方乊一 • 行业开发工程师人员占比枀低 • 枀速交易、量化交易、高频交易、实时风 • 一切围绕关系型数据库(RDBMS)、戒者 索性说Oracle为核心的技术系统 控对技术性能的枀致追求 • 软件系统可靠性、高可用性、快速扩容能 • 基亍封闭技术的第三方中间件(技术古老、 理念落后) 力要求超越绝大部分其他行业 • 业务创新100%依赖IT – 新一代金融机极 • Oracle+J2EE是部分工程师对技术丑界的全 部想象 就是IT机极、大数据公司、于服务提供者 • 可是… • 语言:C/C++、Java、Stored Procedure、 shell script • “亏联网业务就是建网站” • “什么叫用户体验?”
5. 我们 - 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的践行者
6. “去IOE” – 广发新金融技术Stack  “亏联网规模”(Internet-scale)要求成本可控的大 规模分布式系统部署  “亏联网金融”:既然在亏联网上,就要采用亏联网基 因的技术  财新网2014年6月16日周刊捅破了“去IOE”窗户纸  “由技术转换、商业变迁和信息安全担忧共同驱劢的大 裂变正在发生”
7. 我们干了什么 广发证券互联网创新2年回顾
8. 平台数据 6,000,000 手机证券总用户超600万 5月份 单月新增用户超70万 Platform DATA $100亿—500亿 $ 7,000万 易淘金电商平台,2014年产 品年销量过100亿,15年目 标500亿 创造的产品二级 转让市场“淘金市场” 单日转让记录突破 7000万 600 73.6 万万 总用户数 5月份单月 增长用户数 17.6 46.5 亿亿 7月8日 2015年4月份 单日销量 销量 728 3万 4.17单日 完成转让 8.2 亿 5月份 完成转让
9. 金融电商类 – 易淘金平台、淘金市场、理财账户 100亿上线10个月达到 500亿2015年预期超过 4 月 份销量近50亿、单日销售量超过15亿 单日转让记录7200万
10. 社会化平台类 – 证券界“网店”、“嘀嘀打车”、“社交晒股” apps (屏幕图片均为真实App截图)
11. 泛交易终端类 – 手机交易、页面交易、客户端交易 证券界的 “手游” “页游” “端 游” (屏幕图片均为真实App截 图)
12. 经营驾驶舱APP 电商运营数据随时随地一手掌控 (屏幕图片均为真实App截图)
13. 云计算类 – Open Trading 交易云  FIX国际标准协议  C、Python、Go、 Java语言SDK  极速接入  券商唯一交易云平台  打造金融业的开发者社区  “API经济”  对接互联网合作伙伴  服务传统DMA客户  仿真交易平台开放给一切 量化交易开发者
14. 广发证券互联网金融技术体系全景 易 淘 金 Web 网 上 营业厅 淘金市场 理 财 App 开户 广发网 微信服务号 广发通 OAuth2 云存储(视频 图片语音日志 上 传 ) 服务 广发必答 理财网店 网店卖家端 (微信入口) 运营监控 1600+金 钥 App 匙 投 顾咨询 服务入口 全民晒股 多 渠 道消息 推送服务 异 步 聊 天与 社交服务 自选股云 同步服务 其他服务 封装柜台 系 列封服装务柜 台 系 列封服装务柜 台 系 列封服装务柜 台 系列服务 客户画像 理财系列 CRM 服务 电商系列 合规风控 服务 其他中台 运营管理数 服务 据监控服务 微服务注册 手机证券 页面交易 交易插件 市场 开发者社区 PC/Mac交 易 第三方交易 终端 DMA (直通交 易) 动 态 路由接 入服务 API gateway (流控) 行 情 云服务 资讯云服务 微 服 务 发现 微服务集群 容器管理与 协同 泛终端/入口 云端/Edge Micro Services 日志服务 大 数 据 集群 流 计 算 集群 搜 索 引 擎集群 Data Super Highway 交易总线 交易中 间件 交易中 间件 交易中 间件 中间件/大数据 电商理财体系 交易柜台 互联网金 融柜台 社会化金融体系 交易技术体系 第三方集中 交易系统 自研发内存 交易系统 交易平台
15. 金融电商背后的技 术MEAN Stack + Micro Services + 大数 据
16. MEAN Stack + Ionic JavaScri pt 全栈• MongoDB、Express、AngularJS、Node.js – JavaScript • 服务器端 • PHP? 我们不是它的粉丝 • Java?太Verbose的语言,JSON和POJO还要来回转换 • 我们喜欢Node.js – 事件驱动、异步编程、高幵发、与客户端语言 及数据对象同构 • 数据存储 • MongoDB – JSON格式存储中间结果、灵活、不仅是简单的缓存 (复杂查询、Aggregator、MapReduce) • 无传统“SQL注入”类攻击之虞;采用最佳实践防范“服务器端 JavaScript注入”攻击 • AngularJS - 依赖注入、双向绑定、强大开源社区支持 • Ionic + AngularJS 支持 “移动先行” 策略 • ES6 Now with Babel Express.js
17. “全栈同构” - 解决符合中国国情的浏览器兼容性问题 - 优化“互联网最后一公里”的SPA下载 - 支持搜索引擎索引 - 移动端:AngularJS + Ionic - Web端: - Koa + Flux + React? - Meteor? - Derby、Rendr、Flatiron„ ?
18. 实践 • 我们喜欢的 • 让我们掉坑里的 – 模型设计简单灵活 – 符合电商 – 金融数据要求严谨,schema- 产品数据模型EAV/稀疏矩阵的 less的数据库迫使应用程序贯彻 特点 的强数据类型的schema(幵丐 – 原生支持数据集复制与分片, 实现高可用和分片技术架极相 对简单直接 保证多个应用程序遵循),增 加应用程序负担 – 2.x版本里锁的粒度太粗,一个 – 天然符合“全栈同极”技术体 系 – 一些小特性比较实用。例如TTL 索引,GEO索引等 – 内置GridFS,是一个不错的分 注意 布式文件系统 数据集忘记加索引,导致整个 数据库巨大性能问题 – 查询不够灵活,对亍稍微复杂 的查询一般都需要用到mapreduce、aggregate才可以满 足 – 3.0以前,批量删除性能比较 1、日常运维的时候,要经常留意日志。找出那些耗时比较长的语句,进行优化,否 则可能导致整个数据库不可用 2、默认是不启用用户认证,生产中的机器需要注意 3、在适当的场合,最好在应用层进行建模。过于灵活的代价可能是难以维护,特别 是核心的业务。 差;由亍每个文档都保存字段 名,大多数情况,占用的空间 比关系型数据库都要大
19. Micro Services Architecture – 金融服务中后台“救星” • 券商传统系统(legacy)支持互联网业务 时,需封装各种服务(Request/Response、 Pub/Sub) • 绝大部分封装服务只考虑提供“接口”以对 接Web层,简单粗暴 • 传统系统本身的架构设计不是为高并发的互 联网应用特点而设计,几乎无法优化扩容 • 服务数量巨大无法管理 • 历史遗留系统由五花八门的语言写成 • Polyglot(混合编程) • Hybrid Persistence(混合存储),“加厚”服 务层,缓冲对旧系统压力 • 大量服务通过统一服务注册、服务发现机制来 管理 • 利用健壮性(Resiliency)架构范式 (Architecture Patterns)提高分布式架构下 服务依赖、调用的健壮性 • 利用“容器化”获得水平扩容、部署自动化能 力 • 平台Performance Metrics监控 Consumer-driven contract test API Doc & Pub Service Discovery Service framework Resiliency Async event-driven programming Container + Orchestration Pact、Pact-jvm Swagger.io Consul Curator DropWizard Netflix Hystrix ReactiveX Slate SmartStack Spring Boot Spring Cloud Etcd Docker + Kubernetes + Mesos + Open vswitch/Weave + Terraform
20. 广发电商中后台微服务API
21. • Bl ueprint deployment wi th Terraform • Conti nuous I n te gration wi th Ma ven + Jenkins event GGataetwewayaysesrevrivciece • Loa d-Balancing • Dyna mic Configuration • Ba ndwidth Control • Wi l dcard Domains • Ba ck-end Health check service1 Hystrix commands Service discoveryby DNS lookup service2 业务逻辑 Hystrix DropWizard/Spring Boot Docker CoCnosnuslul Watch CoCnosnuslul Watch Cons ul event bus/Notification Service CoCnosnuslul • Servi ce registry/discovery • Loca l DNS service • Cons istent K/V provider • Event dri ven API • Mul ti DC s upport • Event delivery • Rea ctor design patterns • Nea rly real-time feedback Watch CeCnetnsretsarrelavrclivcocienocetnrtorlol • Docker container remote control by docker http APIs • Cons ul a gent remote control by consul http APIs • Servi ce provisioning • Servi ce port management • 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
22. 微服务让券商后台封装服务在互联网链路上“健壮化” 传统模式 互联网并发流量 Web服务器 Edge/应用集成 业务逻辑 业务逻辑 Tomc应at用逻辑 Tomcat Node.js 服务器 业务服务 业务服务 Tomcat 服务器 Node.js 服务器 C API 复杂依赖关系 复杂部署 超时、假死… 业务服务 Tomcat 服务器 Java API CRM 柜台 交易 数据 仓库 产品 中心 其他 微服务模式 互联网并发流量 Varnish/LVS nginx 统一接入 全 栈 同构 Edge Infrastructure as Code C on tainers Horizontally Scaled Hybrid Persistence Resiliency Patterns Partial upgrades 业务逻辑 Hystrix DropWizard Docker CRM 柜台 交易 数据 仓库 产品 中心 其他
23. Micro Services要素 • 框架 – 服务劢态配置(Dynamic Configuration) – 指标监控(Application Metrics) – 仪表板工具支持(Dashboard) – 日志(Logging) – 运维工具箱(Operation tool box) • 健壮性架极范式(Resiliency Patterns) – Circuit Breaker – Intelligent routing – Micro proxy – Control bus – One-time token – Global lock – Leadership election – Distributed sessions – Cluster state – Re-try – Time-out – Fail-fast – More…
24. 广发泛交易终端架构 容器化、依赖注入、DDD
25. 泛终端 – 手机、平板、Web、PC/Mac交易终端 - 证券投资者使用终端的多样性 - 全终端覆盖的开发挑战 - 多终端协同的必要性
26. DDD – 域模型驱动开发 • 挑战 – 非常复杂的业务领域 – 基本业务元素在多终端、多系统的 反复应用 – 新业务基亍相对稳定的基础业务元 素的扩展 – 掌握核心业务知识的工程师很少 • 解决方法 – 用良好的面向对象设计对业务领域 建模(Domain Model) – 广泛采用设计模式(Design Patterns)贯彻“松散耦合”原则 – 既懂技术又懂业务的丏家掌控核心 “域模型” – “域模型”跨语言、跨平台、跨系 统通用 – “域模型”独立可测试、扩展 – 应用层工程师使用域模型开发应用 Domain Model 。。。 Position Trade Order Account Portfolio Security Quote Stock Bond J2ObjC UML/Java A n droid交易app
27. 容器化与依赖注入 Native Container HTML5 APP App logic MVC framework Domain Model Network provider Local store provider Strategy provider Push Notification provider Log provider Network impl Local store impl Strategy impl Push Notification impl Log impl XXXX provider XXXX impl “古代”浏览器 “现代”浏览器 Chrome app Github Electron
28. 同一个HTML5应用在不同容器的性能优化 本地存储 网络连接 协议解码 图形渲染 安全沙箱 消息推送 桌面控制 优化空间 安装方式 低 标准浏览器 浏览器内,小 Chrome Chrome App 浏览器内、indexDB 多种技术选项 Electron Node-webkit Cordova/Crosswalk 操作系统支持的任何技术 不是所有都支持 WebSocket 效率低 可用WebSocket、QUIC 可用WebSocket、QUIC 效率低 可用原生插件 WebSocket、TCP/UDP、 anything 可用C/C++/Java 不一定支持硬件加速 浏览器安全沙箱 Canvas、硬件加速、 Chrome实验扩展 浏览器安全沙箱 Canvas、硬件加速、 Chrome实验扩展 NaCL Canvas、硬件加速 调用操作系统服务 不支持 无 GCM 无 GCM、自定义 Chrome app launcher 自定义、Mac OSX消息中心、 Windows消息中心 操作系统桌面应用 HTML5范围内 页面加载 利用Chrome特性 (SPDY、Pre-render、 QUIC„) 页面加载 除Chrome所有特性外,再 加PNaCL,近原生应用性 能级别 Web store 近原生应用性能级别 安装包、App store 性 能 / 可 扩 展性 高
29. “抓中药”式构建、打包、集成 Domain Model Native Providers UML/Java model GWT JS model J2ObjC Objective-C model N(eOtwbNjoCer)tkworkNe(tJwS)ork (Java) log store Jar npm Maven repo Npm/bower repo xcode CocoaPods specs repo Push notification (Mac) Push notification … (Chrome) Apps – HTML5 SPA或 操作系统原生 安装包 Web IPA APK DM G MSI CRX Jenkins Main “Main” for Node-webkit “Main” for Cordova “Main” for Web Common app logic Container Node-webkit Electron Cordova Web/SPA
30. Open Trading – 广发交易云 行情与交易开放API、开发者社区
31. “API经济” – 云服务打造行业生态圈 手机证券 操盘手 API/FIX 广发交易于 交易总线 交易系统 高频行情 Open Trading Cloud DMA 机极投资客户端 第三方终端 开发者社区 - 机构投资者 - 互联网合作公司 - 工程师里的投资者 - 投资者里的程序员 主要技术 - API Gateway - Time-series Database - 基于PGM组播的消息总线 - Docker+Kubernetes - FIX协议实现 - Java+Go - Dapper-like分布式系统跟 踪技术 - Disruptor - 大量分布式架构设计模式
32. HPC 交易中间件 – Mechanical Sympathy 存储 延迟 DRAM ~65ns MC ~20ns L3 cache ~15ns L2 cache ~3ns L1 cache ~1ns Register <1ns * Martin Thompson QCon SF 2010 数据 交易系统中间件的挑战: - 超低延迟 - 超高并发 - 分片与水平扩容难 - 都是事务型操作 基于Java的分布式系统,比C++开发效率高、相对易维护,也 可以实现HPC – Mechanical Sympathy是关键 • 利用高性能网络技术 • Java Sockets Direct Protocol (SDP) 支持 Infiniband RDMA • Solarfare OpenOnLoad TCP kernel bypassing • ZMQ OpenPGM extension 让我们获得PGM可靠多播 • 正确使用存储 • 传统硬盘读写也可以很快,只要是顺序的(避免随 机访问)- Kafka证明其既不丢失数据又保证高性 能,系统架构简单,非C/C++技术亦可达成 • SSD用于随机访问,大幅提高RDBMS和MongoDB等性能 • 内存与线程管理 • 避免cache hit miss – HPC算法里最大性能损耗 • 慎用多线程锁技术 • Queue作为线程间通讯手段有各种复杂问题,Java里 的Queue还是导致垃圾收集的源头 • GC影响交易系统性能,需要避免或可控
33. 交易总线 - LMAX Disruptor + PGM + 仲裁/排队/去重 RiRnginbugffBeur ffer (插图来自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等实 现消息流水线、排队机、仲裁机、去重
34. 行情指标计算 – 挪计算还是挪数据? 1. 分时(交易价格和交易量在划分到一个小的时间区间得出的连续统计点) 2. K线(5、10、15、30、60分钟、日、周、月、季、年) 3. 分笔(对交易所每笔成交数据的展现) 4. 排行(涨跌幅、开盘价、最新价成交量等等) 5. 其他指标(内外盘、换手率、市盈率等等) 上证 深证 港股 其他 收集器 收集器 收集器 收集器 收集器 Redis大集群 Redis Sentinel + Lua read 上证 上证 深证 。。。 成千上万 g o-routine 成千上万 g o-routine 成千上万 g o-routine 成千上万 g o-routine Redis主/从串联小集群 - Move Compute to Data:Lua在Redis分片内就地计算 - 减少10倍数据交换量 - 单线程Redis内Lua计算导致查询阻塞 - 减少阻塞要加大Redis分片数量 - 资源消耗、数据修正困难、迁移不便 - Move Data to Compute:数据挪到Go服务作计算 - 一个股票对应一个go-routine,大规模并行 - 市场独立不分片 - Redis主从读写分离 - 运维简单、扩展性好、数据故障修复简单
35. (屏幕图片均为真实App截图) 大数据无处不在 优化 /P13N 应用 日志 分析/ 机器学习 大数据
36. 电商业务日志 Agent 电商机器 日志 Agent 交易终端 日志 Agent 用户行为 日志 Agent 交易日志 Agent 交易机器 日志 Agent 中台应用 日志 Agent 任何非结构性数据 Agent 业务数据 业务数据 专用高速网段 专用高速网段 广发数据高速公路(DSH) Bus Node/总线节点 Flume Collector 数据收集器Flume 可Coll靠ecto数r 据收 集传输 Kafka Bus Node/总线节点 数据F收lu集me器CFolullmecetor C数olle据ctor收集器 Flume Collector Bus Node/总线节点 数据F收lu集me器CFolullmecetor C数olle据ctor收集器 Flume Collector 数据同步、转换 ETL jobs Sqoop 大数据集群(Lambda架构) Steam Steam Processor Processor Spark Steam Steam Proc es s or Processor Streaming/流式运算 Real-time views 融合 数据 仓库 Batch views Map Reduce Hadoop ElasticSearch 批处理层 Batch layer 服务层 Serving Layer 实时层 Speed Layer 应用场景 事中风控 策略交易 客户画像 MOT 征信 创新理财产品 智能电商 市场舆情 个性化 智能运维 合规大数据 商业智能BI 后端风控 经营报表 反洗钱
37. DevOPS – 运维工具与理念 “measure anything, measure everything” - Etsy
38. “天量交易” + “互联网化” + “国际化” 的三大挑战 • 亏联网业务的挑戓 – 24x7 – 高幵发 – 部署扩容响应快 • 屡创新高的交易量挑戓 – 更丰富、更复杂金融产品 – 黑天鹅事件频发 – T+0终会来临 • 国际化早晚到来 – 多交易市场 – 24小时滚劢清算 – 停机时间窗口小 行业运维的典型现状  人肉监控、人肉部署  开发者(商)对机器日志的忽(bu)视 (dong)  割裂的监控点,靠人肉挖掘日志恢复 “案发现场”(bug scene)  多数限于硬盘、网络、CPU之类的“硬 指标”监控,缺乏业务语义的应用监控 -发现故障有时晚于客户  扩容能力弱 – 知识结构和财务制度无 法支持弹性设备资源池(云)  系统性能优化往往限于数据库 我们需要 “Operational Intelligence”
39. “不懂运维的架构师不是好程序员” 性能跟踪 基于Google Dapper 论文的低消耗、应 用级透明、分布式 系统跟踪技术内置 于一切 收集+监控+预警 挖掘+分析+预测 Hadoop 日志 Flume/Kafka Spark HBase P redictive/Prescriptive a nalysis Machine Learning  Statsd  Graphite  Cabot  InfluxDB
40. 1 考虑用户体验(浏览器兼容性、SPA下载)+SEO 一张图的总结 2 边缘服务与端技术同构,微服务严谨健壮 融合型设备端 Edge 电商网站 理财App 电商App 社会化金 融App 手机交易 App 平板交易 App 页面交易 PC交易客 户端 Mac交易 客户端 服务器端JS (i.e. Node.js、 Vert.x) 原生JSON存储 (i.e. MongoDB) “全栈同 构” Isomorphic Tech Stacks 聊天社交服务 OAuth 云推送 云同步 云存储 微服务+云 Strong-typed languages 持续集成 局部升级、持续 交付 容器化 健壮性架构范式 容器管理与协同 混合存储 性能监控 3 核心技术引擎支持创新 数据与后台 不怕堵塞的网络 数据公路 实时日志采集 基于实时流式计 算的大型data backbone 机器学习 消息中间件与高 性能运算技术 (HPC) “Divide and conquer”(实 现分治算法)的 Compute Grid
41. developer.gf.com.cn