2018-08-14 16:00

　　大家下午好，我先做一下自我介绍，我叫杨利进，来自于工商银行系统网络平台实验室，我们做实验室是做什么事情呢？主要是抓住于基础设施和技术架构，还有运维，两大领域的一些研究。

　　我们是运维单位，主要是保证信息系统的业务连续性，我们的创新和成本可控，这是从整个企业来说来看。

　　今天下午要跟大家分享的就是很小的一个题目，就是RDS的实践，今天跟大家分享的主要是三个方面的内容：第一方面就是我们面临的问题，我们为什么要创新，在这方面给大家介绍一下工商银行信息系统的运营架构所面临的一些什么问题。这个大概也就是在五、六年之前，大概2012年开始，工商银行和国有四大行都差不多，都是DB2的数据库，UNIX小型机，为什么现在叫分布式转型，是什么原因推出了我们的转型和创新，我们到底遇到了什么问题。

　　我的体会是这样，我们金融科技要创新肯定是遇到了问题，面对我们应用产品的时候你看到了什么问题，你看问题的深度有多大就决定了我们创新的成果有多大，这是我第一点要跟大家分享的。

　　第二点主要是跟大家分享关于数据库服务，也是我们思考也是从去年开始思考问题，从今年年初开始行动做这件事情，我们为什么做这件事情，就是我们的目标就是成本和效率。

　　第三方面就是大家前面都说到DBA要怎么样，我今天要讲的就是DBA的转型。工商银行有非常多的经验丰富的、数量不少的DBA，能力非常强。接下来面临着向分布式框架过程当中几个DBA或者十几个DBA，面对上千套数据库的时候还可以应对吗？

　　我们之前也做过很多的所谓的自动化，但是这种形式，DBA肯定要面临着转型。我们DBA怎么才能不成为业务的瓶颈，这也是我们要思考的一个问题，工商银行的系统也积累了大量的运维数据，我们后面怎么来做，把人工的工作怎么交给机器来做，怎么实现自动化监控、自动化检测等等这些都是我们要思考的问题，这是我第三点想跟大家分享的。

　　首先给大家介绍一下工商银行数据中心，大家都知道工商银行有9991的工程，1999年9月1日围绕全行的信息化的进一步的要求，启动了全行数据大集中的工程。我们数据中心是在2000年11月成立的，数据大集中对我们整个工商银行来说，不管是业务发展还是经营管理带来了非常深刻的变化，也创造了巨大的业务价值。

　　现在都讲大数据分析，我举个例子，业务经营管理层面上，在2002年我们整个全行的大集成完成以后做了综合的统计和客户端管理系统，就是现在大数据分析的雏形。效果是什么呢？我们的董事长一早上一上班就可以看到全行到昨天为止工商银行能赚多少钱。甚至有一次我接到总行的电话，有一个战略性的客户突然发现自己的存款少了多少，这是董事长直接关注的客户，可以马上查到原因，这是数据带来的便利。

　　回到我们的数据中心，2014年我们全面建成为了两地三中心的整个运营架构，大家可以看到，我不详细讲了。

　　现在看一下，工商银行所谓的宇宙行，你的信息系统又是这么巨大，我觉得还是前面所提到的我们面临什么样的问题和挑战，我简单归纳一下，碰到三个方面的挑战，第一就是就是业务本身创新发展的需要，就是我们本身工商银行的业务发展，我们的业务量现在平均增长率大概20-30%左右，我简单说一下我们现在每天的交易量大概在5.3亿笔左右，我们日均也要四点几亿的交易量，业务的增长是非常快的。整个我们互联网金融也好，工商银行打造业务交易的结构也发生了大的变化，整个工商银行除了是一个企业以外，还担负着很大的社会责任，要适应国家发展的各方面的需求。早几年工商银行就提出来了全球化、综合化的经营策略，除了传统的银行业务以外，境内有37家分行、境外有44家分行，我们还有综合化子公司有5家，我们工银瑞信是做基金的，还有集团托管业务8家。

　　这是业务发展自身的要求，我们的挑战也是非常严峻的，还有我们内外部的监管的要求，有信息安全的要求，早上也看到主会场有一个分享，就是可信云安全的发布，所以我们有信息安全的要求，还有国家要求的自主可控的要求。这是我们第二方面的挑战。

　　第三方面的挑战，比如我们的阿里等等，它们自身是科技型的工程，作为银行，我们金融科技的发展能不能给我们的业务创新做一个很好的支撑，甚至我们带动业务创新。在90年代的时候有一个是非常热门的，科技怎么引领业务的发展，现在很少讲“引领”这个词了，但是我们现在还是要讲科技发展怎么带动业务的创新、业务的发展。

　　我概括一下，工商银行信息系统面临以上这些方面的挑战，应对这些挑战，我们工商银行很早就提出来IT架构转型。以上是我简单介绍的。

　　前面介绍的都是非常宏观的内容，我介绍这些东西的目的就是让大家能够对我们工商银行的系统为什么要创新、为什么要转型有一个简单的了解，我还是回到今天的主题上面，就是我们为什么要做DB2。现在导致了我们两个挑战，一个是就是怎么保证我们数据库高效运行，而且要可控，我们开会要写会议纪要，所以我们既要系统高效运行，另外又要成本可控。另外就是DB2的数量，这些都是我们面临的挑战，我们怎么解决。

　　我们看一下首先业务上的数据，成本来说的话，银行的信息系统来说成本是非常高的，采购了多少服务器、采购了多少存储，我们整个的机房、网络等等整体成本，可能要看TCO是多少，这是我们面临的首先第一个我们业务层面的一个诉求。

　　第二就是效率，前面也都说了，一个数据库的供应是以周为单位，但是要十天半个月，要采购等等流程，要配合的东西也很多，在这种情况下目前来说行业的竞争也是我们很多分行、各地区谈一个业务，人家提出一些相应的要求，几天之内都是这个系统要上线，这样的效率可能满足不了要求。

　　第三是运营，我们整个数据中心的运营怎么提高效率。

　　最后一个就是整个环境要以服务化的环境来做，技术上怎么实现，怎么创造业务价值。最终的目标我们要做RDS这个事情，我们要成本可控，这是我们整个做这件事情的初衷。

　　我们也有一个规划，我们按三个阶段做这个事情，第一阶段就是解决成本的问题，怎么样实现在一台服务器上布数据库，技术成本就是数据库的虚拟化怎么来做。第二阶段就是怎么实现调度，我们数据库作为服务来调度，我们应用研发的人自主申请、后台自主提供，前面阿里的同志也说了，局部的概念要淡化。第三阶段就是数据库智能平台。这是我们RDS要建设的思路。

　　如果我今天的分享能够给大家一些启发的话，就能够达到我的目标。

　　第二大部分我讲一下RDS建设过程当中的一些思考，讲一些不是很技术的东西，但是我们看怎么考虑这些问题。我们如何选择容器的技术路线呢？有几个方面考虑的因素：第一方面是成本，看看大家是怎么做的，业界有一些评价。我们肯定是要做压力测试，用一些模型来支撑。另外就是和企业自身的应用场景结合，必须拿真实的应用场景来结合，到底跟你企业适不适用这是非常重要的一点。

　　第二方面我们讲调度，还是看调度的能力，但是数据库云化给我们无状态的应用做云化有非常大的区别，无状态的应用主要是在于它的部署，如果说你有问题了，另一个地方再起一个就拉倒，没有什么再多的调度的东西。数据库除了快速部署以外，还有高可用、弹性，至少包含这两个方面。在高可用层面，至少可以说RTO（音）时间缩短，银行承担的是很大的社会责任，这方面是非常重要的一个因素。

　　另外，前面也有老师分享容器的漂移等等问题，这对我们来说都是非常有参考价值的，我们怎么通过这些方法来做，我们所面临的问题可能都是局部居多，比如遇到一些宕机，就是局部的一些故障更多。虽然我们建成了两地三中心的架构，但是我们更加注重局部故障的问题，我们遇到这个问题的时候怎么保证数据不丢失。我们很少用本地存储的架构，我们通过一些容器的调度和漂移实现数据的零丢失，所以我们在高可用层面都会有很大的体现。这是我想讲的调度的第一个问题。

　　第二个问题就是弹性，银行实际上面临的场景是非常多的，我们业务支撑的增长，还有银行现在很多的业务受到整个金融市场的影响，比如2015年股票大涨的时候，我们交易量都是平常的五倍，这就涉及到弹性的问题，不是说我们弹性有没有必要，而是说弹性应该怎么样实现针对应用的发展。

　　另外弹性基于成本也是非常有好处的，不管是互联网企业或者我了解下来的金融企业也好，整个MySQL或者是数据库高可用，很多程度都是主备，备机一半资源都是浪费的，可以做一些报表和批量，但是实际上利用率是非常低的，在我们平常不需要的时候怎么让资源更好地分配，如果需要升级的时候快速地扩展，这样也是基于成本的考虑，这是综合来看，这些都是属于弹性效应。

　　另外调度来看的话，整个方案如果再好，如果不能跟你的技术环境适应的话，会遇到很多的问题和困难。我作为RDS是符合我业务的需求，解决我的问题。

　　第三方面讲的是支撑技术，支撑技术后面我可以详细讲。第二个问题就是你的问题要有解决方案，如果你的支撑技术不能提供，大家知道容器要比大家说的虚拟机可能来得要差一些，这些问题在方案里面怎么解决，所以我们要考量，我们最后选定了Docker+K8s的高可用性的方案。

　　性能对比就不展开讲了。

　　另外就是支撑技术，支撑技术就是整个计算、存储、网络分离是灵活调度的前提。网络技术的时候，除了解决自身的问题，你要兼顾建设方面的问题。我们计算、存储、网络架构，除了解决自身的问题以外，还要兼顾应用研发等等，否则你会遇到很多的困难和阻力，这个事情就办不成了。

　　第二部分我们看一下我们的这些技术，除了你解决的问题以外还有什么额外的政策服务，比如说前面讲的我们通过存储支撑技术实现我们数据的零丢失，我们存储怎么通过容器自动化漂移实现高可用。

　　另外容器漂移的时候，有的时候某一个应用计算资源特别大的时候，两个服务器不够，后面会不会要增加更高的配置。这样的情况，在传统的环境下服务器资源要重新申请审批，可能至少要几天的时间，如果在资源池里面至少是纵向伸缩，对我们的资源完全是透明的，我们整个在想技术方案的时候，一个肯定先要满足支持你方案的要求，第二兼顾传统的应用要满足。

　　安全隔离方面，这个就不展开来讲了，前面很多小伙伴们讲的非常多了，我讲的没有大家专业。

　　接下来看一下我们RDS的规划，我们的解决方案是什么？就是分层解耦。后面讲一讲我们平台提供的能力，这个前面的也讲了，我就不多说了。

　　我再讲讲我们DBA的转型，DBA的转型第一方面我们把RDS建成了以后，至少是我们的部署、扩容、弹性、缩容这些方面，这个工作量大概占了DBA工作量1/3以上可以解决。

　　第二我们日常的运维，前面也讲到了，我们也是积累了很多自动化运维脚本，但是我们有一个目标，尽量让机器承担更多的工作。不要说前面这些都不行，我的想法就是把平台做的更好，怎么更能集中地去运维，另外我们DBA的经验非常丰富，凭着你的经验和能力，让机器承担的能力更大，让平台更加丰富，这是我想说的第一点。

　　我们运维也是具有价值，DBA下一步怎么思考，很多运维和很多人分享都有类似的想法，跟大家声明一下这是我自己的思考，DBA怎么转型，通过运维大数据分析的手段和机器学习的手段来实现。Oracle上面应用和数据库关系不是很大，再看Oracle的过程中，MySQL的性能怎么好，它就是响应慢，那怎么办？特别在MySQL层面，应用和MySQL的结合越来越紧密，所以你要从数据分析，不能光看数据库的运维日志等等一些信息，还必须跟你的应用结合起来，和数据库的应用数据一起来看。

　　另外，图大家都会画，关键是在落地，做一个功能，可能这个功能是天天在做的，你花一个月的时间把这个功能做出来了，后面就做运维了，关键是在落地。

　　我今天的分享就这么多，谢谢大家。