美团数据库运维自动化系统构建之路

清疚 2022-07-16 01:11 168阅读 0赞

【目录】

*  构建前的苦恼
    
     *  数据库运维的多、杂、烦
 *  构建中的坎坷和思考
    
     *  第一次吃螃蟹：1.0版系统
     *  吃螃蟹之后的反思
     *  2.0版系统的架构设计&典型功能实现案例（三个）
 *  构建后的效果&后期计划

--------------------

### 构建前的苦恼——一线运维DBA ###

首先说一下数据库运维自动化系统构建前，运维DBA都有哪些烦恼？

这是我们的一线运维DBA的小团，它每天需要对接很多的RD（Research&Development 研发）的需求。从我们现在的系统统计来看，使用我们平台系统的RD大概是一千五六百人，我们的人数是RD人数的十分之一不到。我们每个DBA对接的RD需求还是非常多的。新业务的上线，RD需要申请新的数据库集群。随着业务的发展，比如：数据库的流量大了，需要拆分了，都需要DBA手动去做。第三个是SQL的审核和上线，SQL会不会有什么问题，可能他测试环境OK，但是到了线上会有各种各样的问题。第四个是变更、升级。第五个是备份，不然的话，RD把数据写坏了，你就没地方找了，再就是帐号和安全，虚IP的维护，DNS、MySQL本身的维护，还有数据一致性，包括RD提的一些问题的排查，自身报警的处理。这就是我们一线运维的DBA，小团每天需要干很多的事情，这些事情都很重复，相信大家在座的有DBA的话，肯定是每天都会遇到我列的这些事情中的一个或多个。

![图片描述][20160926112705427]

### 构建前的苦恼——手动运维的烦恼 ###

接下来，我们先看一下美团点评初期数据库系统的架构：一开始是两层的架构，在主从库的基础上配置读写DNS，后来引入LVS。这个两层或者三层的数据库架有什么问题呢？

比如底层的数据库做切换了，上层的DNS配置也要变更，生效到各个机房，几分钟过去了……

RD说：“这个不行，你不能这么搞，忍不了”。

所以说，这样的数据库架构在切换或者从库上下线流量的时候，都会导致业务的报错，业务接受不了。

第二个是多：重复没有成长，你让一个DBA一开始做搭建、扩容、拆分、切换，他们可能觉得很有新鲜感和成就感，但是你让他做了上百次甚至上千次之后他们觉得这个没有成长。

第三个是杂：经常被打断，有报警处理的时候需要立马处理，RD找到你说这个问题必须马上、立刻处理，所以经常在做一些事情的时候被打断，总感觉自己在做杂事。

最后一个烦：RD经常不按照规范做事，包括上线一些大SQL、慢查询。程序不加重试，在网络抖动的时候，发现数据库怎么连接断了？他就会找到你。还有一些误操作，前几天有一个RD半夜打电话跟我说，线上数据误删除了需要恢复，通过我们平台去Delete数据的话，是很好恢复的，但是他说不好意思，我通过帐号直连线上删了数据。有些明白的RD会不好意思，知道数据不好恢复；但是，有些RD会说：“你DBA就是干这个事儿的，你就是得帮我恢复数据。”

大家很郁闷，在没有自动化运维系统之前的DBA还是非常苦恼的。

![图片描述][20160926112726350]

### 构建中的坎坷和思考——1.0版系统设计之初的考虑 ###

以上讲完了数据库运维自动化系统构建前DBA的苦恼，接下来说一说我们如果想去构建一套数据库自动化运维系统应该从哪里开始着手，我这里列的都是非常重要的。

第一个就是CMDB，如果你做的自动化系统中没有CMDB，那么，我觉得你做的自动化系统就不叫自动化系统。做自动化其实就是做标准化，这样的话，你在做自动化运维的时候，CMDB可以很方便的让你查询到信息，对业务进行合理的描述，这样的话有一个基本的地方，其实就是数据标准，我后面会说。

第二个就是你想一想在你做自动化运维系统之前，你整个公司或者RD的需求、DBA的需求，你需要做哪些自动化。美团初期只做了三个，在线DDL，数据库帐号申请和慢查询。有些RD或者DBA经常出去听一些会，比如腾讯讲蓝鲸，阿里讲鲁班，我们回去搞一套这么大的，其实没有必要，你们公司需要什么，你迫切需要的应该最先做，先把系统搭起来，再迭代。这里我给大家说个经验就是，可以先从DBA内部入手，再推广到RD。

第三个就是开发人员和成本，当时2015年初期的时候，美团App的DBA只有4个人，那时候既没有FE，也没有后台做开发的，这个时候就需要考虑到开发会有一些人员和成本的问题。会想，我是不是招一个人或者招两个人？其实没有必要，你可以放眼整个公司看一看，有没有共用的平台或者资源给你使用，这样更快，更便利的让你搭建平台。

最后就是开发形式，我们整个大的运维部是有开发人员相关资源的，我们找到他们去帮我们做一些页面，这样的话，你就会迅速的搭建你的1.0版本。

以上就是我要说的四点。

![图片描述][20160926112740168]

### 构建中的坎坷和思考——1.0版系统架构设计&使用情况 ###

大家可以看一下我们1.0版系统的整体框图，用户就不说了，前端模块主要是Django+MVC的方式，前端开发是不懂DBA业务的，他们需要做什么事情呢？他们把用户提交的任务写到数据库的task表中，我们后台的DBA去写一些脚本，去把前端提交的任务拉出来，拉出来之后如果有日志，会反写到task表里，这就是我们1.0版的架构，非常的简单，但是也是非常的实用，右边这个图是我们1.0版的效果，其实我后来加了DML，一开始只有DDL，业务他只需要选择他所需要变更的SQL类型之后，提交到后端DB的task表。后台会有一个常驻内存的进程，扫描这个DB，去发现当前有没有需要我去执行的任务，如果有就拉出去执行，执行的过程中会有一些日志，会回填到这个DB中，前端从DB拉去日志信息，就可以展示了。当时的效果，日均的订单是1840，2015年初，公司正是快速增长期的时候，现在应该比这个稍微少一点，当时使用人数大概600人，虽然是很简单的一套架构，但是使用的人数还是非常多。

![图片描述][20160926112753960]

### 构建中的坎坷和思考——1.0版的反思 ###

1.0版的系统做完了之后为什么做2.0版的系统呢？

不是说1.0版的系统不好，或者使用的人少，随着美团的发展你的标准化程度就慢慢得满足不了要求，所以我们会反思1.0版的一些问题，开始去做2.0版的系统。

1.0版有什么问题呢？

首先是前瞻模块重，开发人员很多，因为我们当时都是公用开发人员，开发人员很多，依赖也非常多，其实我开发习惯不太喜欢依赖什么太多的框架、组建，这样的话感觉很重，可能导致你代码的迁移、扩展性差。

第二个是没有接口化，RD不方便接入，很深刻的一个例子就是，有一个业务，他可能到某天的凌晨需要建跟时间相关的表，需要删表、建表，他每次都等到凌晨的时候去平台提交去做，他觉得很辛苦，于是就问我：“你们有没有接口让我去调，我写个脚本到那个时间就把我的表建上，因为每个时间表结构都是一样的”。如果你的平台没有接口化很不方便，特别有一些需要定期跑的业务。

第三个就是开发周期长、成本高，得跟他们沟通，需求调整复杂。当然它主要在高并发、高性能上很差，原因是什么？因为后台是一个常驻内存的进程，我当时只起了大概可能是6个线程就跑了，并发的话只能跑6个，我们2.0版的系统你想跑多少个就跑多少个，我一会儿给大家介绍一下怎么做的，不易扩展，这个也不方便扩展，后台的任务就一个，挂了就挂了，图象化做的也不好，毕竟是找人家帮我们做的，效果也不是太好。这个是我们为什么做2.0下定决心的一个原因吧！

最后就是任务的不可干预性，有一个改表操作，改到一半不想改了，这时候需要DBA上去手动操作，且不能暂停、回滚，2.0版的支持。

![图片描述][20160926112808449]

### 构建中的坎坷和思考——2.0版架构设计 ###

随着业务的发展，1.0版系统已经不能满足我们现在的需求，我们就做了2.0版。

2.0版需要遵循三个方面：标准化、自助化、自动化。

第一个标准化，指的是：接口标准、数据标准、流程标准。接口标准。你不能说，我的平台（WEB前端）提交的是一种方式，API接口提交是另一种方式，这是不行的。数据标准，就是CMDB，一定要准，一定要实时得更新，不然整个上层，它是基石，整个上面的框架搭起来都是白费的。流程标准，你需要制定ABCD各种各样的流程，很多DBA，他有自己的方式、方法。比如说对于拆分来说，A有它的方法，B有它的方法，可能都能达到目的，但是标准化，只能用一种方式。

第二个自助化，操作自助，只要能放给RD自主操作的就自主操作。问题定位的自助，RD碰到了数据库相关的问题，不是第一时间找DBA，而是第一时间在你平台上可以看到现在数据库的状况，定位到现在数据库的问题，去操作相关业务逻辑解决问题。

第三个自动化，高可用和报警自动处理。高可用，从库宕机你可以把它剔掉；报警自动处理，对于收到报警看一眼，后台有报警自动处理的程序就给它处掉了。

这是我们需要遵循的三个化，标准化、自助化和自动化。

![图片描述][20160926112822121]

### 构建中的坎坷和思考——2.0版架构设计 ###

介绍2.0版系统整体的架构之前，我先给大家介绍一下两个开源的组件，第一个是RabbitMQ，这是一种应用程序对应用程序的通讯方法，这个端对于另一个端的通讯，它是通过这个端来发消息，另一个端接消息，从而连接了两个端，很简单，其实他的作用就是连接消息的桥梁，美团点评现在做的O2O，就是连接人和服务，你不需要自己找，你只需要在APP上操作就行了。对于消息队列，你只需要提交到对应的队列中去就行了。

![图片描述][20160926112836449]

### 构建中的坎坷和思考——2.0版架构设计 ###

第二个就是Celery，这个Rabbit的中文翻译是兔子，Celery翻译成中文就是芹菜，兔子和芹菜构建了我们2.0版系统。大家可以这么理解，Celery其实就是封装在消息队列上面一个非常好用的任务调度者，是基于Python开发的，他可以帮你干什么呢？可以帮你发任务，可以帮接任务，可以帮你定时的起任务，我今天凌晨2点拆分，可以白天提交，凌晨Celery帮你调度。它是对于消息中间件上面很好用的封装。

![图片描述][20160926112847793]

### 构建中的坎坷和思考——2.0版架构设计 ###

说完了以上两个开源的组建，我们接下来说整个2.0版系统的架构，一点点的放出来，首先是用户，通过前端的Web，他的所有的操作全部打到我们的API层，业务模块：脚本也好，系统也好，也是打到我们的API层，这样做到了接口的统一，后端的处理都是一样的，不管是任何人，对于我来说都是我的一个端。

API层它可以做两个事情，比如我想查询当前数据库的主从架构情况，当前服务里的数据库列表，那么API层直接跟CMDB交互获取数据并返回。第二种是需要后台做任务的，比如搭建，扩容，拆分这些都是任务，它们需要到后台的任务管理模块去做。任务管理模块会把任务分发下去。这中间会有CMDB。任务管理模块可以详细讲一下，这个就是刚才我所说的MQ的消息管道，这里是Celery，这里有两个Celery，你可以理解为它是MQ的封装，你只需要给Celery通信就可以了。TaskControl是挂载到整个消息中间件上面的一个任务处理者。它会生成父子进程去处理任务。

![图片描述][20160926112903090]

### 构建中的坎坷和思考——2.0版架构设计 ###

我刚才说的为什么任务是可以无限地增加，前提是在机器可以承载的情况下无限增加。第一步，TaskControl先fork出一个子进程，第二步，子进程1再fork出一个子进程，这个子进程2，是真正得做任务的进程，这个进程再调用任务执行脚本或者模块去进行任务操作。子进程1，它会把子进程2的一些信息，比如进程PID，回填到数据库里，子进程一1就退出了，子进程1退出之后，它跟子进程2的关系就断开了，这里要说一点，子进程1得忽略回收子进程，这时候子进程2就托管给了init进程，这样的话就生成了这么一个任务执行单元。任务执行单元只是需要自己去做任务，比如说它去做DDL，这个子进程2是父进程，会去做子进程的回收操作，任务日志的回填工作等。

![图片描述][20160926112917090]

### 构建中的坎坷和思考——2.0版架构设计 ###

最后的效果大家可以看到，就是右下角这样的，这个TaskControl，每次生成父子进程完成之后，它就回去从消息队列去拿新的任务，一台机器上，好多个父子进程，并发高的时候，这些任务会有一百多个，这样的话，大大提升了整个系统的并发性，正常的话，这里起6个子进程就够了，用来监听任务，生成任务执行单元。我看有些公司会起很多很多模块去处理，用这种技巧的话，就可以让任务的执行脱离整个任务系统。

这么做还有什么好处呢？在做升级或者整个系统挂了的时候：我们直接升级好了，系统挂了也没事，任务还是不受影响。机器挂了怎么办？这个就没办法了，机器挂了确实就挂掉了，上面的任务需要重新发起，可能需要人工的干预。

![图片描述][20160926112933247]