[[172019]]

美團點評技術(shù)沙龍由美團點評技術(shù)團隊主辦，每月一期。每期沙龍邀請美團點評及其它互聯(lián)網(wǎng)公司的技術(shù)專家分享來自一線的實踐經(jīng)驗，覆蓋各主要技術(shù)領(lǐng)域。

目前沙龍會分別在北京、上海和廈門等地舉行，要參加下一次最新沙龍活動?趕快關(guān)注微信公眾號“美團點評技術(shù)團隊”。

本次沙龍主要圍繞數(shù)據(jù)庫相關(guān)的主題，內(nèi)容包括美團數(shù)據(jù)庫自動化運維系統(tǒng)構(gòu)建、點評側(cè)MySQL自動化服務(wù)平臺RDS、美團數(shù)據(jù)庫中間件、和小米高級DBA帶來的Redis Cluster的大規(guī)模運維實踐。

講師簡介

寧龍，美團網(wǎng)高級DBA，現(xiàn)負責(zé)美團數(shù)據(jù)庫自動化運維系統(tǒng)的架構(gòu)和開發(fā)工作。

目錄

今天我主要分這幾個部分講：

• 第一部分是美團在數(shù)據(jù)庫自動化運維系統(tǒng)構(gòu)建前的煩惱，DBA手動運維DB的時候遇到的各種問題;
• 第二個是我們在構(gòu)數(shù)據(jù)庫運維自動化系統(tǒng)過程中的一些坎坷和思考，這里我會說我們的1.0版系統(tǒng)，還有1.0版的系統(tǒng)為什么要到2.0版的，以及現(xiàn)在2.0版系統(tǒng)在線上的使用情況，在2.0版系統(tǒng)的基礎(chǔ)上，我會給大家介紹三個典型的案例，可能大家平時會用到的;
• 最后說一下我們2.0版系統(tǒng)構(gòu)建之后線上跑的效果，以及我們做的后期改進的計劃，也可以說是3.0;
• Q&A環(huán)節(jié)。

構(gòu)建前的苦惱——一線運維DBA

首先說一下數(shù)據(jù)庫運維自動化系統(tǒng)構(gòu)建前，運維DBA都有哪些煩惱?

這是我們的一線運維DBA的小團，它每天需要對接很多的RD(Research&Development 研發(fā))的需求。從我們現(xiàn)在的系統(tǒng)統(tǒng)計來看，使用我們平臺系統(tǒng)的RD大概是一千五六百人，我們的人數(shù)是RD人數(shù)的十分之一不到。我們每個DBA對接的RD需求還是非常多的。新業(yè)務(wù)的上線，RD需要申請新的數(shù)據(jù)庫集群。隨著業(yè)務(wù)的發(fā)展，比如：數(shù)據(jù)庫的流量大了，需要拆分了，都需要DBA手動去做。第三個是SQL的審核和上線，SQL會不會有什么問題，可能他測試環(huán)境OK，但是到了線上會有各種各樣的問題。第四個是變更、升級。第五個是備份，不然的話，RD把數(shù)據(jù)寫壞了，你就沒地方找了，再就是帳號和安全，虛IP的維護，DNS、MySQL本身的維護，還有數(shù)據(jù)一致性，包括RD提的一些問題的排查，自身報警的處理。這就是我們一線運維的DBA，小團每天需要干很多的事情，這些事情都很重復(fù)，相信大家在座的有DBA的話，肯定是每天都會遇到我列的這些事情中的一個或多個。

構(gòu)建前的苦惱——手動運維的煩惱

接下來，我們先看一下美團點評初期數(shù)據(jù)庫系統(tǒng)的架構(gòu)：一開始是兩層的架構(gòu)，在主從庫的基礎(chǔ)上配置讀寫DNS，后來引入LVS。這個兩層或者三層的數(shù)據(jù)庫架有什么問題呢?

比如底層的數(shù)據(jù)庫做切換了，上層的DNS配置也要變更，生效到各個機房，幾分鐘過去了……

RD說：“這個不行，你不能這么搞，忍不了”。

所以說，這樣的數(shù)據(jù)庫架構(gòu)在切換或者從庫上下線流量的時候，都會導(dǎo)致業(yè)務(wù)的報錯，業(yè)務(wù)接受不了。

第二個是多：重復(fù)沒有成長，你讓一個DBA一開始做搭建、擴容、拆分、切換，他們可能覺得很有新鮮感和成就感，但是你讓他做了上百次甚至上千次之后他們覺得這個沒有成長。

第三個是雜：經(jīng)常被打斷，有報警處理的時候需要立馬處理，RD找到你說這個問題必須馬上、立刻處理，所以經(jīng)常在做一些事情的時候被打斷，總感覺自己在做雜事。

最后一個煩：RD經(jīng)常不按照規(guī)范做事，包括上線一些大SQL、慢查詢。程序不加重試，在網(wǎng)絡(luò)抖動的時候，發(fā)現(xiàn)數(shù)據(jù)庫怎么連接斷了?他就會找到你。還有一些誤操作，前幾天有一個RD半夜打電話跟我說，線上數(shù)據(jù)誤刪除了需要恢復(fù)，通過我們平臺去Delete數(shù)據(jù)的話，是很好恢復(fù)的，但是他說不好意思，我通過帳號直連線上刪了數(shù)據(jù)。有些明白的RD會不好意思，知道數(shù)據(jù)不好恢復(fù);但是，有些RD會說：“你DBA就是干這個事兒的，你就是得幫我恢復(fù)數(shù)據(jù)。”

大家很郁悶，在沒有自動化運維系統(tǒng)之前的DBA還是非?？鄲赖摹?/p>

構(gòu)建中的坎坷和思考——1.0版系統(tǒng)設(shè)計之初的考慮

以上講完了數(shù)據(jù)庫運維自動化系統(tǒng)構(gòu)建前DBA的苦惱，接下來說一說我們?nèi)绻肴?gòu)建一套數(shù)據(jù)庫自動化運維系統(tǒng)應(yīng)該從哪里開始著手，我這里列的都是非常重要的。

第一個就是CMDB，如果你做的自動化系統(tǒng)中沒有CMDB，那么，我覺得你做的自動化系統(tǒng)就不叫自動化系統(tǒng)。做自動化其實就是做標(biāo)準(zhǔn)化，這樣的話，你在做自動化運維的時候，CMDB可以很方便的讓你查詢到信息，對業(yè)務(wù)進行合理的描述，這樣的話有一個基本的地方，其實就是數(shù)據(jù)標(biāo)準(zhǔn)，我后面會說。

第二個就是你想一想在你做自動化運維系統(tǒng)之前，你整個公司或者RD的需求、DBA的需求，你需要做哪些自動化。美團初期只做了三個，在線DDL，數(shù)據(jù)庫帳號申請和慢查詢。有些RD或者DBA經(jīng)常出去聽一些會，比如騰訊講藍鯨，阿里講魯班，我們回去搞一套這么大的，其實沒有必要，你們公司需要什么，你迫切需要的應(yīng)該最先做，先把系統(tǒng)搭起來，再迭代。這里我給大家說個經(jīng)驗就是，可以先從DBA內(nèi)部入手，再推廣到RD。

第三個就是開發(fā)人員和成本，當(dāng)時2015年初期的時候，美團App的DBA只有4個人，那時候既沒有FE，也沒有后臺做開發(fā)的，這個時候就需要考慮到開發(fā)會有一些人員和成本的問題。會想，我是不是招一個人或者招兩個人?其實沒有必要，你可以放眼整個公司看一看，有沒有共用的平臺或者資源給你使用，這樣更快，更便利的讓你搭建平臺。

最后就是開發(fā)形式，我們整個大的運維部是有開發(fā)人員相關(guān)資源的，我們找到他們?nèi)臀覀冏鲆恍╉撁?，這樣的話，你就會迅速的搭建你的1.0版本。

以上就是我要說的四點。

構(gòu)建中的坎坷和思考——1.0版系統(tǒng)架構(gòu)設(shè)計&使用情況

大家可以看一下我們1.0版系統(tǒng)的整體框圖，用戶就不說了，前端模塊主要是Django+MVC的方式，前端開發(fā)是不懂DBA業(yè)務(wù)的，他們需要做什么事情呢?他們把用戶提交的任務(wù)寫到數(shù)據(jù)庫的task表中，我們后臺的DBA去寫一些腳本，去把前端提交的任務(wù)拉出來，拉出來之后如果有日志，會反寫到task表里，這就是我們1.0版的架構(gòu)，非常的簡單，但是也是非常的實用，右邊這個圖是我們1.0版的效果，其實我后來加了DML，一開始只有DDL，業(yè)務(wù)他只需要選擇他所需要變更的SQL類型之后，提交到后端DB的task表。后臺會有一個常駐內(nèi)存的進程，掃描這個DB，去發(fā)現(xiàn)當(dāng)前有沒有需要我去執(zhí)行的任務(wù)，如果有就拉出去執(zhí)行，執(zhí)行的過程中會有一些日志，會回填到這個DB中，前端從DB拉去日志信息，就可以展示了。當(dāng)時的效果，日均的訂單是1840，2015年初，公司正是快速增長期的時候，現(xiàn)在應(yīng)該比這個稍微少一點，當(dāng)時使用人數(shù)大概600人，雖然是很簡單的一套架構(gòu)，但是使用的人數(shù)還是非常多。

構(gòu)建中的坎坷和思考——1.0版的反思

1.0版的系統(tǒng)做完了之后為什么做2.0版的系統(tǒng)呢?

不是說1.0版的系統(tǒng)不好，或者使用的人少，隨著美團的發(fā)展你的標(biāo)準(zhǔn)化程度就慢慢得滿足不了要求，所以我們會反思1.0版的一些問題，開始去做2.0版的系統(tǒng)。

1.0版有什么問題呢?

首先是前瞻模塊重，開發(fā)人員很多，因為我們當(dāng)時都是公用開發(fā)人員，開發(fā)人員很多，依賴也非常多，其實我開發(fā)習(xí)慣不太喜歡依賴什么太多的框架、組建，這樣的話感覺很重，可能導(dǎo)致你代碼的遷移、擴展性差。

第二個是沒有接口化，RD不方便接入，很深刻的一個例子就是，有一個業(yè)務(wù)，他可能到某天的凌晨需要建跟時間相關(guān)的表，需要刪表、建表，他每次都等到凌晨的時候去平臺提交去做，他覺得很辛苦，于是就問我：“你們有沒有接口讓我去調(diào)，我寫個腳本到那個時間就把我的表建上，因為每個時間表結(jié)構(gòu)都是一樣的”。如果你的平臺沒有接口化很不方便，特別有一些需要定期跑的業(yè)務(wù)。

第三個就是開發(fā)周期長、成本高，得跟他們溝通，需求調(diào)整復(fù)雜。當(dāng)然它主要在高并發(fā)、高性能上很差，原因是什么?因為后臺是一個常駐內(nèi)存的進程，我當(dāng)時只起了大概可能是6個線程就跑了，并發(fā)的話只能跑6個，我們2.0版的系統(tǒng)你想跑多少個就跑多少個，我一會兒給大家介紹一下怎么做的，不易擴展，這個也不方便擴展，后臺的任務(wù)就一個，掛了就掛了，圖象化做的也不好，畢竟是找人家?guī)臀覀冏龅模Ч膊皇翘?。這個是我們?yōu)槭裁醋?.0下定決心的一個原因吧!

最后就是任務(wù)的不可干預(yù)性，有一個改表操作，改到一半不想改了，這時候需要DBA上去手動操作，且不能暫停、回滾，2.0版的支持。

構(gòu)建中的坎坷和思考——2.0版架構(gòu)設(shè)計

隨著業(yè)務(wù)的發(fā)展，1.0版系統(tǒng)已經(jīng)不能滿足我們現(xiàn)在的需求，我們就做了2.0版。

2.0版需要遵循三個方面：標(biāo)準(zhǔn)化、自助化、自動化。

第一個標(biāo)準(zhǔn)化，指的是：接口標(biāo)準(zhǔn)、數(shù)據(jù)標(biāo)準(zhǔn)、流程標(biāo)準(zhǔn)。接口標(biāo)準(zhǔn)。你不能說，我的平臺(WEB前端)提交的是一種方式，API接口提交是另一種方式，這是不行的。數(shù)據(jù)標(biāo)準(zhǔn)，就是CMDB，一定要準(zhǔn)，一定要實時得更新，不然整個上層，它是基石，整個上面的框架搭起來都是白費的。流程標(biāo)準(zhǔn)，你需要制定ABCD各種各樣的流程，很多DBA，他有自己的方式、方法。比如說對于拆分來說，A有它的方法，B有它的方法，可能都能達到目的，但是標(biāo)準(zhǔn)化，只能用一種方式。

第二個自助化，操作自助，只要能放給RD自主操作的就自主操作。問題定位的自助，RD碰到了數(shù)據(jù)庫相關(guān)的問題，不是第一時間找DBA，而是第一時間在你平臺上可以看到現(xiàn)在數(shù)據(jù)庫的狀況，定位到現(xiàn)在數(shù)據(jù)庫的問題，去操作相關(guān)業(yè)務(wù)邏輯解決問題。

第三個自動化，高可用和報警自動處理。高可用，從庫宕機你可以把它剔掉;報警自動處理，對于收到報警看一眼，后臺有報警自動處理的程序就給它處掉了。

這是我們需要遵循的三個化，標(biāo)準(zhǔn)化、自助化和自動化。

構(gòu)建中的坎坷和思考——2.0版架構(gòu)設(shè)計

介紹2.0版系統(tǒng)整體的架構(gòu)之前，我先給大家介紹一下兩個開源的組件，第一個是RabbitMQ，這是一種應(yīng)用程序?qū)?yīng)用程序的通訊方法，這個端對于另一個端的通訊，它是通過這個端來發(fā)消息，另一個端接消息，從而連接了兩個端，很簡單，其實他的作用就是連接消息的橋梁，美團點評現(xiàn)在做的O2O，就是連接人和服務(wù)，你不需要自己找，你只需要在APP上操作就行了。對于消息隊列，你只需要提交到對應(yīng)的隊列中去就行了。

構(gòu)建中的坎坷和思考——2.0版架構(gòu)設(shè)計

第二個就是Celery，這個Rabbit的中文翻譯是兔子，Celery翻譯成中文就是芹菜，兔子和芹菜構(gòu)建了我們2.0版系統(tǒng)。大家可以這么理解，Celery其實就是封裝在消息隊列上面一個非常好用的任務(wù)調(diào)度者，是基于Python開發(fā)的，他可以幫你干什么呢?可以幫你發(fā)任務(wù)，可以幫接任務(wù)，可以幫你定時的起任務(wù)，我今天凌晨2點拆分，可以白天提交，凌晨Celery幫你調(diào)度。它是對于消息中間件上面很好用的封裝。

構(gòu)建中的坎坷和思考——2.0版架構(gòu)設(shè)計

說完了以上兩個開源的組建，我們接下來說整個2.0版系統(tǒng)的架構(gòu)，一點點的放出來，首先是用戶，通過前端的Web，他的所有的操作全部打到我們的API層，業(yè)務(wù)模塊：腳本也好，系統(tǒng)也好，也是打到我們的API層，這樣做到了接口的統(tǒng)一，后端的處理都是一樣的，不管是任何人，對于我來說都是我的一個端。

API層它可以做兩個事情，比如我想查詢當(dāng)前數(shù)據(jù)庫的主從架構(gòu)情況，當(dāng)前服務(wù)里的數(shù)據(jù)庫列表，那么API層直接跟CMDB交互獲取數(shù)據(jù)并返回。第二種是需要后臺做任務(wù)的，比如搭建，擴容，拆分這些都是任務(wù)，它們需要到后臺的任務(wù)管理模塊去做。任務(wù)管理模塊會把任務(wù)分發(fā)下去。這中間會有CMDB。任務(wù)管理模塊可以詳細講一下，這個就是剛才我所說的MQ的消息管道，這里是Celery，這里有兩個Celery，你可以理解為它是MQ的封裝，你只需要給Celery通信就可以了。TaskControl是掛載到整個消息中間件上面的一個任務(wù)處理者。它會生成父子進程去處理任務(wù)。

構(gòu)建中的坎坷和思考——2.0版架構(gòu)設(shè)計

我剛才說的為什么任務(wù)是可以無限地增加，前提是在機器可以承載的情況下無限增加。第一步，TaskControl先fork出一個子進程，第二步，子進程1再fork出一個子進程，這個子進程2，是真正得做任務(wù)的進程，這個進程再調(diào)用任務(wù)執(zhí)行腳本或者模塊去進行任務(wù)操作。子進程1，它會把子進程2的一些信息，比如進程PID，回填到數(shù)據(jù)庫里，子進程一1就退出了，子進程1退出之后，它跟子進程2的關(guān)系就斷開了，這里要說一點，子進程1得忽略回收子進程，這時候子進程2就托管給了init進程，這樣的話就生成了這么一個任務(wù)執(zhí)行單元。任務(wù)執(zhí)行單元只是需要自己去做任務(wù)，比如說它去做DDL，這個子進程2是父進程，會去做子進程的回收操作，任務(wù)日志的回填工作等。

構(gòu)建中的坎坷和思考——2.0版架構(gòu)設(shè)計

最后的效果大家可以看到，就是右下角這樣的，這個TaskControl，每次生成父子進程完成之后，它就回去從消息隊列去拿新的任務(wù)，一臺機器上，好多個父子進程，并發(fā)高的時候，這些任務(wù)會有一百多個，這樣的話，大大提升了整個系統(tǒng)的并發(fā)性，正常的話，這里起6個子進程就夠了，用來監(jiān)聽任務(wù)，生成任務(wù)執(zhí)行單元。我看有些公司會起很多很多模塊去處理，用這種技巧的話，就可以讓任務(wù)的執(zhí)行脫離整個任務(wù)系統(tǒng)。

這么做還有什么好處呢?在做升級或者整個系統(tǒng)掛了的時候：我們直接升級好了，系統(tǒng)掛了也沒事，任務(wù)還是不受影響。機器掛了怎么辦?這個就沒辦法了，機器掛了確實就掛掉了，上面的任務(wù)需要重新發(fā)起，可能需要人工的干預(yù)。

構(gòu)建中的坎坷和思考——2.0版功能實現(xiàn)案例一：集群搭建

說完了上面的整體架構(gòu)之后我會給大家講三個案例：

第一個案例是我們現(xiàn)有的集群的搭建過程，我先說一下我們線上跑的整體數(shù)據(jù)庫的四層架構(gòu)：第一層是業(yè)務(wù)層，業(yè)務(wù)層，訪問我們都是通過DNS，DNS下面掛的是虛IP層，虛IP層下面會掛我們的中間件，atlas，每個機房會有并行得部署多個，最下面掛的是數(shù)據(jù)庫主從架構(gòu)，這個是現(xiàn)在美團用的線上數(shù)據(jù)庫主流架構(gòu)。

構(gòu)建中的坎坷和思考——2.0版功能實現(xiàn)案例一：集群搭建

現(xiàn)在開始說搭建流程，我說了這么多，大家沒看到我們系統(tǒng)的廬山真面目，這個是我們2.0版本系統(tǒng)的頁面。對于搭建，DBA需要先點擊一下服務(wù)組初始化，首先需要去創(chuàng)建一個服務(wù)，我們每一個DB集群在數(shù)據(jù)庫里面都是有一個標(biāo)識的，被稱做服務(wù)組。

構(gòu)建中的坎坷和思考——2.0版功能實現(xiàn)案例一：集群搭建

接著，需要選擇你要搭建的類型，我剛才說的四層的架構(gòu)是這里的A套餐，但是如果說是一些統(tǒng)計、運營類的庫，我們可能會用到BCD套餐，后面三個套餐用的比較少。當(dāng)然因為這里有四個，可能涉及到的情況非常多：有沒有atlas、有沒有MGW、有無DNS……可能至少得有八種情況。有時候大家做自動化的時候，就會遇到矛盾，這種情況怎么辦?現(xiàn)在給DBA的四個套餐其實就是制定標(biāo)準(zhǔn)，就是你搭建的數(shù)據(jù)庫集群，都是按照我的標(biāo)準(zhǔn)來的，只有這四種，DBA就說了：你有時候不滿足我的情況，DBA就要手動去做，怎么辦?

構(gòu)建中的坎坷和思考——2.0版功能實現(xiàn)案例一：集群搭建

你的系統(tǒng)不能夠兼容DBA的需求的時候怎么辦呢?這個時候確實很麻煩，它手動運維在后面搞一搞，很有可能造成你的CMDB信息缺失等問題，這個就很麻煩。

遇到這種情況，我就告訴他們：“OK，我整個平臺兼容你所有的操作”。

很簡單，他說了：“我想mysql上面不掛中間件，我想直接掛MGW。”

可以。但是你得分兩步做：第一步你是在平臺，你先把D套餐給它搭起來，你到我們MGW和DNS里面去申請。你在這個管理功能就可以做。也就是說，做流程化或者是標(biāo)準(zhǔn)化的時候，你把流程制定出來的時候，也要考慮到靈活性，你要兼容它可能存在的所有情況，我們把線上相關(guān)的所有組件都做了管理，MGW有管理，DNS有管理，包括其他的日志都有管理，細分的管理都有，你正常情況下按我的標(biāo)準(zhǔn)、按我的流程去走，你萬一涉及到特殊情況的話，你也可以在各個分組件的管理里把你想做的事情做完。這樣的話，就把整個DBA或者整個ID用戶都圈到你的整個平臺里面來了，而不是我的平臺今天只兼容一部分。這樣的話，大家做自動化起來會很費勁。 因為原來也是，原來我線上會有報警校驗線上CMDB的準(zhǔn)確性，如果線上CMDB的錯的話，可能非常麻煩。所以說，DBA在應(yīng)對RD的時候很苦惱，我們做自動化運維開發(fā)在應(yīng)對DBA的時候，也很苦惱，用這種方式就可以滿足他們了。

構(gòu)建中的坎坷和思考——2.0版功能實現(xiàn)案例一：集群搭建

在大家選完套餐之后就可以到這個界面了，做數(shù)據(jù)庫運維自動化系統(tǒng)有很多流程性的東西，你接下來需要走哪一步，選完套餐之后讓他選機器，你的監(jiān)控是什么，buffer pool多大，下面會給他展示一個實時的拓撲;你要把你的用戶當(dāng)小白鼠，你得告訴他現(xiàn)在長什么樣子了，不然的話他提交出錯了，又回來找你。

構(gòu)建中的坎坷和思考——2.0版功能實現(xiàn)案例一：集群搭建

第二個我們?nèi)ミx擇atlas，根據(jù)分組選擇atlas，就是數(shù)據(jù)庫中間件，選擇完之后就可以形成這樣的圖。

構(gòu)建中的坎坷和思考——2.0版功能實現(xiàn)案例一：集群搭建

第三步就是你去申請這個虛IP和域名了，這個虛IP層正常一個機房會有一個。一個虛IP上會掛多個atlas。

構(gòu)建中的坎坷和思考——2.0版功能實現(xiàn)案例一：集群搭建

到最后一步可能就是你需要新搭建集群的時候，需要給RD申請一個DB，申請一個帳號，讓他可以訪問。

構(gòu)建中的坎坷和思考——2.0版功能實現(xiàn)案例一：集群搭建

這樣形成最后一個大的JSON，讓DBA去做確認，你申請的服務(wù)名稱、你當(dāng)前數(shù)據(jù)庫的機器、中間件的機器、你的虛IP層和域名，包括你的DB，會有一個整體的拓撲圖，這樣的話。然后把整個的參數(shù)，所有的需要你完成這個數(shù)據(jù)庫集群搭建的參數(shù)合成一個大的JSON。發(fā)到API層，API層會做參數(shù)校驗，你當(dāng)前搭建的參數(shù)是否滿足系統(tǒng)的要求，如果滿足要求，就會發(fā)到后臺的流程引擎中，就是后臺系統(tǒng)去做任務(wù)。做任務(wù)的時候，大家可能說，我需不需要有什么高深的語言，這個無所謂了，你可以是腳本，也可以是程序。我們現(xiàn)在線上，搭建的話用的還是DBA他們一開始寫的搭建腳本，只需要把腳本改造一下，輸入，輸出標(biāo)準(zhǔn)化一下，你能夠識別腳本的輸出輸入就行了。

大家說自動化很艱辛，很艱難。其實身邊有很多的資源就是DBA手中平時做的一些腳本，有一些腳本可能DBA自己用，寫的不太好。但是他本身，他是有非常大的價值的，因為他是長年累月改過的，可能第一版不行改第二版、第二版不行改第三版，他可能改了一年，他的整個腳本跑起來還是非常流利的，我們腳本搭建很穩(wěn)定得跑了10個月的時間，主要的原因是因為我們DBA很靠譜，積累的很多實用的腳本。有些純開發(fā)的人去做DBA的自動化系統(tǒng)，他很難理解DBA的需求，有時候DBA也講不清楚，所以通過你做系統(tǒng)，他做腳本的方式去合作，真的很靠譜。因為做出來的系統(tǒng)是非常穩(wěn)定的。

構(gòu)建中的坎坷和思考——2.0版功能實現(xiàn)案例二：在線表變更

說完了數(shù)據(jù)庫集群搭建這個案例，我們說第二個案例：在線表變更是怎么做的。首先批量的DDL或者DML打造我們的API層，我們API層會做兩個事情，第一個是語法檢測，語法檢測有兩種方式，一種是測試庫，一種是sqlparser;比如，對于autoddl的create操作，你可以在測試庫上建一下這個表，你就知道語法對不。或者是說alter操作，你可能先從線上把表結(jié)構(gòu)拉到測試環(huán)境，在測試庫上先建上，再把alter語句用到這個表上，你看alter能不能通過，這樣很方便就繞過了sqlparser。

但是，在這個時候，因為在做在線的DML的時候，你是需要給用戶備份的，方便用戶，萬一我誤操作了，可以去恢復(fù)，就必須進行sqlparser。第一步：你必須把update或者delete語句改寫成select，然后會去線上做查詢計劃，看一下explain的結(jié)果是否滿足我的要求，如果不滿足的話，就提示選擇，不是直接拒絕掉，沒有那么暴力，這個后面會說。所以說這個sqlparser，應(yīng)該也是一個比較基礎(chǔ)的難題，大家可以嘗試一下在源碼把這個sqlparser抽離出來，或者大家可以考慮去找一些已經(jīng)開源的sqlparser。第二個就是語義的檢測，是什么呢?也是標(biāo)準(zhǔn)化，就是RD提交的SQL是否滿足你的要求，比如命名的要求、必須要有主鍵索引，而且不能有重復(fù)的索引，對于DML來說，因為對于互聯(lián)網(wǎng)應(yīng)用來說會有很多的比如說客服給我們運營人員說，我的什么什么錯了，這個時候運營的人都會改這個數(shù)據(jù)庫，改動一般都是一兩行這種，所以我們設(shè)定一千行基本上能夠滿足大部分人的需求。然后在語法、語義提交通過之會到后臺的提交任務(wù)，剛才所說的2.0的系統(tǒng)，由后臺的任務(wù)執(zhí)行者去執(zhí)行，然后做在線的DDL。我們選擇的是開源的pt-online-schema-change，這個是一個開源工具，它做操作的時候，可以做到在線改表的時候不鎖表，當(dāng)然還會有一些其他的問題，這里不是我們今天所說的重點，大家如果以后有遇到這個工具有什么相關(guān)的問題都可以找我們，美團還是踩了非常多的坑，有比較多的經(jīng)驗。

構(gòu)建中的坎坷和思考——2.0版功能實現(xiàn)案例二：在線表變更

大家可以看看這是我們現(xiàn)在的在線表變更的提交頁面。這里也是先選業(yè)務(wù)，選完相關(guān)的業(yè)務(wù)，你選庫，選操作類型，我們這里會有一個業(yè)務(wù)高峰的描述，比如對于pt-online-schema-change在做表變更的時候，他會有一個數(shù)據(jù)拷貝的過程，所以說我們會有一個業(yè)務(wù)高峰，在業(yè)務(wù)高峰的時候RD發(fā)起的任務(wù)是不能被執(zhí)行的。還有任務(wù)操作時間區(qū)間，RD也可以選，比如我選今天晚上凌晨變更或者什么時候變更都是OK的，RD把他的SQL批量粘到這里。對于在線的分表，粘一個母表就行了，下面我們自動生成帶數(shù)字的語句會給他操作。這樣也方便我們后臺的處理，對于512的分表，我們只校驗第一個語法語義就行了，不然的話，會產(chǎn)生很多性能問題。

構(gòu)建中的坎坷和思考——2.0版功能實現(xiàn)案例二：在線表變更

講到這里大家肯定會有疑問，如果你在語法檢測或者語義檢測出問題的時候應(yīng)該怎么辦?我們不是非常暴力的把RD的請求直接拒絕掉。而是在這里，給了RD一個選擇：也就是說我們現(xiàn)在，大部分在線的表變更都是自動的，當(dāng)然有一些不滿足語法語義的單子，語法當(dāng)然不用說了，直接報錯給RD讓修改，對于語義來說，有些RD說，你幫我刪或者幫我改，我們可以接受延遲，這個時候我們讓RD選擇，你可以點繼續(xù)，把這個單子發(fā)給DBA，如果DBA說能執(zhí)行就可以執(zhí)行了，我們的在線表變更是手自一體的。我們要把RD所有的操作，都得圈到我們的平臺里去做，而不是說我語義不支持了，就找DBA手動去做。

構(gòu)建中的坎坷和思考——2.0版功能實現(xiàn)案例二：在線表變更

這里可以看到，遇到了語法或者語義檢測失敗之后，我們的平臺會給他報錯，并會給他一個詳細原因的解釋，你不能說錯了，而且你要直白得告訴RD為什么錯了;這樣的話可以提升RD的DBA能力。比如說這里長度，SQL語法問題，都會告訴他;這樣的話，他可能用問一次兩次，后面如果用多了，他就不會問了。

構(gòu)建中的坎坷和思考——2.0版功能實現(xiàn)案例二：在線表變更

這個就是我們整個任務(wù)執(zhí)行的一個詳情的單子，就是RD在提交完任務(wù)之后在這個頁面看到他任務(wù)執(zhí)行的詳細的信息，這上面是一些元信息，包括他提交的時間，他服務(wù)的信息，下面會有一個詳細的執(zhí)行日志發(fā)給他，你在做任務(wù)操作的時候，你把你的任務(wù)相關(guān)的數(shù)據(jù)實時回填到任務(wù)表里，前端只需要讀這個任務(wù)表就行了。

構(gòu)建中的坎坷和思考——2.0版功能實現(xiàn)案例三：高可用解決方案(MHA)

第三個案例是什么呢?就是我們的高可用的解決方案，上面已經(jīng)列了，美團現(xiàn)在用的是開源的MHA，一個很牛的日本人寫的。我這里大概介紹一下切換的過程，原理大家可以回去自己看，左邊是我們四層的架構(gòu)，我們現(xiàn)在整個MHA只運用于這四層的架構(gòu)，如果你不是這四層的架構(gòu)切換過程是不滿足的。對于主從的結(jié)構(gòu)這里會有監(jiān)控的哨兵，比如這個哨兵他發(fā)現(xiàn)現(xiàn)在主庫連不上了，這個時候，他不是說我就切換了，他是先聯(lián)系其他哨兵，不能相信謠言嘛，也要先打聽打聽我自己的判斷是不是對的，他會去聯(lián)系其他幾個哨兵，你們幫我看看當(dāng)前主庫是不是掛了，其他幾個哨兵跑回來跟他說主庫確實掛了，他便開始切換。

到了第2步，調(diào)MHA去做主從切換。切換完之后呢，他會通過API去改CMDB的信息，CMDB里面會描述數(shù)據(jù)庫的主從的架構(gòu)，描述完之后，他會去調(diào)接口，通知中間件變更主從信息，那么到3.2為止服務(wù)就恢復(fù)了。我們現(xiàn)在自動和手動做切換，時間都在10秒左右，如果RD程序有數(shù)據(jù)庫重試的話應(yīng)該是沒有影響的。切換完之后會到第4步，其實這里很簡單，就是告訴哨兵主從結(jié)構(gòu)變了，告訴他重新監(jiān)聽新的主從結(jié)構(gòu)就OK，這是我們現(xiàn)在平臺去做切換的過程，大家可以借鑒一下。

構(gòu)建之后的效果和后期計劃——構(gòu)建之后的效果

說完我們整體的1.0版的數(shù)據(jù)庫自動化運維系統(tǒng)、2.0版的系統(tǒng)，以及三個案例之后我們來看一下現(xiàn)在整個線上構(gòu)建之后的效果，以及我們后期的計劃。這個統(tǒng)計圖是一個開源組件統(tǒng)計的，他可以分析每天我們的一個用戶量，我們每天在這個平臺上跑的RD的用戶量大概是在三百多。每天會有三百多RD在我們的平臺上做操作，累計的RD數(shù)目大概是1461個，這些是需要跟DB打交道的RD數(shù)量。這個是我們整體平臺跑的效果，你的自動化運維系統(tǒng)做出來之后做的怎么樣?不是嘴說的，還是要有質(zhì)量運營的數(shù)據(jù)。我們做質(zhì)量運營，包括用戶數(shù)，任務(wù)的成功率，平臺的接入率，功能的覆蓋率去衡量整個平臺的指標(biāo)。

構(gòu)建之后的效果和后期計劃——后期計劃

這個圖，也是我們，我剛才前面已經(jīng)講過了，這個架構(gòu)。我們在使用這個架構(gòu)的過程中，很好用，非常好。但是也會存在一些問題，存在什么問題呢?首先這個API層，隨著前端的功能越來越多，我們API會有200多個，很多很多，維護起來比較麻煩。第二個是CMDB，誰都可以去寫。

第三個這個任務(wù)執(zhí)行者現(xiàn)在用不著重，因為他現(xiàn)在需要處理后端的各種各樣的任務(wù)，他會越來越重，DBA可能想要加一個功能，也只能找我加或者我們組內(nèi)的人去加這個功能，這里能不能讓DBA也參與進來

構(gòu)建之后的效果和后期計劃——wew后期計劃

在這個做完之后我們會有一個后期的計劃，我們需要把整個的架構(gòu)改造成這樣的，加入兩個東西，一個是核心功能庫和核心組件庫，這兩個東西包含了API基礎(chǔ)的核心功能，包括日志，包括統(tǒng)計，包括權(quán)限校驗都放在核心功能里，核心組件包括一些DNS組件，Atlas組件、監(jiān)控都放在這里操作，API層只需要負責(zé)他的邏輯就行了。

任務(wù)執(zhí)行者也是只做通用，我只幫你分發(fā)任務(wù)，幫你做任務(wù)的子進程生成，具體誰去做，去調(diào)任務(wù)執(zhí)行平臺去做，這樣的話，我只要任務(wù)平臺做的足夠好，DBA或者RD只需要把你的腳本放在這個平臺的下面的目錄里，就能調(diào)用整個系統(tǒng)，這樣的話非常方便，讓更多的人參與你整個平臺的建設(shè)、開發(fā)和改造的過程中來。