跨境互联网券商架构最佳实践\n

引言

近年来，随着监管层面对金融科技的拥抱态度，券商通过互联网展业的力度日渐加大，越信智能科技核心团队有幸加入两家港美股券商，并负责从0到1建设香港G券商的跨境互联网证券系统。因未有历史包袱，G券商的系统总体架构均为在目前主流技术基础上进行重新选型，包括各端架构、CI/CD及团队协作工具，目前系统已平稳运行半年以上，未发生任何生产事故。后台微服务、移动端组件化、DevOps等在证券金融领域的实践，希望可以给到同行一些启发，更期望能获得一些探讨指点，在思维的碰撞中，完善认知。

正文内容概要：

\n
系统特性\n
技术架构\n
部署架构\n
金融安全\n
核心系统选型\n

系统特性

跨境互联网券商兼具金融、互联网、跨境属性，每个属性对系统有着不同要求。
\n金融属性：跨境券商的金融属性决定系统对合规、安全性及稳定性有较高要求；
\n互联网属性：互联网化运营思维则期望系统的扩展性良好，迭代效率高，以跟上需求的不断变化；
\n跨境属性：系统需提供给多地区用户（大陆及香港地区）访问，要求系统架构选型及部署时考虑版本国际化及跨境访问的问题。

在符合监管规定的前提下，系统围绕安全性、稳定性、易扩展性、国际化四个特性进行设计，考量以下细节：

\n
安全性：终端安全、存储安全、通讯安全、服务安全、数据安全；\n
稳定性：通讯稳定（HTTPDNS，专线），服务稳定（多点部署，网关支持熔断、限流，监控告警），数据稳定（热备）；\n
易扩展：服务分层，横向扩容支持，前后端分离；\n
国际化：多券商、多皮肤、多语言支持，跨境加速。\n

技术架构

没有祖传代码，我们可以比较开放、客观的在目前主流技术上进行选型，充分考量并平衡各技术方案的当下稳定性、生态及未来发展性。下图为我们既定的技术栈架构图：
\n

后台微服务架构

如上图所示，我们基于Spring Cloud进行后台架构设计，服务界限及层次均有一个较好的划分，只允许上层服务依赖下层，不允许出现平级调用或下层服务调用上层服务的情况。万一出现，则是组内讨论，看是否有必要做服务下沉，调整服务层级。

两个注册中心：因为行情服务属于我们之前的沉淀，久经考验，高效稳定，为兼顾业务进度，暂未做注册改造；

两个网关：为提升推送速度及节约跨境带宽成本，行情服务设计成无状态服务，不依赖统一网关，可在全球多站点部署。

移动端组件化架构

在移动端，我们分别基于Swift及Kotlin语言进行组件化设计。
\n除无法替代的三方库尚在使用objc以及java外，业务组件开发均使用新语言编写，Crash明显减少（类型安全的语言特性），代码更加简洁，开发效率变高。

组件化设计则让移动端业务组件彻底解耦，在规范每个组件的代码目录及调用约定后，代码结构非常清晰。不过前期在各个组件间调用上还是花了些时间。

Web前后端分离架构

在Web端我们则采用前后端分离架构，并选择Vue做为主体框架，因为其学习曲线相对较平滑（相比react），国内生态也不错，同时支持移动端H5、PC端开发，可较好的进行前端技术栈的统一。硬广一个小伙伴们利用闲暇时间做的体验一流的移动端H5行情。点此体验。

DevOps

我们使用jira做为敏捷交付的项目管理工具，首个版本上线后，三周左右一个迭代；使用jenkins+gitlab+docker进行docker化持续集成交付，测试环境提交代码则自动发布，生产环境由发布人员确认后一键发布；使用yapi用作我们接口文档及mock server工具，不再依赖后台逻辑编写即可联调；使用gitlab flow统一代码协作规范。
\n有了项目晨会沟通，没有了JAR包上传发布，没有了需依赖后端造数据联调的痛苦，没有了分支管理混乱导致不该上线代码上到生产及频繁的冲突解决，团队协作尽是一片欢声笑语。

部署架构

部署架构设计时考虑要素：

\n
客户跨境访问稳定性；\n
业务扩展性（如将来可能对接境内外地区券商，如境内A股、东南亚）；\n
成本；\n
符合交易所要求。\n

综合考量，最终使用阿里云部署相关服务，架构图如下：

交易所要求

期望自行对接交易所行情或交易的公司需注意，因港交所线路不断升级（如从SDNet/1升级到SDNet/2），会对托管机房本身提出更高要求，有些机房就不一定能满足这些硬性条件了，因此需提前了解清楚交易所的要求，找好对应机房。若不是自行对接，行情柜台供应商选择的机房一般情况下都会符合要求。

业务扩展性

根据规划，核心服务将来可以扩展提供A股、东南亚股市交易功能，且业务重心可能会更偏向境外，因此我们将核心服务均部署在香港阿里云。不过阿里云香港实例比华南区的会稍微贵一些，测试环境部署在境内可节约一些成本。

跨境访问

因国际出口带宽限制，若通过公网进行跨境访问，偶尔还是会出现网络不可达情况，我们在没使用专线的情况下确实碰到过网络问题，使用专线服务后情况有很大改观。
\n特别注意的是：境内访问境外HTTPS站点不稳定，需拉设专线解决。

成本

大型券商的架构中，大部分网络访问是在专线内进行，但对于刚起步的券商，专线成本需考量（10M基本上1万/月），我们仅在大陆跨境访问、柜台连接交易所使用专线，其余部分专线替换为VPN访问，不牺牲安全性的前提下，牺牲部分稳定性，迄今为止网络基本上未出现过问题。

另外专线还是尽量做到多方询价，可以有三种方式搭建专线（直接从网络运营商拉设专线比较实惠）：
\n1、向网络运营商询价并拉设专线；
\n2、向阿里云有合作的供应商询价并拉设专线；
\n3、找系统供应商负责对应的专线拉设，如柜台到阿里云的专线可交由柜台供应商负责。

金融安全

安全的设计是贯穿在整个系统中，从架构设计、代码开发到运维，从用户输入到最终数据落地的整个链条均应考虑安全问题。

重点描述下我们在网络传输过程中的一些安全措施：

网络传输

从以下几个方面保证数据的网络传输安全：

\n
全站HTTPS
\n并非申请一个HTTPS证书就万事大吉，客户端尽量对SSL证书进行严格校验，避免中间人攻击导致用户数据泄漏。\n
敏感数据加密
\n部分敏感的数据我们会在HTTPS之内再进行一层加密，主要采用RSA非对称加密方式，以防范HTTPS证书颁发机构出问题，随意签发证书导致的安全问题。\n
API签名防篡改
\n所有面向终端的接口均要求签名，防止接口数据被恶意篡改。\n

核心系统选型

在证券系统中，交易和行情属核心的业务系统，选择自研还是外部供应商？市场上供应商情况又如何？

交易柜台（港股）

目前市面上的外部供应商可定制化能力普遍较弱，定制化需求排期较慢，拥有自己柜台，相当于有了技术壁垒，因此很多公司有自研柜台的想法。但目前实际自研柜台的券商非常之少（宣称的不算）个人认为主要是两个原因：

业务能力：港股品种众多（除常见的股票、基金外还有窝轮、牛熊证、股指期货、股票挂钩票据等丰富的衍生品），交易规则多样（手数、价格步长不是确定值），支持融资融券业务。考虑的异常（业务异常，如孖展风控预警、牛熊回收、临时休市等）非常之多，对团队的港股业务经验有着较高要求；

成本及周期：业务的复杂度与研发成本、周期正相关，并且考虑到交易所交易权的申请、专线铺设、柜台的MR测试、生产试运行等流程，若可达到正式客户使用，少则1年（有柜台研发经验），上不封顶，小券商基本不会选择这条路。

因公司业务时间限制，我们最终选择对外部供应商进行选型对比，目前市面上头部选手为ayers、iasia、恒生三家，恰好我们基本都有使用过，大概做个总结：

Ayers：简单、易上手，统一版本，定制开发较难，价格相对便宜，适合小客户起步阶段；
\niAsia：大客户较多，系统相对稳定，API相对丰富（英文文档），价格相对较高，适合对系统高可用、高并发有要求和定制化开发要求较多的券商；
\n恒生：最符合中资券商习惯，服务比前面两家好，对港股业务理解暂时没赶上前面两家本土供应商，不过个人认为成长性较好。PS：恒生收购Ayers会有什么影响需自行判断。

行情供应商（港股）

行情系统我们有较好的沉淀，目前已是可支持直接解析港交所数据源，提供实时和延时行情服务，属自研系统。

资讯供应商（港股）

资讯供应商可选较多（如AAStocks、ETNet、天汇等），基本都是以ETL形式接入，所以相对来说看中的是数据的质量，稳定性在可接受范围内即可。

结束语

从0到1建设起一个互联网券商系统大约需1年时间，20人左右团队，800万左右成本，不算是一个小工程。期间遇到的问题繁多，无奈团队实在给力，准时交付且平稳运行。待花开，你们值得拥有更多的美好。亦愿所有读者的2019，美味纷呈，精彩绽放。

作者简介：童军，越信智能科技（深圳）有限公司技术总监。10年以上互联网从业，4年互联网金融、6年管理经验，重点关注互联网金融领域。联系方式：微信keyva33，邮箱tongjun@vstonehk.com。