【IT168 专稿】本文根据【2016 第七届中国数据库技术大会】（微信搜索DTCC2014，关注关注中国数据库技术大会公众号）现场演讲嘉宾汪洋老师分享内容整理而成。录音整理及文字编辑IT168@ZYY@老鱼
讲师简介
▲汪洋
汪洋，平安科技数据库技术部总监
1996年开始接触Oracle数据库，1998年考获OCP 7.3证书，从此与Oracle数据库结下不解之缘。2011年至今任职于平安科技(深圳)有限公司，担任数据库技术部总监，负责生产、开发、测试数据库的管理运维工作，向开发部门提供应用系统的数据库产品选型，架构设计方案，以及提供必要的数据库开发支持等。
近年开始关注和研究新型及开源数据库产品在金融行业的应用，配合公司整体战略，促进传统金融向互联网的快速转型。在致力Oracle数据库稳定运营的基础上， 引入了MySQL、PostgreSQL、Redis、MongoDB、TimesTen等数据库并推广应用。 在加入平安科技之前，供职于Oracle香港高级客户服务部门3年，为香港、澳门和深圳的客户提供Oracle数据库架构设计，升级方案制定，驻场支持等高级服务。期间也曾做为资深数据库专家参与解决香港和深圳重要客户的疑难问题分析和解决。
正文
大家好，我是平安科技的汪洋，我今天演讲的主题是《平安数据库云平台建设与规划》，我的分享主要分为以下几个部分：
平安在主机存储方面逐渐实现标准化和规范化，在数据库层面也努力实现标准化和规范化。以往搭建一个数据库可能需要几天甚至一星期的时间，在互联网时代，如何满足敏捷开发、敏捷交付的要求呢?因为Database as a Service全都是自动化和规范化的，所以可以大幅提高时效和质量，并且不会出现开发、测试、生产环境各不相同的情况。根据oracle统计，数据库发生故障，差不多有50%都发生在配置和安装上;系统在开发测试通过之后突然发现生产环境发布出了问题，而采用DBaaS可以解决这些问题，大幅降低这些方面的出错概率。通过在集团内部提供DBaaS，可以很大程度上提升客户满意度。
如何满足金融监管的要求呢?平安的一个优势在于我们是金融集团，我们知道金融监管的要求，在发展互联网金融的同时满足监管要求。平安不仅传统金融部分增长强劲，而且快速向互联网转型，拥有许多具有互联网特性的公司，也开发了很多移动应用，这些公司都要求敏捷开发和敏捷交付。在这种情况下，云是唯一的解决方案。
我们很清楚建云可以带来什么好处。无论是给平安科技自身，还是给集团子公司带来的好处，但我们也面临着难点和挑战：我们要怎样建云，要建什么样的云。我们不仅使用Oracle，最近两年也对开源数据库产生了很大星期并投入使用，我们在集团内部引入了很多新型数据库产品，包括PostgreSQL、MySQL，在NoSQL领域用到了Redis和MongoDB，在内存数据库领域用到了TimesTen。
数据库产品的多样性、版本多样性、平台多样性以及数据库架构的多样性，安全区域众多等问题都是我们面临的难点和挑战。
我们不光有X86服务器，还有Solaris、AIX、HP等，平台的多样性使建云产生了困难。DBaaS不是说把数据库部署在服务器上就大功告成，还有很多配套的东西，例如HA、监控、备份等。而私有云还有一些地方和公有云不同，需要特殊考虑，比如权限管理。此外核心和非核心系统也需要区别对待，极其重要的高负载的核心系统可能需要部署在小机上。所有这些，都是我们在建设DBaaS初期需要考虑的问题。
即使是每一种数据库产品还有不同的架构，不同的RTO，需不需要同城或者远程灾备，也都是建设DBaaS时需要考虑的问题。一些大公司的规范肯定是非常多的，包括主机分配规范，存储分配规范，数据库架构规范，运维方面的规范，如何把这些规范融入到平台中。我想DBaaS提供的不是单一的实例而是一个完整的产品，这个产品融合了我们十几年的运维经验，我们需要给大家提供有用的、可靠的产品。
另外，还存在公有云和私有云的共存问题。我们对某些集团子公司的私有云采用全托模式，把他们的数据库托管给科技进行管理;而对于公有云来说，有些集团子公司是属于互联网性质，可以给他们更大的自由度。因为他们也有自己的DBA，他们自己有能力管理数据库，所以有一部分权限就要跟私有云的区分开。
在私有云方面，因为是全托管，所有的数据库相关问题、数据库升级都由平安科技来完成。而对于公有云来讲，DBaaS用户可能没有操作系统权限，但要求出现数据库问题让用户能够快速查找、定位并解决，这需要开放更大的数据库权限给他们。不知道大家有没有听说过Bi-modal IT双模式发展，传统的金融公司包括银行和保险公司，一方面要求系统高可用、高可靠、高性能;另一方面又想向互联网转型，需要敏捷开发、敏捷交付。所以现在很多传统公司在进行双模发展，我们的DBaaS来按照这种思路来规划，让两个模式都可以往前走，这就是公有云和私有云的区别。我们建设的私有云就是服务集中管理和DevOps高度集成;公有云就是自助管理，给它一些管理API，它就可以订阅或者集成API提供的管理功能，自主选择如何维护数据库。
知道了怎么做和为什么要这么做之后，我们应该建什么样的DBaaS呢?平安的优势又是什么呢?平安运行了十几甚至二十年，我们积累了大量的运维经验，有很多方法是我们在实践中发现的，甚至Oracle的很多经典案例分享也是平安贡献的。平安对资源和成本的精细控制让我们遇到了很多其他地方遇不到的问题，积累了大量的架构设计和运维经验。我们希望可以把这些经验融入到我们的DBaaS数据库平台里。另外金融监管包括保监会，银监会，证监会，他们对恢复时效的要求，对不同级别的数据库的数据恢复以及高可用、安全性的要求，一样在平台中得到了体现。平安目前提供的DBaaS服务已经涵盖了这些方面，我们的愿景就是建造最安全的金融云。
接下来，我们来看一下数据库平台的概念框架：
在这个数据库框架中，最关键的部分就是Cloud Deployment和Job Schedule。Cloud deployment顾名思义是用来做发布和部署的，当我们有一个新版本，或者想创建一个数据库时，只需要点一个按纽，Cloud deployment就可以开始工作，按照我们给出的主机资源分配和存储资源分配的规则创建数据库，并不是单一的实例而是一个完整的架构产品，是包含高可用架构和集成了各种工具的产品。这个过程是异步的，并不是说点击按钮之后一直等待直到数据库建完，而是通过异步的方式，数据库建好之后，就会通知你。一旦数据库建立失败，它会告诉你失败的原因。
ZeroMQ其实是Salt技术框架里用来下发任务的的组件。Resource Pool是资源池，也就是当我需要主机资源、网络资源或者存储资源时，Resource Pool就可以用来分配资源，再上一层是CMDB——配置数据库。创建数据库前会读取配置信息，应该是在哪些主机和存储上创建，创建完以后会写入一些配置信息，还有就是发邮件，创建好以后会通过异步机制通知我们。它还具备一些统计功能，比如统计创建了多少个数据库。在公有云的情况下，Open API可以实现自己订阅需要的管理功能。在图的最下方，代表的是不同的数据中心。
紧接着是技术性框架，大家可以看到有个PORTAL，如果你在PORTAL上进行操作，下一步就是DBaaS服务器，通过它控制Saltstack Master。我们也曾经考虑过使用oracle的相关服务例如OEM，但因为前面提到数据库产品种类繁多，OEM无法全部支持。也了解过行业中的其他一些框架，都不能很好的满足我们的要求，最后我们选择了Saltstack部署框架构建DBaaS服务。如果本身数据库模块版本要更新，那就通过Saltstack访问GitLab拿取最新的版本进行下发。Saltstack通过Salt Master把任务下发到Minions来实施，这两个基本上是Saltstack框架最主要的部分。
上图是我们提供的一些云平台服务，有多样化的产品，也有不同平台上的产品，当前这些并不是所有都已经实现。但将来，肯定会一步步实现全覆盖。至于Resource Pool和后摩尔定律时代，现在基本上制造工艺已达到极限，芯片速度无法赶上当初摩尔定律的18个月。Intel因为这个原因也对制程流程进行修改，该制程分为两个阶段，过去首先是Process，其次是architecture;现在分为三步进行架构优化，一个叫process，一个叫architecture，最后一个叫optimization。也就是说后摩尔定律时代工艺和技术也基本到达一个极限，我们不能再像前几年那样，通过增加CPU速度，进行Scale Up来获得资源的增加和性能的提升。而要增加CPU数量，做Scale Out，云计算就可以通过Resource Pool帮助我们做性能提升。
再来看一下DBaaS中的数据库产品架构实现。
拿PostgreSQL来说，其具有完全同步的主从复制功能，但如果设置了这种强一致的同步，性能就会遭到损失。如果设置异步，可能没办法百分之百保证主从切换数据的强一致性，而对于金融行业来讲，有些情况下数据丢失是无法容忍的，所以我们从使用本地盘演进到了共享存储架构。这种架构在oracle上平安已经使用多年，是安全且可靠的，是金融行业可以信赖的。
从图中可以看出，我们有一个同城容灾，DB Server和DB Server Hot Standby处于一个主机集群，主机发生问题切换时保证数据的强一致性，另一方面实现了计算和存储的解耦。SAN存储相比于主机来讲，可靠性占优，尤其是相比于X86服务器来讲。基本上存储很少发生问题，多数是X86服务器出现故障，但如果使用本地磁盘，就相当于把计算和存储绑在一起。如果主机挂了，存储也会同时不可用，这时候如果发生切换就会出现数据不一致的情况。在这种情况下，就希望能够把计算和存储解耦，采用共享磁盘架构，通过VCS或其他集群技术来实现切换。当主机出问题时，我们可以快速切换到另一个主机，而存储丝毫不受影响。金融行业对数据安全要求非常高，采用同城容灾并不能保证数据百分之百不流失，但这种情况很少发生，因为是在不同机房之间，或者在同城的不同数据中心之间延迟是非常小的，是可以容忍的。另外，远程容灾必不可少，尤其是现在的金融系统必须要做远程灾备，要保证即使地震或者发生其他自然灾害都可以快速切到远程，这种情况下也会有一定数据丢失。DBaaS中PostgreSQL备份采用WOS存储，极大节省了存储成本。
关于服务的高可用性，以MongoDB为例可以看到有三个数据节点和两个仲裁节点组成一个复制集。MongoDB有其内置的横向扩展性。这点不同于MySQL，MySQL自身不具备横向扩展性，需要使用第三方代理。MongoDB架构的复制机要求至少有三个，因为要投票，大家做分布式都知道肯定需要投票，发生问题时需要快速切换。由于要有同城或远程容灾，所以三个数据节点是必不可少的。为了增加它的高可用性，再增加两个没有任何存储的仲裁节点，用五个节点保证它的高可用性。也就是说将来DBaaS上提供的MongoDB数据库，每个分片都是有五个节点的复制集，在任何情况下都能保证其数据的可用性。
我认为RTO和RPO分为很多层面，比如HATO就是主机故障的情况下，需要进行恢复的时间;还有RTO，如果整个城市出现了自然灾害这种极端情况，远程的灾备环境需要启用，服务从停止到切换到远程重新提供的服务时间定义为RTO。这些因素决定了数据库架构的搭建，DBaaS根据不同的SLA自动选择最适合的架构。
服务的管理性，拿oracle来说，我们提供的不止是一个实例，也不止是一个高可用的架构，我们还集成了多年来累积的运维经验，例如对实名用户的管理，对数据库的审计和性能管理。拿分区管理来举例，oracle分区的功能非常强大，但它也有不足之处，比如交换分区的时候要检查是不是所有交换分区要求的条件都已经满足了，临时表上的索引是否完整，一点不一样就会导致交换分区失败。我们当然不希望出现这种情况。问题其实完全可以通过自动化运维管理来解决，所以我们自己写了一套封装的oracle分区管理，当交换分区时，可以保证只要调用这个过程分区交换肯定是成功的，该管理程序可以自动做健康性检查和一致性检查，包括分区以后的各项检查。还有对统计信息收集和执行计划的管理，都已经集成到我们提供的DBaaS平台上，提供的是一个完整的产品。此外在数据库内部，确保一个系统发生问题时不会影响到同一个数据库里面的另外系统，叫做资源管理器，还有索引碎片分析，林林总总，数量众多。总之我们提供基本服务，进阶服务和高级服务。
Cloud Monitor主要用于监控，我们希望能够把这些产品或服务统一到一个监控架构中，最终我们选择了Zabbix。Zabbix本身针对不同的数据库提供了一些可下载模板，但每一个数据库还有自己的特性，针对这些特性，平安针对每一种数据产品编写了自己的指标并补充集成到Zabbix里。
最后希望能够通过Cloud+DevOps 实现数据库审核，包括对数据库版本的审核和对SQL语句的审核。这也是DBaaS云平台部署的一部分。在DBaaS上，可以选择订阅不同的API，完成对不同版本数据库和SQL的审核。
在平台上，我们也提供了PATCH升级，SQL Audit以及性能影响分析。平安对此的要求是非常严格的。大家都知道，数据库优化器是基于统计信息的，如果收集的统计信息发生了改变，执行计划就有可能改变。可能变好，也可能变差，但一旦变差，就可能导致应用系统出问题。所以在已有字段上加索引或者收集统计信息时，我们都会自动进行性能影响分析，这样可以保证我们在收集统计信息时，及时发现问题，及时改正。性能影响分析是融入到我们DBaaS平台上的。此外还有一些数据库的升级和容量规划服务，都集成到了我们提供的平台上。
从2015年2月到2016年4月，可以看到这个增长的斜率，蓝色的是redis，因为我们在向互联网转型，需求越来越多，并发越来越高，所以前端需要有redis来降低响应延迟及分担数据库负载。redis最多达到了748套，Postgres最高达到了235套，mysql达到了166套，而且还在快速增长。
我们的愿景是希望能够做到DBaaS对平安所使用的数据库产品全覆盖，也包括未来可能引入的开源数据库技术。也希望把DBaaS平台和其上的产品提供给我们集团的子公司，或者将来可以把这个产品提供给一些中小银行、保险公司或金融服务公司，不断的优化体验，进一步提升时效，让大家把焦点聚焦在他们的业务上，而不是IT的资源或流程上。我的演讲到此结束，谢谢大家!
