微众银行CTO马智涛: 微众银行式“去IOE”
来源: 21世纪经济报道
2015-11-05 13:29
分享

马智涛有种如释重负的感觉。

一年前,他还在顺丰速运时,在一次饭局上朋友说起微众银行,他想到的是一张白纸,以及一个百年难遇的机会。而此刻,他的身份已经是微众银行首席信息官(CTO)。

这是整个专访里难得出现的形容词:“如果从一张白纸开始搭建一个银行平台,我们都不敢跳出过去的框框走向"去IOE"这条路,我们的代价不仅仅是自己还有整个行业。这一步是必须走的,只不过不知道是谁来走。”

马智涛的另一段经历是:一些大行在银行IT上想法与微众一致,但囿于传统架构和海量账户迁移风险,难以做去IOE的决策。马智涛了解这种决策的难处,因为早前的十年间,他就在中国平安负责IT,深谙一个没有历史包袱的机会,便成了百年难遇。

为什么要去IOE?

IOE分别指IBM(国际商用机器)、Oracle(甲骨文)和EMC(易安信),三者分别是小型机、数据库和高端存储的领导厂商,他们组成的系统被视为大型金融机构后台的“黄金架构”。

传统金融机构普遍沿用IOE架构,即集中式架构+闭源商用系统。程序基本运行在一、两台主机服务器上,其中一台是备用机。IOE还提供了应用程序以外的所有基础软件,包括操作系统、中间件、数据库等。而这些基础软件的源代码一般都是不公开的。

这些闭源系统的安全性讨论自“斯诺登事件”后被放大。关于银行业去IOE,监管层曾发布《关于应用安全可控信息技术、加强银行业网络安全和信息化建设的指导意见》,意见核心在于自主可控、减少对IOE等厂商的依赖。

“为什么会选择走这条技术路径?事实上对于微众来讲,我们别无选择。”马智涛说。在App推出时,微众银行将自己定位为中国首家“去IOE”银行IT系统。

行业谈到去IOE时,更多被关注的是成本问题。但在马智涛看来,新型银行需要掌握核心技术,这是创新业务和自主可控的前提;另一方面互联网银行海量交易、数据和事件驱动营销的特点,会带来许多突增的业务量,因此需要一个具备灵活伸缩性的平台;回到普惠金融的定位,微众也必须在成本结构上具备优势。

具体到银行IT系统的搭建,这些想法的落地也决定了微众“去IOE”的路径,创新即技术上不能依赖外部厂商,而现成的银行IT解决方案也难以具备微众所要求的伸缩能力,回到成本,IOE架构背后的成本是微众无法承担的。

成本优势如何体现?根据马智涛的测算,通过标准化的硬件及开源软件,微众所能够做到的成本应该是传统银行的十分之一。

“我们的判断是,两千万的账户规模是一个比较重要的节点,超过这个规模,微众银行IT成本架构的优势是非常突出的。”马智涛说。

如何去IOE?

马智涛所说的成本优势,简而言之是通过标准化的硬件和开源软件来实现的。这与传统银行集中式架构+闭源商用系统相反,而是参照互联网企业通常采用的开放式架构。

讲分布式架构之前,马智涛用了一个比方:往一个很大的水杯里加水,当水杯满了,可能要更换一个更大的水杯来把这些水倒到大水杯上去,而微众的做法,是一个一个的小水杯,当一个水杯满了以后,只需要增加水杯,就可以装更多的水。

回到传统银行的IOE架构,在需要扩容的时候,更换计算硬件、数据迁移都是非常复杂的操作,对银行IT系统安全性和稳定性构成极大风险,这也是大行去IOE一大难点。

以银行业务系统和账户体系为例,在传统银行架构下,假设一台服务器能装500万账户,当容量达到500万账户以前,就要换上一台可以装1000万账户的机器,然后把500万账户搬过去。这个过程涉及数据迁移,操作风险高,扩容周期长,成本投入亦不菲。

微众式的去IOE,首先在硬件上,采用大量标准化的硬件,分布式架构决定了用低端设备X86替代IBM的可能性。数据库方面,运行在X86服务器上的数据库TD-SQL(腾讯基于MySQL开源体系下开发的数据库),可实现数十万级IOPS(每秒读写操作次数)的读写能力。

软件方面,微众大量采用了开源技术,如Java、MySQL、Linux、LVS等,以及多个结合腾讯经验改造优化的开源软件,包括TGW、TLinux、TDW等。

互联网银行海量数据、交易,移动支付、同业合作的特点,也决定了分布式架构落地。打散的数据分布一方面实现了海量数据处理能力,不同节点的分布,也带来横向扩展和可伸缩性的可能。

这一IT设计理念,实际上借鉴了早期商业银行按照分行部署业务系统的经验,在微众的实践中升华至“数据分布、管理集中”的整体设计原则。

安全性之考

分布式架构和开源系统决定了微众银行的成本优势,而金融机构的安全性和稳定性要求,是否能沿用互联网公司的IT架构?

这个问题上,传统银行的怀疑恐怕多于想象。而马智涛认为,这是一个误解。打散的数据分布,每个计算节点上承载的数据量和风险已经被大幅度降低,“亿级的数据你可能不敢放在一台低端设备上,但把它们打散到十个、二十个节点后,这些设备的处理能力和稳定性是绰绰有余的。”

传统银行基于安全的考虑,使用两地三中心的容灾体系,通常是一个中心工作、一个备用。而微众的做法是两个同城中心同时运作,此前这两个中心承载的计算量是6∶4,两个星期前微众将其切换为7∶3,验证了其跨中心切换方案行之有效。这种同城多中心多活的架构设计,也是微众银行IT架构满足高可用性要求的基础。。

在马智涛看来,金融IT高可用性的头号杀手是“ 变更”。每次大的功能升级、版本发布,涉及的系统变更都会构成风险,容易导致服务中断。在传统IT集中架构模式下,变更风险往往影响整体。而在分布式IT架构体系下,变更可以在某一节点上测试,再推至整体,规避全局性风险。

IOE体系下另一个问题是,当软硬件出现问题时,不时需要海外专家跟进处理,而这个周期往往会被延长,这对业务影响是巨大的,这也是监管层关注自主可控的主要原因之一。

微众银行开业之初,曾将部分账户托管在兴业银行银银平台之上,在微众银行自身体系搭建起来之前,支持银行的基本资金运作。

这一托管协议的启示是,在民营银行试点扩大,利率市场化下竞争加剧背景中,银行IT的科技输出将是一片蓝海。马智涛的思考是,微众银行可以在直销渠道和科技能力上帮助新型银行,类似于微众此前与银银平台的关系,新型银行快速开展业务,微众可以作为服务提供方帮助中小银行快速开展业务。

如何实现科技输出的标准化?马智涛认为,这种合作并非一次性或阶段性的合作,在微众银行平台上提供的增值服务,包含了数据能力、风控能力、科技能力。

有鉴于此,在建设微众平台之初,一个重要原则是:需要支持多法人部署的云服务模式。微众希望在这种模式下,同业能将业务或应用系统部署在其金融云平台之上。“很多同业跟我们交流,都表现了浓厚的兴趣,希望在技术方面建立合作,这是一个很大的市场。”马智涛说。

分享
名称
成交量
成交利率
1
21190.64万元
10.35%
2
2590.64万元
10.35%
3
21190.64万元
10.35%
4
21190.64万元
10.35%
5
21190.64万元
10.35%
6
21190.64万元
10.35%
7
21190.64万元
10.35%
8
21190.64万元
10.35%
9
21190.64万元
10.35%
10
21190.64万元
10.35%