[来自IT] 导语：本文根据蔺瑞超老师在年5月12日现场演讲内容整理而成。
蔺瑞超汽车之家高级数据库专家 汽车之家MySQL技术负责人.负责公司MySQL的运维体系建设,以及数据库相关平台设计和实现工作。 摘要：分享一下汽车之家数据库服务化平台从0到1的实践过程。详细介绍平台的整体架构，技术栈以及各系统模块的工程化实现方案。希望给正在做数据库自动化，平台化的同学一些借鉴和启发。 服务化平台目标及发展历程 汽车之家整体平台的目标是实现数据库运维自动化、自助化、服务化。目前，智能技术发展迅速，智能运维成为主流，汽车之家后续也将朝向智能化发展。 年之前汽车之家数据平台基于SQLServer，年之后开始使用MySQL，目前，两个体系同时使用，平台建设兼容SQLServer和MYSQL两套体系。年，汽车之家基本是纯手工，做了一些标准化的工作和一些规范的制定以及落地。年，主要做一些工具化的东西，比如写一些自动化相关的脚本工具。年，开始逐渐构建系统来解决问题。年，为了配合公司私有云的战略，把数据库服务作为服务平台去建设。未来，我们会向智能化运维方向进行探索。 服务化平台技术栈
汽车之家目前平台的技术栈主要基于Python加Go，包括社区的一些比较优秀的组件。 服务化平台系统架构
这是汽车之家的基本系统架构，最底层是MYSQL、SQLServer，现在在跟进分布式数据库的评估，后续会有一些相关场景的落地。之上是基础组件、信息采集层。基础组件主要包括运维的基础设施。信息采集层包括元信息、性能数据以及查询日志等。然后在这些信息的上层做了很多运维、数据相关的组件系统，完成我们的运维工作。 整体架构的上层是一些服务的Portal，主要是面向开发同学和DBA同学的服务单元。灰色部分是在做的以及未来的考量，蓝色部分和绿色部分是已经实现的功能。 运维设施 服务的自动化构建，是开发同学提出资源申请,一直到服务交付的完整流程。我们主要实现了数据库服务的自动化部署，包括MySQL集群建设、SQLServer部署以及Slave自动构建。 整个实验方案是基于Salt来实现的部署模块，部署采用Celery分布式异步任务框架来做任务的异步化。整个流程会结合系统平台部的资源申请和装机的流程，协调交互。 服务化自动化架构
这是整个架构，从服务申请到资源交付的全流程实现。系统平台系统提供流程申请以及装机,之后和我们DB自动部署平台做交互，请求过之后,我们会异步和salt做交互。 基于Salt实现了两个部署模块，分别支持SQLServer和MySQL，未来开发模块来支持分布式数据库的部署 服务化自动化构建
在请求过来之后，DBA对它做一些配置,比如选择版本和端口,实例数量等信息。
选择完之后进行异步部署。
可以在这边看到它的状态和日志情况。
这边会把最终部署结果反馈回来，如果有问题，DBA同学需要去处理。 备份恢复体系
做DBA运维,备份恢复是我们最重要的一块工作。目前的备份由全备和日志增量来实现，整个备份过程中需要加密，然后进行恢复较验。
备份恢复体系，由DB服务器端做备份，通过备份程序把整个备份推到BufferStorage。整个过程它会把备份信息写入我们平台的数据库，整个阶段都会跟元信息做相关的交互。这一共分为4个流程,从开始备份到上传Buffer环境，在Buffer环境做一个数据恢复性较验，最终把整个信息更新到我们数据库里，来后续供我们备份恢复或者集群构建的时候使用。 高可用架构
关于高可用，我们主要还是传统型的HA方案。 整个公司多个机房之间部署了内部DNS解析服务，所有的业务和DB之间的交互全部都通过DNS来做。整个基本的架构就是MHA加半同步。MHA提供原有功能对DNS做支持。运营解析会有对应接口，我们切完之后可以实时更新DNSCache，让它生效，这样可以保证切换时间对业务影响比较小。对于SQLServer，我们引入了AlwaysON来实现秒级HA方案。 未来我们主要考虑基于MySQL集群的一些技术，以及分布式数据库技术来实现真正的高可用方案的升级换代。 SQL实时分析
SQL查询的分析，目前我们通过MYSQL的Slowlog以及实时查询采样来进行实时分析。整个实现方案通过HEKA组件，我们可以把日志流做实时采集，然后推到Kafka。另外，我们把TiDB的SQLParser剥离出来，用在这个地方。消费端主要做格式化和信息落地，落地完成之后做统计分析，除此之外就是可视化。 HEKA实时采集
这是大家都很熟悉的Slowlog的格式，在Slowlog里的SQL就是这个样子。
这块主要对Slowlog按照一定的规则做split，把split内容用一套正则做模式匹配，把对应的关键指标提取出来，最后就形成了这个格式。这个可以直接的推到kafka，然后消费端对信息进行解析。
这是一个实时的SQL信息，我们用的组件vc-mysql-sniffer，可以生成固定的日志格式，这个日志格式分析完之后就是这个样子。 最终我们可以拿到SQL的执行时间，SQL的来源以及SQL执行的Database等信息。把这些信息实时的推到Kafka之后，就可以做相关的消费和解析。 SQL实时分析
这是我们解析的架构，由HEKA把Slowlog和我们采集的SQL的Log实时化的推到Kafka，Kafka把这些信息推到消息系统。我们在消费端实现了信息的消费，然后通过parser做解析，生成特定的格式进行落库，落到我们的MetaDB，再通过MetaDB上的计算任务做统计。后续我们可能会把美团开发的SQLAdviser引入到这个流程。ErrorLog也是通过同样的机制采到ELK里，供我们后续做一些相关的分析使用。 数据设施——需求
数据传输的类型主要是全备和增量;功能需求主要包括数据脱敏、抽取任务的延迟情况、结构变更感知和异构传输同步。另外，整个系统要简单、灵活，让DBA能够解决常见的问题，能够很快的做响应。 CDC获取及技术选型
关于变化的数据获取，常见方案有这几种,日志解析，用Trigger或类似方式记录数据变更，还有一种就是基于时序的SQL逻辑抽取。我们采用的方案有两个，一个是逻辑抽取(AutoLine)和BinLog解析。 AutoLine(逻辑抽取) ——逻辑复制
AutoLine本质上是一个分布式的调度系统。 如果站到一个表的数据角度来看，整个时序就是这样的一个情况，不断的有数据在变化。 这些信息怎么获取、抽取、怎么把它迁移到需求地呢? 在一个点对整个表做一次历史数据的抽取，之后根据它的数据修改时间把它的增量数据抽取出来，把增量部分落置到对端，每一张表都是这样的逻辑。 如果表特别多的时候，也就是多个任务做小单元化的数据抽取，就把所有的单元变成任务，所有的任务都可以被调度。实现的方式其实很简单，增量的同步肯定要获取增量的数据，我们实验的这套系统就可以支持异构的数据库，并且它还可以按需扩容和故障自愈。
整个系统架构本质上是调度系统，基于Celery异步任务框架来实现的。系统设计的时候会有不同的优先级队列。 下边的Worker执行每个任务单元。Worker是可以人为控制的，可以根据任务量判断给多少Worker。 现在我们的系统分了全量、增量，增量里面又分为分钟级和小时级的调度，因为每个组的调度频率是单独可控的，所以只要调度正常，每个分组里的任务状态正常，并且不断的有Worker来执行各种任务的小时调度单元，就可以实现整个数据的迁移。 Worker在执行一个任务片的时候，任务片可能会因为意外情况导致失败。于是有了任务片故障自愈功能。任务片出现了问题之后，它的状态会自动归为可调度状态。调度完成之后会更新任务的元信息来表示数据迁移到了哪个时间点。 结构感知是一个逻辑抽取，不适合做结构感知。所以，我们基于这套框架做了结构对比度的功能，它会定期的校验任务的主库和配置的信息是否对等，如果不对等会触发一个结构同步动作，然后进行更新。 所有的任务在调度的过程中都是互相独立的，每一个任务都可能会延迟，这个延迟时间在做计算的时候是有要求的。我们会根据它所在组的调度区间对它做延迟校验，如果它延迟了，我们会把相关的信息反馈到系统层面，让相关同学去处理。
通过观察我们调度系统的界面，我们可以实时监控任务执行情况。 在增量的情况下，任务执行效率很高，几秒钟之内就可以将任务片迁移到目标库。 日志解析——技术选型
对于技术选型，开源组件有很多，比如AlibabaCanal、LinkinDATABUS、Tungstenreplicator、MaxScaleCDC等等。通过评估,选择了自主开发，用Python(团队比较熟悉)来实现日志的解析。 日志解析 整个系统有几个核心的组件，第一个是日志解析，也就是把自己伪装成一个Slave，然后不断的获取Binlog的Stream里面的Event来做相关的处理，它会把Event的数据换成Json格式，序列化后投递到Kafka。 在整个解析中，我们加入了一个幂等消息分发。在异常的时候，Kafka因为一些异常的情况会导致消息重发，因此我们为每个消息生成了一个MD5值，消息端可以基于这个值做消息的幂等性校验。 还有一个是解析端高可用，就是我们在做日志解析的时候，如果我的主库或者解析源挂掉，可以换到下一个节点去做解析。 快照处理
做数据接入的时候，会需要一个历史数据，于是我们引入了快照处理的模块。这个模块利用了一个MYSQL特性，因为我们使用的版本是Percona，Percona把ConsistentSnapshot从MariaDB取过来，在此基础上实现了一个session克隆。当开多个线程的时候，可以用同一个Snapshot去抽取，实现真正的并发。 快照的创建，首先连接数据库要开启RR模式，然后通过STARTTRANSACTIONWITHCONSISTENTSNAPSHOT命令开启快照，这个快照可以拿到Binlog的位点，然后通过函数可以拿到当前连接的sessionid。 日志应用 当Snapshot、Binlog都存在的情况下，Apply端消费对应任务的topic，处理数据的Snapshot，然后做Apply增量。因为已经有位点了，每一个Json消息里面都会包含消息对应的Binlog的位置和它的file，这样就可以做增量的消费，在消费过程中，如果对数据准确要求很高，可以对每一个消息做校验。 系统结构
这是当前系统的架构，有Dumper解析模块，还有Snapshot，主要做集备做并发执行，把消息以同样的格式提供到消息缓冲Kafka系统，消费端就可以基于Snapshot加解析端增量来实现实时化的消费。 目前的消息端可以支持这几个方面： SQLServer、MySQL 实时计算平台 缓存更新策略 搜索引擎索引的实时更新