【案例】穆冬生：邮储银行的全面云化发展之路

原标题：【案例】穆冬生：邮储银行的全面云化发展之路

8月24日，由金科创新社和IBM联合举办的2018新一代金融云平台沙龙在北京止观美术馆举行，本次沙龙的主题是“新架构、新速度、新效能”，三十多位金融行业专家、业内实践者齐聚本次沙龙，就新一代云计算技术容器云及其实施方案和应用等行业热点话题进行了热烈的交流和讨论。

中国邮政储蓄银行数据中心高级工程师穆冬生出席了本次沙龙活动，并发表了《云计算技术在邮储银行的应用与实践》主题演讲。

坚持分布式架构为邮储银行上云打下坚实的技术基础

邮储银行2007年成立，2009年实现了物理集中，之后通过2010年、2011年的集中测试形成总结报告，决定用小型机集群的分布式架构，这也成为后来邮储云计算架构的基础。

云计算是邮储银行科技发展的必然选择

科技在发展过程中，遇到了一些问题，也成就了邮储银行的云计算发展战略：首先是近两年发现大量应用上线后，数据量剧增，如何处理大量的数据成为一个瓶颈；

其次，邮储银行从2015年开始大量的推动互联网的新一代，包括新一代的手机银行，新一代的网上银行，去满足互联网金融的落地。原有传统的架构已不能满足新一代的互联网金融的运用；

第三，对于行内分布式系统在实际运行所发生的故障，如果只是通过内部不同项目团队进行任务分解，很难形成了一个有效的支撑；

第四，在满足银行应用的前提下，需要对资源进行合理配置。

综上所述，云计算成为邮储银行科技发展的必然选择。

邮储银行云交易量占比60%，生产云系统及云交易量占比行业领先

基于业务属性，把互联网的一些应用搬到云上，打通外部的电子渠道，同时兼顾安全。互联网金融是核心，目前整体云上的交易量在行业内占比是60%。从投资效果来看，比之前2014年、2015年资源使用还是节约了不少。

以下是穆冬生演讲实录：

今天我主要跟大家分享一下云计算在我们行的一个应用和实践的总体情况，因为趁着这个机会，银行同业也比较多，大家都在一个微信群里，互相加一下，多做交流。

今天分享的主要有三部分，第一个是我们为什么选择云计算，行领导和总工在选择技术路线的时候主要是基于前期分布式的集群架构，第二个是云平台总体架构及关键技术在邮储银行系统应用的情况，第三部分是简单分享一下云计算平台在我们行内总体的应用效果。

一、邮储银行的云之路

1.坚持分布式架构打下坚实的技术基础

我们行2007年成立，2009年实现了物理集中，把各个分行的系统物理集中。因为邮储银行是从个人储蓄上来的，这块的量与四大行比量也是比较大，所以从2009年开始我们实现了个人储蓄物理集中，通过2010年的集中测试和2011年测试成形，在总结报告出来以后，行领导决定用小型机集群的分布式架构，跟我们今天的合作伙伴有点差异，而且后来没有再用大型机，这块也稍微有一点差异，但是在技术选择上还是选择的分布式架构。

2.稳健的技术推进线路

在选择的时候我们从产品和管理层上推动的是稳健的路线。

第一个是要有信息化产品普及应用；

第二个在扩展的时候，对应我们行目前在使用的产品，对开源推广的力度是比较大的，同时在不同的决策层中，从管理、业务，核心的慢慢应用，在开源组件选择上也是选择成熟的在我们行慢慢应用；

第三个，在推广的时候可能有一些分布式的框架组建的架构；最后在选择的时候，在路线替代的时候，从明年开始，会选择核心系统和小型机往云平台的论证，在往这个方向走的时候是最难走的一步。

3.超大规模核心系统应用是巨大的考验

从我们行来看，现在我在技术路线上尽量在满足业务需求的前提下，使用的是开放式的架构，然后小型机为什么要选择明年开始上云呢？

因为使用的小型机和存储，经过了2012年、2013年还经历了灾备，设备老化，有一部分产品慢慢的备份不足了，所以现在也遇到了痛苦。我们行在实现的时候，像其他系统的时候，包括使用开源的，尽量满足核心技术，以及硬件尽量可控。

在技术指标上，现在日均基本上是1.1亿笔，这个交易量跟各大行比算法不太一样，我们基本上按照业务逻辑算法，实际上满足1.1亿笔，峰值在春节前后左右，我们的金额量基本上比较小，不像其他行金额量比较大，但是会遇到一个问题，交易的笔数是比较多的，因此在这个基础上我们形成了核心系统，我们行目前有十亿的帐户，五亿的客户，网点数目前来看是排在比较前的，包括自营的和邮政的网点。

整体的范围来看，邮储银行在推核心系统的时候，实现了在系统设计架构建设的时候也面临了好多的方面。

4.云计算是邮储银行科技发展的必然选择

第一因为好多性能这两年上线的时候对我们行数据量来说是相对较头疼的，出现了一个瓶颈；

第二，邮储银行从2015年开始大量的推动互联网的新一代，包括新一代的手机银行，新一代的网上银行，我们要满足互联网金融的落地，这一方面原有传统的架构是不能满足的，因此我们在选择上云的时候，首先要把新一代的互联网金融的运用慢慢推到云上；

第三对于行内分布的系统，实际上从2015年开始实际上在运用当中也出了好多的异常故障，只是通过内部不同项目团队的分解任务，很难形成了一个有效支撑；

最后在这个基础上在满足银行应用的前提下，我们慢慢形成了我们行自己的资源配置，数据还有高效的服务系统，这种系统走过来实际上也是比较痛苦的，但是也是再往前走。

二、云平台总体架构及关键技术

1.云平台总体架构

我们行云平台总体架构主要是从三个方面来进行推我们现有的云平台。

第一在底层上基本上是以现有的Openstack，形成了现有的存储网络，在第一层次推下面IaaS层的时候形成了资源池。资源池在推动的时候会面临两个问题，前面专家也说过了，而且我们行现在出现了两地三中心，同时要面临现有北京的两个中心和合肥一个中心同城和异地云的推送，在这个方面遇到了很多问题，实际在推动的时候，在底层云资源输出的时候，第一阶段是完成同城云的资源统一管理，然后按照规划，从第二阶段，就是从下个月开始到年底，争取推动合肥和北京异地云，统一一片云的形成，让从它资源和业务上能形成一个有效的资源整合。

第二个我们行在推送的时候用的是Docker，我之前要把36家分行的资源收上来，推了一些容器，但是推的效果不是很大，只是积累了一些经验；接下来要上新一代资产业务的时候，把这一部分的计划放到容器上，从基础层和应用层在推；在不同项目组的时候我们也适当的推送一些人工智能，在云上实现云的输出，虽然在一些调用和性能上还不是特别理想，但是也在完全推，这个方向也是将来银行的一个选择。同时在组建的时候，数据库选择是P库，行内的架构和行内的数据用PG代替，不同的项目组，还有底层专门有PG的团队，为了让它更加灵活的在云平台。

对于第三层来说，应用开发这层跟下面的几层是有关联的，只有拿出基础工具的时候，上层开发比较固定，同时前面专家也介绍的对于标准来看，实际上我们在推送的时候应用从底层输出，逐步定义了几套标准，但是这套标准在云上来看他还是有些差异的。

2.云计算关键技术

A、PAAS层-数据库分表设计

从设计上来看，现在PG库是个轻量的，在我们行这么大的规模帐户和交易量的基础上，先侧重于1024的基础，在1024基础上可以逐步的拆分不同的库，规模上可能先以比如说启动的基本上是16，有的系统交易量大的时候我选择32，32的基础上然后让数据更有效的去分布，但是在渠道系统用的是目前还不错，但是对于帐户系统，有些后端在同步组件的时候时间效率上有一些问题，后来这些问题是通过一些别的辅助方式完善了一下，所以这些分布的设计是不错的，但是他有好多辅助分布的一个技术支持。

B、PaaS层-开源PG数据库

第二层来说，选择PG库是我们的策略，可能这种方式跟选择是不一样的。因为MySQL市面上比较多，也比较成熟，但它从标准实现上来看，拿我们行现有的业务来说，后来改了PG库的逻辑更严谨一些，在使用上和效能上，感觉要比MySQL要好；同时对于主表采用堆表存放，能够支持更大的数据量；灾备我们现在有一套同城很好的机制，但是异地上，还是在完善，但是从使用的效果和我们摸索的情况来看，通过两年多的摸索基本上能够实现有效的开源。

C、PaaS层-开源内存数据库

我们在数据库的选择上有一个方式，要逐步的往分布式云上走。我们行开源实际上慢慢从2014年开始，通过持续化的组建，从30多个备选当中去考虑，同时结合现有的信息量，对客户端的支持和数据架构支持的角度来看，邮储银行选择了云系统的组件，因有很多因素要考虑，最后变成整个云产品叠加组合上的选择是有不同的方向。

D、PaaS层-分布式服务

分布式服务我们现在在推，把原来传统的集中服务路由调用和多协议的选择，异构重置上逐步叠加，叠加的时候在服务中心进行注册，完成注册之后所有服务的分布重构，然后进行性能测试，目前来看有几个项目正在推的，分布式我们组合交易，把一些简易的系统通过服务注册上来，性能测试的结果还不足。

E、PaaS层-微服务

这一步是后续有几个项目有这么一个思路，就是逐步形成有效的微服务，但是这个微服务体系在推动的时候，发现有些服务组件的选择还是有些差异的，目前还是在尝试测试的验证当中，以上就是刚才我介绍行内平台的一些，还有技术选择的情况。

三、云计算行内应用

目前我们行内的云计算应用 是从2014年底开始，为什么在2014年底呢？刚才介绍了，实际上从2012年到2014年主要推全行核心系统的上线，但是核心系统上线之后，回头看的时候，好像所有的电子渠道系统跟其他行比是稍微要滞后，所以在2014年的时候云计算有一个逐步的推动。

1.邮储云平台实施路径

我们在推动云平台实施路径跟各大行都是差不多的，先是资源、应用的，然后数据的，数据智能这方面通过我们行的大数据现在已经走了三期了，通过大数据他的一个智能分析，然后和平台，形成一个统一的大数据的价值创造。

2.邮储云平台实施历程

实际上我们行选择云的时候没有直接拿开发测试上，是2014年决定之后，拿邮储在广州的一个消费公司拿他先示范的，因此前期在核心系统上是有一些差异的。

2015年的时候还选择了某一个公司，后来这个公司没做成，所以在2015年的时候，这个系统上完之后，有了一些经验储备；

2016年通过四大类的开发测试项目和电子渠道的项目，夯实了云技术平台的架构体系，后续手机银行逐步往云上搬；

2017年的时候我们做了一个大数据，当时考虑的主要有两类，一个大数据就是常规化的；还有一个是Hadoop的组建，同时还有一些实验室项目都往云上搬，因为实验室资源的回收和大数据想收回来是很难的，目前这些放在虚机上也不好收，同时也在尝试使用一些资源扩充。

2018年我们正在推的是负债和资产等资产类的核心系统上云。

最后，公司类的负债核心是因为现有平台的使用，他的量与其他方法比，我们算是低的，但是个人交易量上来的时候，压力是大的，尤其是前期平台的两地三中心的规划应用，本来去年我们就打算启动，但是目前有一些其他因素可能推到明年。

3.邮储云实施效果

云的实施效果这方面，我简单说一下。基本上推动了，但是在效果推送和资源调整的时候，因为内部的一些管理机制，造成了灵活度稍微差一点，因此希望通过今年和明年机构的调整设置，把技术和管理角度来看，同样的实现一个有效的调整。

A.双线体系设计

云在推送的时候还有一个双线问题，之前都在考虑云的灵活性，云的价值，但是云的安全也是我们要面临的一个问题。不管从硬件上和软件上，我们都尝试着在推，虽然也碰撞出很多问题，尤其在推硬件和软件推送的时候，银行这个行业还是比较游刃有余的。

第二方面是安全服务资源，对于虚拟的隔离，我们也加强了软件的安全，从今年逐步适用如何再去选择有效的安全组织，在虚机和存储之间进行架构。

同时在云主机上层的时候，我们已经考虑在应用一些项目来补充，另外通过预警机制在这方面形成逻辑安全；

在安全方面，我们在推动的时候要保证国民安全，所以在使用安全的时候连着密钥管理平台。

在业务风控体系上面，这些系统上线的时候，前期这个平台至少通过三级要求，同时在业务上进行外部的测评，通过外部第三方的测评，和一些渗透，发现一些问题，避免他从逻辑层面上慢慢渗透到下面，所以这方面也是在下一步的考虑。

4.邮储云应用云图

我们行建的云图也是有差异的，在建设的时候我们看到业务的属性，把互联网的一些应用、业务属性形成一个外围是电子渠道的、互联网金融是核心的云；同时要考虑到安全，在内侧的核心系统来说也要形成有效的云；开发测试我们现在的研究结果是暂时不做。

目前整体的交易量在行业内占比是60%，交易量应该是比较大的。投资效果来看，比之前2014年、2015年资源使用还是节约了不少，但是比如有些像内存资源，实际上了数据之后不会考虑太多节约问题。我们当时有个口号，五年之内整体投资要下降，但是这个里头不包括核心，因为核心系统是四级，四级没有办法，可能还要单独考虑一下。

5.邮储银行三方系统上云效果

整体的三方系统上云的效果来说，2015年、2016年每年三方系统都比较大，2017年目前全天成交量是1893万笔，但是对于三方支付来说，2017年至少感觉不像2015年、2016年每年压力那么大了。

对于新的手机银行推用的时候，最大的问题是并发上来了，因此并发上来之后，交易量、日均交易查询、激活这些方面是重点推动的，从去年整年来看，这两个系统是我们新一代的手机银行支付，同时今年也上线了新一代网银，但是它的交易量从电子渠道来说它是下降的，只是满足更好的客户体验。游戏网