【IT168 专稿】本文根据【2016 第七届中国数据库技术大会】（微信搜索DTCC2014,关注中国数据库技术大会公众号）现场演讲嘉宾王伟老师分享内容整理而成。录音整理及文字编辑IT168@ZYY@老鱼。

　　讲师简介

▲王伟

　　王伟，爱可生客户方案与售前总监,毕业于北京工业大学自动化系， 从业十八年，现任职于爱可生公司担任企业数据方案总监。曾就职于IBM，HP，Oracle，Sun MicroSystem与Synnex等多家世界优异IT公司，具有丰富的云计算、大数据与互联网技术的行业咨询与方案设计经验。曾参与建行、昆仑银行、上海银行、浦发银行、人保、太保、安徽移动、北京联通、北京智慧东城等多个客户云计算与大数据的咨询工作与建设项目，对国内外云计算、大数据技术和解决方案具有深刻和独到的见解。

　　正文

　　大家下午好，总体上来说，爱可生是以数据处理技术为根本，为企业提供私有云的解决方案。实际上爱可生专注于开源软件，专注于MySQL为企业提供定制化数据处理技术解决方案已经超过10年时间。现在大家都在谈互联网转型，学BAT，搞大数据，爱可生正是这样一家以互联网、大数据和分布式技术为根本，为传统企业互联网转型提供技术咨询、数据支撑平台和实施服务的综合性公司。

　　在互联网、云计算和大数据时代，我们的产品重心以及服务范围都在发生转变。传统企业进行互联网转型时，对数据处理技术、分布式数据库软件都有各自独特的要求。我们基于多年服务于企业市场的实践经验，结合对互联网分布式技术的理解，提供了基于私有云的企业高端PaaS平台，帮助传统企业实现新业务转型。

　　以上是我们数据处理技术的服务范围，我们以数据处理技术为核心，为互联网转型企业打造高端PaaS服务平台，以上这张图是非常典型的云计算架构，爱可生的价值体现在PaaS层。我们把PaaS又分为两个层面：一层称之为数据服务，另一层称之为应用服务。在数据服务中，包括业务型数据服务，也就是我们常说的关系型数据库服务。我们的PaaS平台可以提供弹性关系型数据库服务RDS，进一步，我们也提供分布式数据库服务DRDS，同时包含企业数据仓库EDWS。

　　在大数据时代，很多企业都面临这样一个问题：经过多年的信息化建设，积累多年的数据如何发现数据规律和创造价值。例如客户的交易日志和用户行为数据等信息，如何通过大数据技术进行整合。所以说在我们的平台，大数据技术也占有举足轻重的位置。

　　在建设大数据项目时，构建平台本身不存在太多的技术风险，问题在于积累的关系型数据，例如交易型数据或用户行为数据，如何实时有效的传递到大数据平台进行实时处理和数据挖掘。所以在这个层面，我们提供一套数据交换中间件。通过数据交换中间件，我们制定了一些数据整理和清洗的策略，可以实时或者按照一定周期，把在线系统产生的实时数据，例如交易日志和用户行为，同步到大数据平台进行分析整合，利用先进的机器学习算法和流式计算模型，对在线系统的业务模式进行辅助，利用数据创造商业价值。

　　为什么在数据服务之上会有应用服务呢?因为在互联网时代，企业一定会有很多应用面临互联网流量的压力，用传统的基于应用中间件的应用架构已经不能支撑，例如双十一，六一八，春晚红包等等短时间密集型品牌推广与市场大促活动。在如此大规模的密集型数据处理量级，不只是要为应用提供分布式数据库，同时也要在应用层面做分布式改造。也就是说，如果我们的应用如果还像传统银行一样只能做垂直容量扩展，就很难适应大规模的促销、红包秒杀等海量数据处理的技术要求。所以我们推出如下应用框架来帮我们解决这个问题，对企业应用进行微服务改造。

　　爱可生专注于企业数据处理技术的核心能力，最终以组件、平台、服务等多种方式进行输出，为企业提供互联网转型的技术保障：

　　1、B2D基础软件，B2D基础组件针对开发者，其中包括针对MySQL的自动化读写分离，数据库的高可用，分布式数据库中间件以及代表数据库监控组件等面对开发者的组件。

　　2、PaaS平台产品，根据上述这些开发组件，我们打造了很多PaaS平台产品，我们可以提供RDS、DRDS、DevOps和ThinkBig平台。

　　3、企业数据平台咨询服务，包括在线交易数据库设计非常好的实践，应用如何改造成分布式，以及在线分析多维度数据汇集算法等。

　　接下来，我们谈一些实质性的技术内容。因为今天是一次数据库技术大会，那么我们就从数据库的角度，谈一谈开源数据库在企业应用中会面临哪些问题，以及爱可生的方案是如何解决的。

　　以MySQL为例，MySQL十分简单，易用。早在10年前，我们就称MySQL为十分钟的数据库，因为MySQL可以短时间内搭建起来，迅速用于开发、测试、甚至上线运行。但如今在互联网时代，我们采用的开源数据库会面临以下的问题：扩展性和高可用问题。我们的网站做一个简单的促销，比如红包，秒杀等活动，此时会有非常大的流量流向网站，这时数据库层面如何做扩展呢?如何保证高可用呢?

　　针对生产应用中的扩展性问题，因为现在要做的是传统企业向互联网转型，所以势必要学习互联网行业做数据处理的经验。

　　在多年的数据服务经验中，我们注意到，互联网行业经常使用读写分离技术来提升数据库整体的吞吐量。所谓的读写分离是指主从异步数据复制。互联网行业技术密集，他们有能力在应用里做读写分离逻辑，把写入操作放到主库实行，主库会把写入的数据复制到从库，然后应用由从库进行读取操作。这是互联网行业的用法，但这种模式很难应用到传统企业，因为传统企业尤其是金融，经常会有一个单独的开发中心、测试中心以及运维中心，开发中心在开发应用或者外包给第三方时，他们不会管部署架构是什么样的，所以这种方式很难在传统企业实施。

　　针对这样的现状，我们开发了DBProxy组件。DBProxy实际是一个读写分离插件，上层应用认为DBProxy就是一个数据库，可以采用任何管理工具比如JDBC或ODBC连接DBProxy，对SQL进行解析，然后写入主库。这样就使得上层应用和底层部署架构进行了解耦，这是我们提供给传统企业提升数据库吞吐量的非常好的实践。

　　我相信很多人可能会问，怎么保障复制延迟呢?确实，MySQL异步复制一定是有延迟的。通过优化，我们在一些业务峰值可以将延迟控制在1到2秒的量级内，一两秒甚至三五秒这样的延迟，实际上对大量的互联网业务模式来说是可以接受的。但确实有一些比较苛刻的情景，不允许两秒或者三秒的延迟，这个时候怎么办呢?我们的设计可以强制SQL读取主库。但这样的场景毕竟不是常态。

　　另外一点就是高可用，开源数据有很多高可用方案，毕竟MySQL从成立到现在差不多有20年的历史了，社区里有很多做MySQL开源方案的，实际上我们帮客户做了十年的技术服务。我们认为或多或少都有这样那样的一些问题，有一些可能是在业务方面的数据丢失。比如说多年前，我们在做中国移动的飞信项目时，把飞信的100多个SQL Server转移到MySQL，就做了高可用。实际上高可用在当时是可以保障的，但如果业务峰值真的发生故障，有些方案可能或多或少都有数据不一致问题。正常情况下，用Backup检测Master的状态，一旦发现Master宕机，Backup就会启动。但不幸的是，假如这条通路发生了故障，就会造成数据不一致等一系列问题。所以我们经常会用到高可用方案，我们认为其实它并没有满足我们金融行业对数据一致性要求非常高的这样一个场景。最终，爱可生开发了自己的高可用软件，通过上帝视角，判断各节点的状态，保证高可用。

　　所以后来我们做了大量的设计，开发了ActionTechHA组件，用于保证数据的一致性，即使在极端情况下，也不会有任何数据丢失。所以说归纳下来，传统企业要做互联网转型需要集高可用技术之大成，合横向扩展能力于一身的数据库。基于此，我们开发了“互联网+”数据库云PaaS平台。

　　PaaS平台架构分层如下图所示，最底层是物理层，是设备的一些物理机和存储，如果没有物理机只有虚拟机，也可以接受，但虚拟机的性能会大打折扣。在物理机里构建私有PaaS数据库云平台，我们选择一台Server安装云平台管理软件，云平台管理软件启动起来之后，它会有一个管理维护，从这个角度来看，我们实现了自动化运维。

　　每一台server都有一个bot，它的作用在于管理任务的代理和自动化运维。管理员需要安装一台服务器，再把其他机器纳入到集群管理。对于任何一个业务库的创建、配置成一个高可用集群，同时进行读写分离，这些操作不需要管理员亲自到机房在Server上做，都是通过bot自管理实现的，这是物理层的构建。

　　物理层构建完成之后，我们要构建数据库。在数据库放6台Server，但是我支持在一台服务器上部署多个MySQL instance，从而实现服务器数量和mysql instance的解耦。这个架构不采用任何虚拟化技术，不产生任何虚机，因为我们认为虚机对数据库造成的性能损耗是非常明显的。在不依赖于虚拟化技术的前提下，我们实现了数据库的资源隔离、自服务、自管理等云计算的特征。

　　虚拟化经常会使用分布式存储，这种方式哪怕你使用万兆以太网，看起来貌似传输效率提升了，但是TCT/IP有它本身的特殊性，即数据传输延迟比较大。比如说对于4K小数据的交换，它的延迟非常严重。而MySQL恰恰是对存储的IOPS非常严格的，所以我们的云平台不使用任何虚拟化技术，同时保证了资源的合理分配和调度。

　　通过管理门户，在物理层之上构建数据库云平台，这里面的每一个椭圆都是一个数据库业务组，也就是说我们构建一个数据库云平台之后，在数据库层可以创建多个不同的MySQL业务，比如说我的交易、支付、短消息等就是不同的业务。每一个业务组，我们都配备了高可用方案。通过一些组件、高可用集群、读写分离器，把每一台从机都利用起来，从机同时会承载我们读任务，而不是简单的备机。同时，我们也很担心读写分离器会成为一个单独的故障点或性能瓶颈。所以在读写分离这一层，我们通过HAProxy做了一个负载均衡。我们在管理门户里同时集成了备份管理工具和监控管理工具，对整个平台做一个整体的监控。

　　监控物理硬件的同时，我们也要监控每一个业务的健康情况。更为重要的是，监控主从之间数据复制的效率，也就是可接受的数据复制延迟时间。假如超出了我们可承受的延迟范围，要产生一些自动修复手段，使这个延迟达到标准化。

　　这是PaaS云平台的优势，它是我们多年来积累的做MySQL的经验，高可用而且可以确保在极端情况下，通过读写分离的方式做到快速处理，因为有这样一个中间层，使得我们上层应用不用做任何更改，即直接使用这套技术。

　　接下来看一下对互联网转型企业的大规模云数据有什么样的要求。传统企业要向互联网转型，势必需要一些分布式技术对业务系统做一些支撑，一些互联网巨头公司的分布式技术都是私有的，并不可能提供给传统企业。这是我们开发分布式集群的核心驱动力。

　　分布式集群可以帮我们做应用系统的分库分表。分布式集群通过负载均衡，向上服务于应用，对应用来说，SQL是完全透明的，向下可以对接若干MySQL集群，然后由中间层做数据分布分表。在软件架构层面，充分使用了服务器技术。下面是我们的一些数据库节点，每一个节点我们都做了高可用。

　　分布式集群在架构上充分利用服务器的多核多线程。每一个服务器线程里都在跑的一些模块，包括SQL解析、SQL执行、SQL路由、SQL计划，响应处理和结果的合并，最后汇报到上层应用。同时，围绕这样一套架构，对分布式集群如何做数据备份、数据恢复和数据迁移，比如之前采用的数据库不是分布式的，我们如何迁移到数据库分布式里。同时，我们对整个运行情况做了管理。

　　以下是数据库分库分表模型，假如我们的数据库叫DB1，DB1里可能有两张表，一张表T1，一张表T2，对表T1来说，最终会落到数据库1。而对于表2，我们认为它可能会膨胀到上亿或者几亿的数量级。此时，我们对表2做分库分表操作，我们把表2配置到分片2、分片3、分片4，同时做不同的数据库。在这样一种配置里，如果表1需要进行数据插入，那很简单，直接落到数据库1。但如果表2要插入一条数据，就需要通过哈希算法插入到不同的数据库分片和不同的数据库里。如果对单表进行查询，表1直接在分片1上做，如果是表2，就需要分发到不同的分片上进行，然后再由中间层做一个数据合并。其实也很简单，复杂的是跨库、跨表。

　　我们的中间层支持所有在线操作，有大量数据合并、统计、汇总的任务。正由于我们对中间层有这么多要求，所以中间层不是一个单独的节点，在分布式的中间层，有多个节点来并发执行一些非常复杂的操作。

　　我们如何对大数据进行进一步整合呢?我们用到了Unified大数据分布式集群，这里面用到了MySQL分布式中间层和分布式集群。但毕竟MySQL不是天生就做横向扩展的，只能通过中间层从一定程度上扩展，但毕竟不是无限的。我们可以扩10个、20个、30个节点，但如果扩100个节点，我们的中间层还能支撑得住吗?说实话，我们不知道，到目前位置还没有做过超过100个分片节点的分布式集群。

　　其实我们并不需要把分布式中间层扩的那么大，我们可以通过兼容大数据技术实现Unified集群，大数据天生具有横向扩展能力。我们通过构建大数据平台，通过数据复制中间件可以有效地把产生的数据复制到分布式集群里。同时这个大数据平台向上是开放的SQL接口。

　　上层有Mysql_Spark_Proxy组件，它会做SQL解析，解析出来的SQL势必需要放到分布式集群上。如果是一次简单的查询，对于热数据的查询属于分布式，但假如是对长期历史数据的检索，就需要使用Mysql_Spark_Proxy调用大数据集群了。也就是说，分布式集群和大数据集群取长补短，提供一套完整的解决方案。

　　同时我们把其他的存量数据放到分布式Hadoop集群上，通过开源方案也可以把数据放到spark集群里，可以跨库异构分析。

　　传统企业做互联网转型时，比如银行，实际上传统银行做一次更新可能需要一个窗口时间，这个窗口时间动则一两个月，长则一年，甚至更久。这样的开发效率、开发周期实际上不适合这种灵活快速的互联网转型。同时我们希望每一个开发组、测试组，在需要数据库这样一些资源时，可以采用DB as a Server的方式在线申请使用。所以针对开发测试，我们提供了这样一套方案。

　　这是商业银行的开发测试，就是由DB as a Server 支撑开发到测试到运维的整个生命周期。对于这样一家商业银行来说，通过这种方式提升了MySQL的交付能力，形成了标准的MySQL运维管理规范，从而实现了全面的MySQL运维自动化。

　　目前已经有效支撑了手机银行，客服、互联网在线融资、信用卡等30多套业务系统。以下是一些界面展示，首先是一台新的物理机，现在有一台新的物理机要入库，要入到金融区域A，还是B，都是通过这样的界面来做入库操作。

　　接下来是实际申请界面，后面是密码，提交之后，它会帮我们自动化创建一主一从架构。它不只是高可用，更重要的是读写分离，数据库吞吐量的提升。备份在后台可以以自动化的方式自动完成。

　　接下来是扩容，因为我们要对性能进行扩容，对存储容量扩容，一开始10GB的数据文件现在想在线扩容到20GB。

　　接下来是HA扩容，假如我们一开始没有配置HA，后来要提升吞吐量就需要HA。或者原来是一主一从，现在想扩展成一主两从，一主三从也可以使用HA扩容。

　　前面提到虚拟化本身的特征并不适合跑数据库，在不使用虚拟化技术的前提下，怎么做到资源隔离呢?实际上我们采用的是Docker技术，采用Linux容器技术可以对云管理平台做资源的合理配置。可以使用如下的方式使不同的资源合理配置，在不使用虚拟化软件的情况之下，做到资源隔离。

　　下面的这个案例是和金融相关的，因为大家都知道，这两年互联网金融风生水起。无论是银行背景还是民间资本，他们都把互联网金融作为今后的发展重点。

　　我们做了很多的银行案例，这家是没有银行背景的互联网金融公司，由我们提供的业务架构呈现的技术支撑服务，目前它的注册用户量超过1个亿，以下是它整体的一个平台架构，其实跟刚才讲的非常一致，只不过是把资源更加具体化了。

　　我们帮助这家互联网金融公司采用了30台物理服务器构建了这样一个云数据库集群系统。一共支持了23套业务数据库。在这之上，我们把交易库单独拿出来做了独立的负载均衡，因为交易库是最大的一个数据库，去年可能注册用户量差不多在5000万左右，这个库的日均交易在3亿条SQL。所以说读写分离这种方式看起来简单，但实际上只要有效运维，可以支撑相当大的规模。

　　上层搭建了Redis缓存，进一步提升整个数据库的效率和吞吐量。截止到去年11月，我们有效支撑了它的日常业务。但这家公司实际上是一家很有野心的公司，5000万的注册用户量显然不能满足它们的发展需求，所以在今年春节期间，它们做了红包的促销推广活动，希望借红包推广自己的业务。当时提出的设计指标是每秒100万个红包的设计容量，而对于这样的要求，我们认为当时的架构是不足以支撑的。

　　我们也可以看到，读写分离的架构，主节点只有一个，而对于一秒钟要处理100万个红包来说，一个主节点显然是不能满足设计要求。所以我们根据设计容量的要求，最终把交易库和新增的红包库做了分布式无缝改造。在没有影响业务的前提下，把它迁移到构建的分布式当中。

　　这是物理集群的构成情况。基每台服务器内存在192G，2路cpu，就可以支撑日均交易， 10亿条SQL的数据量级。

　　以下是改造后的技术架构，对交易库和红包库分别部署了分布式集群软件，各带了16个MySQL分片数据实例。也就是说，每个红包最终都有一个红包ID，对红包ID做哈希算法，最终决定这个红包会落在哪个分片节点，在红包交易的过程中，我们可以在16个节点并发执行红包在线业务，从而显著提升整个平台的处理能力。

　　以下是管理平台展示和客户收益情况，相信大家听完技术与原理的阐述，已经非常理解分布式架构的好处，就不一一进行详细展示了!

　　今天的分享到此结束，谢谢大家!爱可生是一家在互联网转型的风口浪尖上，帮助企业通过数据获取商业价值的公司，希望大家关注我们的微信公众号，共同构建开源与分布式技术社区。