证券行业已经走在“互联网+”的前列。一是证券行业的用户服务手段已经高度互联网化，截至2014年底，我国证券行业网上交易量占比已经超过90%；二是互联网证券试点工作取得了积极成果，截至2015年5月，已有55家证券公司开展互联网证券业务试点，在证券支付体系、账户体系、移动应用、跨界合作等方面进行了有益探索，互联网对于证券行业的影响正在持续扩大；三是证券行业互联网化基础设施建设取得显著成效，机构间私募产品报价与服务系统、场外证券业务清算机构、场外证券业务备案系统、证券行业支付体系、证券行业云平台、征信体系、证联网等基础设施的筹建和使用，为证券行业的互联网化奠定了发展基础。

2014年可谓证券行业的“互联网化元年”,作为证券行业互联网化的先行者，广发证券通过一系列变革积累了丰富的创新经验。当前，证券行业创新转型进程不断加快，互联网金融的迅速崛起更是加剧了行业竞争和洗牌，也为有实力的券商做大做强提供了历史机遇。作为植根广东的知名证券公司，广发证券始终坚持“创新驱动、转型发展”，围绕券商基础功能建设加快组织创新、业务创新和产品创新，努力打造核心竞争力，也为行业提供了值得借鉴的创新模板。

概述

我们的平台逻辑层次上分为四层结构，分别为：接入控制层、业务前置层、交易总线层、虚拟化/容器化层。每一层我们在技术上都采用基于异步高性能消息流水线的体系结构。平台在架构上支持多开发语言接入，所用的开发语言包括Java、Go、Nodejs、Lua、C++等。

我们从2013年左右开始研究docker的，生产环境从最初的docker-1.3.2用到目前docker-1.10.0，一直在不断增加基于docker的部署。2014年开始尝试在生产环境使用docker，2015年开始大规模使用。

目前我们生产环境使用的docker实例个数：

• 行情云：超过4000个实例，分布在6个IDC机房。目前承载实时并发超过30万，整个行情云每秒的吞吐在1.5Gbps左右, 目前服务客户超过200万。

• 交易云：超过300个实例，主要分布在广州同城中心交易机房。目前承载客户DMA接入，每天的交易请求数在100万以上，每日交易额平均在8亿左右，最高的峰值超过30亿。

为什么要容器化

对传统的垂直行业来讲，Docker也是最近几年才出来的技术，技术理念非常先进，因此采用Docker容器化技术对我们而言需要综合的评估，但是我们为什么要去做呢？首先，从行业现状来说，证券行业一方面量化交易、高频交易、实时风控要求高，其次，行业创新非常多，创新业务也很频繁，另外，监管方面，证监会证监局对我们要求交易事故零容忍，当然，最近几年互联网金融发展非常快，众筹、P2P非常多，再次，天量行情，2014年底到去年，最高一天有两万亿的市场行情，这样的话对我们整个交易系统是非常大的挑战。

我们在业务发展过程中一直团绕我们的就是怎样利用有限的资源去支撑业务创新，真正做到IT引领业务；另一方面，我们和其他大型的互联网公司在资源方面是没有办法比的，所以怎样利用有限的资源支撑业务创新，这些都是我们要考虑的事情。 
在使用容器化技术之前，我们遇到一些比较典型的痛点：

1. 以项目为单位部署系统：一个项目采购一批机器，分别各自部署，每个项目之间的机器相互孤立，做不到资源共享。追成极大资源浪费。
2. 传统的交易系统升级是非常困难的，例如，要升级要有一个后台数据表，因为表的数据量非常大，所以这个升级基本上是只能在周末升级，升级时间要1个或几个小时。
3. 还有交易系统要升级要打补丁，在系统里面升级一个补丁，把补丁放上去，补丁打的越多导致生产环境的系统的版本变得不可维护，不敢随便去做改动或重新部署。
4. 测试环境搭建非常耗时，快速部署非常困难。
5. 系统在大的升级完后基本是不可回退的。
6. 行业乌龙指等黑天鹅事件时有发生，根本的原因就是技术系统实时风控速度达不到业务的要求，冒险把比较耗时的风控去掉。

容器化技术很好的解决了我们上面所遇到的问题，因为采用容器化至少有以下几个方面的好处：

① 轻量的引擎，高效虚拟化 
② 秒级部署，轻松迁移和扩展 
③ 易于移植、弹性伸缩，简单管理 
④ 开始具备一点“云”的能力 
⑤ 让微服务成为可能 
⑥ 标准化的服务器端交付物 
⑦ 向DevOps迈进的重要一步

容器技术与云的落地

1. Docker绝对不是一个虚拟机，而且它也不是干这个事的，我们的理解是Docker其实就是一个进程的替代者。
2. 广义讲，云其实就是一个单机多进程的跨网络多进程的延伸，要实现云肯定要实现对资源对进程进行远程编排跟调度，我们认为这构成云的基础。

举一个简单的监控服务例子，一个基于statsd完备的监控服务需要有influxdb、grafana、statsd三个服务组成，每个服务只是一个单一的功能，单纯的一个服务是不能提供监控服务的，要把它提供成一个服务，肯定要组合起来，所以我们是通过compose文件把三个服务组成一个关系，这样就是一个完整的服务。

1.  influxdb:
2.     image: "docker.gf.com.cn/gfcloud/influxdb:0.9"
3.     ports:
4.        - "8083:8083"
5.        - "8086:8086"
6.     expose:
7.        - "8090"
8.        - "8099"
9.     volumes:
10.       - "/var/monitor/influxdb:/data"
11.    environment:
12.       - "PRE_CREATE_DB=influxdb"
13.       - "ADMIN_USER=root"
14.       - "INFLUXDB_INIT_PWD=root"
15. grafana:
16.    image: "docker.gf.com.cn/gfcloud/grafana"
17.    ports:
18.       - "3000:3000"
19.    volumes:
20.       - "/var/monitor/grafana:/var/lib/grafana"
21. statsd:
22.       image: "docker.gf.com.cn/gfcloud/statsd"
23.       ports:
24.          - "8125:8125/udp"
25.       links:
26.          - "influxdb:influxdb"
27.       volumes:
28.          - "/var/monitor/statsd/log:/var/log"
29.       environment:
30.             - INFLUXDB_HOST=influxdb
31.             - INFLUXDB_PORT=8086
32.             - INFLUXDB=influxdb
33.             - INFLUXDB_USERNAME=root
34.             - INFLUXDB_PASSWORD=root

对于容器编排，可以从以下两个方面理解。

1. 容器编排是跨主机去管理多个集群Container的一种行为，随着Docker的发展，生态圈越来越完善，比较常见的Kubernetes、Mesos + Mathon、Rancher等都属于此类范畴。
2. 容量编排是为了将资源利用率最大化，同时均衡系统因容错需要不断变化的需求。

还有调度，云要落地必须要对资源进行调度，这个其实也不难理解，举个例子，我们每年的春运，铁道局都会对客流很大的路线增加临时列车，以防止出现乘客滞留。对我们应用也是这样的类似情况，比如说我们交易系统的一个登录服务，这个服务现在资源利用比较高，有可能出现瓶颈了，这个时候就要想办法多部署一套登录服务，因此调度的话其实就是要发现一些存在潜在的资源瓶颈的节点，你要想办法调度一下，再拉取一套系统提供服务。

透明部署之应用要感知云

云要落地，对我们的应用也是有要求的，应用一开始设计的时候就要容错，写的应用可以容忍宕机，应用要有可伸缩，尽量做到无状态，能够做到透明部署。

应用服务就像一个乐高玩具，每一个组件都有不同的功能，不管怎么部署，怎么组合，可以把乐高玩具可以组成一个民房，也可以组合成大厦，对乐高玩具的组件来讲，功能是一样的，不管你怎么组合怎么部署，房子也好大厦也好，应用本身是不知道的，所以应用设计的时候也是这样子的，一定不要对部署有任何的要求，所以我们是这样想的，对部署是不能做要求的，这样才符合云的一些要素。

交易云平台的架构

虚拟化部署

我们的目标是把整个平台搭建在私有云上，并在多个IDC复制部署。目前我们尚未实现IaaS，故目前仅是通过虚拟化技术在物理机上构建虚拟机资源层，通过工具把本平台的各部件的部署变成可重复和自动化。另外，对数据分片、服务器负载均衡等做了设计，例如采用一定的consistent hash算法，让例如Redis服务在其底层虚拟机数量一定的情况下，扩展物理机资源达到扩容目的。

如果一个“私有云”是一个部署单元（包含整个平台所有模块、服务）的话，上图则是简略的一览图，我们所有的应用都是基于Docker Container，采用的是最小化的Container，一个服务就一个Container，因此生产环境，在主机服务器上面会跑无数个Container来提供服务，一个Container等同于一个APP提供的服务，我们的Docker通过Rancher开源容器管理平台来管理。

集中与分散部署结合

对于金融行业来说，其业务需求对比其它行业，甚至证券行业对银行、保险等金融行业，都具有更高的要求。主要体现在：

①、高时效性，证券市场瞬息万变，几秒钟的时间差可能导致结果的巨大差异； 
②、高一致性要求，重要数据在不同节点应表现一致性，如客户的资金和委托数据； 
③、高可用性，哪怕是分钟级别的系统服务中断都是不可接受的；

基于以上三点，简单的集中部署方案和传统的分布部署方案均已经不能满足要求，需要集中与分布部署相结合：

重要业务数据集中部署，以实现高一致性要求，如客户的资产信息、委托信息等，客户无论从哪个渠道接入，查看到的所有信息都是一致的。

行情和资讯以及一些静态资源分布部署到离客户最近的互联网接入中心 （IDC），以解决互联网客户“最后一公里”问题。这样可以实现数据的高时效性（如行情数据，这显然是很重要的），有效提升客户使用体验。

多个IDC接入中心具有互备功能，假如其中一个接入中心因为不可抗力导致服务终止，可通过DNS域名切换到其它可用的IDC接入，以保证服务的持续性。

容器技术与云的很好实践

不可变运维

因为有了容器技术，使得我们在管理变更，自动化部署方面有了可能，生产系统随着时间的推移，无论如何服务器都会积攒下许多变更，包括：新应用、升级、配置变更、计划任务，以及问题的修正。有一点是毫无疑问的：配置好的服务器运行时间越长久，它就越有可能处于未知状态。对于前面所述的每次变更，不可变运维将通过重新创建新的容器实例来解决确定服务器状态的问题。这样之前我们提到的升级打补丁的一系列痛点问题都得到很好的解决。

不可变，顾名思义就是一旦创建，便不再修改，以下是我们生产实践在使用Docker容器方面的一些原则：

①、容器一旦实例化后，永不改变 
②、服务的变更（升级，降级，修改配置）都通过重新部署实现 
③、不修改容器的内部

Docker很好实践

①. 除了持久存储外，不用映射外部文件

特别是日志文件，不通过映射外部文件的方式，可以通过flume、kafka等接口把日志数据写入到集中地方。

②.不要使用本地网络

不使用”Host”模式，Host模式会污染宿主机，同时也不符合云计算

③.镜像使用标签，抛弃Latest

生产应用中一律使用Tag来标识应用，不使用Latest，因为使用Latest将无法实现回滚。

④.Build编译应用和Build Image分离

使用专用的编译Docker来编译应用本身，如用Maven、Go、C++的image来编译应用。编译后再把应用通过Dockerfile加到服务Image里面。

⑤.Apt-get安装Package用完即删

如下图的例子，Apt-get在一条命令里面写完，因为Docker是分层存储，如果是在另一个RUN命令里面卸载临时软件包，对Docker的Images的大小减小没有帮助。

⑥.Docker内部不要Daemon

服务在Docker内部不要有守护进程，应用挂掉就让它挂掉。通过外部监控来实现应用重启等操作。

关于：中科研拓

深圳市中科研拓科技有限公司专注提供软件外包、app开发、智能硬件开发、O2O电商平台、手机应用程序、大数据系统、物联网项目等开发外包服务，十年研发经验，上百成功案例，中科院软件外包合作企业。通过IT技术实现创造客户和社会的价值，致力于为用户提供很好的软件解决方案。联系电话400-0316-532，邮箱sales@zhongkerd.com，网址www.zhongkerd.com