Nav
大道至简,衍化至繁:证券企业系统高可用运维之道
2019-11-14 发布在 新闻动态

可靠的系统是业务稳定、快速发展的基石,而系统高可用历来是业务正常运行的有力保障。相比于其他金融机构,证券行业具有自身的特点和规律,基于证券行业复杂业务场景下的系统高可用建设既需要准确的技术选型,同时也需要满足业务运行的客观规律。

本文作者东方证券系统运行总部总监殷皓以东方证券的具体实践为例,通过相关技术选型、业务场景应用详细阐述了证券行业复杂业务场景系统高可用建设的具体实践和发展思路。

一、证券行业的行业属性

证券行业首先是处于证监会的监管之下,所以有很强的监管要求。证监会明确指出“市场发展越快,就越要严格监管”,因此证券行业面临“依法监管、从严监管、全面监管”的监管环境。为了指导行业会员信息系统建设,证监会发布了大量信息技术管理办法与行业标准,规定了业务连续性的具体要求,每年灾备能力、演练次数要有具体的报告和指标,备份能力指标等,并且定期对这些内容进行巡视与审计。

除了行业监管之外,行业本身发展也为证券企业带来了内部要求的压力。随着证券市场的规范化和创新步伐的加快,业务系统逐渐增加,以东方证券为例,现在每年都有50套以上新增的系统,这些新增的系统对运维能力提出了更高的安全要求和技术要求。因此摆在我们面前的重要问题,就是如何根据行业及自身特点,能够更好的创建自身的高可用能力,进而满足这些需求。

不同于其他行业的,证券行业的信息系统运维特点主要包括:

第一、较长的可变更窗口

证券行业7x24小时不间断运行的系统目前在逐渐演化和增加,但总体数量并不是很多,工作日休市期以及周末的48小时的存在,使得证券行业有一个较长的可变更窗口。

第二、测试频繁并且习惯于用生产环境直接参测

由于有了较长的变更窗口,对于业务的测试也就可以更加的频繁,并且经常是将核心系统的主生产环境直接投入测试。各交易所也经常以通关、联调的名义要求会员单位必须以生产环境进行新业务的测试验证工作。主生产的参测导致了大量的回退操作,这些回退操作对高可用系统带来了破坏性作用,运维人员疲于应对高可用系统的修复与重建工作,这对高可用系统的技术选型有非常大的影响性因素。以东方证券为例,每年高可用系统的重建达上百次,是银行业的数倍。

第三、人员精简

随着相关新技术的应用,运维已经从分散运营、到集中运营再到智慧运营,运维人员的学习主动性要求和成本越来越高,这也导致人员进一步精简,每个岗位需要担负的责任也更大。

二、高可用技术选型

基于以上的特点,在高可用技术选型上,也就需要更加慎重。我们从分析一般系统的基本架构入手,大部分系统可分解为接入层、应用层、数据层和硬件层。除数据层外大部分层次是无状态信息的,高可用建设比较简单,组件之间功能等价,无数据交换,冗余部署即可解决大部分问题。数据层则不同,大部分系统在收束到数据层后,里面储存有状态信息,必须采用专业的高可用技术才能保持业务的连续性。

从技术视角分类的话,我们认为数据层的高可用技术有可以分为四个流派。

首先是数据库源生的日志重放技术。由于数据库的内部机制是先写日志再提交事务,可以通过将日志传到备份系统,主备两边同步或异步执行日志内容,实现系统的高可用。采用这个方案的优点是功能由数据库源生提供,准确度有保障,效率相对较高。缺点是不支持异构数据库之间的高可用。不同的数据库产品有针对自家产品的不同的实现方案,但是基本上都是同源同类的。

而在不同数据库之间,就只能采取第三方方案来做了,这就是第二类流派日志解析回放技术。比如英方软件的i2Active,它的原理也是基于数据库先写日志再提交事务机制,只是不可避免的有一个处理流程串在里面存在的,首先是想办法获得日志的,通过api接口抓日志,再将二进制日志解析成可读取的字符,重新封装成自己的格式,再分发出去,在目标端提交事务。

这种方案的优点就是支持异构数据库,并且目标端选择非常多,不仅可以入库还可以做文件,或者直接对接消息中间件kafka等。缺点是准确性依赖厂商的日志解析能力,长流程串导致效率一般。

第三种流派,则是通过第三方文件系统同步方案。在早期数据库版本还没有提供日志重放功能时,硬件存储复制是应用较多的的高可用方案,即将本机存储空间通过硬件层传输过去。其局限性是会硬件绑定,并且投入非常高。

不过随着相关软件方案的出现,逐渐解决了这个问题,比如英方的i2COOPY,它就是模拟了硬件操作技术,通过在操作系统层安装一个代理程序捕获I/O操作,通过网络将I/O操作传输出去实现与存储复制类似的功能。它的优点主要是和应用无关,非常贴近于底层,可以同步一个库,也可以同步一个文件;既可以做应用高可用也可以做数据库高可用。

第四种方案则是像Hadoop大数据平台、mpp架构数据仓库、分布式newsql数据库等系统,他们提供的是整体解决方案,并不是某一项具体技术,是由一大堆技术搭建起来的。优点是是自带高可用功能,当然,也存在诸如体量大、成本高(无法用单套小系统去做分布式实践)等缺点。

三、场景应用

每一种技术的选择,都需要考虑到具体的应用场景。我们结合证券行业频繁测试的背景将高可用场景分为:结构简单但是由于数量多导致的复杂场景和由于多系统业务关联导致的复杂场景两大类。

前面我们从技术视角出发把高可用技术分为4类。现在我们站在运维的视角,把高可用技术重新分类为2类:需要维护和无需维护。如果把高可用比做一个大厦的话,那么建造这个大厦就需要两种基石。一种是“白石”,是透明的,需要进行维护,它的创建和运维都是需要初始化的,运行过程当中需要监控,应用系统的变更可能导致白石损坏;另一种是“黑石”,无需维护,比如说做文件系统复制,因为跟应用系统是无关的,搭建好之后应用系统的变更不会对其产生影响。

在搭建的过程中会有两个基本原则:第一,选择黑石、白石两条腿走路。不管是文件系统复制还是数据库复制,都有可能出现的问题,所以需要在建设过程中要选择两条腿走路;第二,业务需求优先。虽然白石越多需要维护的量就越大,黑石越多维护量越小,这个一定要优先满足业务场景的需求。黑石场景的一个缺点是目标端是不可用的状态,如果业务要求做读写分离,要去查询一些数据,这时候白石、黑石比例要优先满足业务要求,再去想怎么在满足业务前提下简化体系和工作量。

黑石有什么好处呢?黑石技术相对比较单一,我们可以统一管理,可以通过简单平台把300多套黑石方案进行监管。白石则不同,各种技术方案的具体实现差异极大,现在没有什么监控体系可以把多种白石技术合在一起进行统一运维。

举一个多系统的复杂架构例子。场外交易平台本身是一个大的主库,同时承担了账户、交易和经管,由于负载分流的需要,按功能拆分,把账户和交易剥离出来成为了2个独立的子系统,同时要实时管控和分析,数据还要写回经管库做清算。

纵向来看,每一个子系统都有读写分离的要求,所以采用了数据库同步的方案。横向来看账户和交易还要将数据实时写回到经管库上,在经管库上做实时报表和分析,经管库自己还是要做读写分离的,这就是一个“五白一黑”组成的高可用架构。这套系统在证券行业主生产环境参测的背景下,每次参测后都要重建5套白石高可用。我们要对这种系统进行优化,降低它的复杂度。比如说因为交易和账户在经管库上是有全量数据的,所以对其查询负载是可以放在经管库上去做。经过改造之后,原来的“五白一黑”的架构就变成了“三白三黑”的架构,这样运维量就大大降低了。

这里还有一个高可用系统建设衍生出的副产物,在高可用技术当中采用了黑石架构,它是一个不可读不可写的状态,目标端资源是闲置浪费的状态。因此要尽量减少资源浪费,就是可以把多个系统的黑石同步数据汇总到一台存储上的共用存储空间,这有两个场景:第一,测试数据快速交付。过去老的方法,比如说托管系统要测试要最新的数据,首先托管系统要等待备份窗口需数小时不等,备份本身2小时,在脱敏服务器上恢复数据要2小时,脱敏要1小时,脱敏后数据再备份2小时,再把数据通过特殊网络拷贝测试环境里面去,恢复再要2小时。

基本上要交付一套测试数据,周期在7到8小时以上。新的方法是当开发提出要测试数据时,可以对已经存在的托管的黑石数据进行存储快照,把它挂在脱敏服务器上直接脱敏,脱敏之后可以通过存储的卸载、挂载放到规定的测试机上,这样就从七八个小时压缩到了一个小时了;第二,这种架构也可以对接云管平台,在启用灾备时动态划分资源,实现动态资源灾备的作用。

四、大道至简,衍化至繁

总体来说,高可用的运营转型经历了四个阶段。第一阶段是手工执行命令;第二阶段是标准化,把一些常用的东西固化下来形式脚本;第三阶段借用自动化运维平台通过流程系统把前面做好的脚本串联起来,实现一个工作自动化;第四阶段目标则是实现运维的智能化。

自动化运维和智能运维的差别主要在决策形成机制方面。自动化运维一般是定时重复性的,或者流程驱动,事件驱动。运维动作的发起大多还是要依靠人。智能运维希望能减少人工干预。为了实现智能化,东方证券已经在做基础平台的准备。建好基于zabbix的统一监控平台和运维大数据分析平台,这些平台和前面的自动化运维平台是基础。

目前的自动化运维平台更多是一个执行机构,统一监控平台提供实时状态信息,后面的运维大数据分析平台提供历史经验、学习分析,这些平台综合在一起才能真正实现智能分析决策,并且真正实现向自动、智能演变的过程。

这里引用老子在道德经中的一句话:“大道至简,衍化至繁”,再复杂的体系也是由简单系统堆砌起来的。所以,在规划建设运维系统时一个有效的工作方法论是把复杂的事物进行分解、归纳、合并同类项,最后实现一个从简到繁再到简的变化过程。