微众银行式“去IOE” 采访微众银行马智涛

原标题：专访微众银行首席信息官马智涛： 微众银行式“去IOE”见习记者  黄杰  深圳报道马智涛有种如释重负的感觉。一年前，他还在顺丰速运时，在一次饭局上朋友说起微众银行，他想到的是一张白纸，以及一个百年难遇的机会

原标题：专访微众银行首席信息官马智涛： 微众银行式“去IOE”

见习记者  黄杰  深圳报道

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

一年前，他还在顺丰速运时，在一次饭局上朋友说起微众银行，他想到的是一张白纸，以及一个百年难遇的机会。而此刻，他的身份已经是微众银行首席信息官（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的科技输出将是一片蓝海。马智涛的思考是，微众银行可以在直销渠道和科技能力上帮助新型银行，类似于微众此前与银银平台的关系，新型银行快速开展业务，微众可以作为服务提供方帮助中小银行快速开展业务。

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

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

（编辑赵萍，如有任何建议及线索，请联系邮箱：[email protected]）