滴滴現(xiàn)在主要使用的數(shù)據(jù)庫(kù)是 MySQL。滴滴的業(yè)務(wù)擴(kuò)展很快，目前 DB 服務(wù)器大致有 3000-4000 臺(tái)，實(shí)例就更恐怖了，整體有 7000-8000。

[[226747]]

在這種情況，靠純?nèi)斯とプ鲞\(yùn)維是不可能的了，下面和大家我們自動(dòng)化運(yùn)維從 0 到 1 的實(shí)踐。

今天的分享主要分為五個(gè)部分：

• 滴滴 DB 架構(gòu)介紹
• 主要工作內(nèi)容
• 主要關(guān)注模塊
• 自動(dòng)化模塊
• 后續(xù)補(bǔ)充項(xiàng)

滴滴 DB 架構(gòu)介紹

一般來說，自動(dòng)化運(yùn)維都會(huì)根據(jù)自己原有的架構(gòu)來設(shè)計(jì)自動(dòng)化運(yùn)維平臺(tái)，上圖是滴滴 DB 的架構(gòu)圖，最上面是 TGW LVS，也就是大家所熟悉的 VIP，接下來是代理層 dbproxy。

代理層下面是 MySQL 的主從關(guān)系，一般情況是一主、一備主和一個(gè)從庫(kù)，如果讀取操作多，QPS 會(huì)比較高，從庫(kù)也需相應(yīng)的增多。

同時(shí)還要有 MySQL 高可用的監(jiān)控來應(yīng)對(duì)主庫(kù)掛了等等的異常情況。運(yùn)維監(jiān)控，我們是使用最常見的 ZABBIX 來做的。除此之外，我們還做了備份模塊和性能優(yōu)化的模塊。

dbproxy 相當(dāng)于一個(gè)入口，連接應(yīng)用，它是分布式的，因此每臺(tái)上都會(huì)有自己的原始配置，所有的訪問 DB 的流量都要經(jīng)過 dbproxy 層。

dbproxy 會(huì)記錄正常的訪問日志，還有一些錯(cuò)誤日志，例如沒有加白名單或者是 SQL 語(yǔ)法錯(cuò)誤等等都會(huì)在 dbproxy 層攔截，產(chǎn)生錯(cuò)誤日志。

上圖的架構(gòu)就是我們?cè)谧鲎詣?dòng)化運(yùn)維的初始部署，我們希望能夠完成從業(yè)務(wù)申請(qǐng)到部署完成的一系列連貫動(dòng)作。

主要工作內(nèi)容

我們平時(shí)的工作內(nèi)容如上圖所示，基本包括部署、工單處理、擴(kuò)容拆分、監(jiān)控報(bào)警處理以及其他任務(wù)。

一周時(shí)間，RD 申請(qǐng) 30—50 個(gè)實(shí)例在我們的工作中是很常見的，這時(shí)如果沒有自動(dòng)化運(yùn)維，單純靠自己手工部署的話，是很消耗時(shí)間的。

工單處理的工作內(nèi)容基本就是做一些 DDL、表結(jié)構(gòu)的變更，白名單以及其他需求。

隨著業(yè)務(wù)的發(fā)展，數(shù)據(jù)量會(huì)猛增，由于單機(jī)磁盤的存儲(chǔ)是有限的，這時(shí)我們就要思考擴(kuò)容、拆分的問題了。

還有一種情況是磁盤可能足夠存儲(chǔ)，但是你的 TPS/QPS 單機(jī)可能撐不住，這時(shí)也要去做擴(kuò)容；監(jiān)控報(bào)警處理指的是我們前面提到的 SQL 錯(cuò)誤，白名單沒有加以及其他一些報(bào)警。

其中，部署和工單處理是我們?nèi)粘９ぷ鞯闹仡^，其占比大約為 70%。但是這一部分工作很容易自動(dòng)化，一旦實(shí)現(xiàn)自動(dòng)化，我們的工作強(qiáng)度會(huì)大大降低。

我們的工作痛點(diǎn)前面也提到了一部分，第一個(gè)就是因?yàn)榱看螅覀兠恐芏紩?huì)有很多的新申請(qǐng)，所以這部分工作的自動(dòng)化是迫在眉睫的。

其次，我們的業(yè)務(wù)還有一個(gè)特點(diǎn)就是峰值比較集中，因?yàn)榇蜍囈话愣技邪l(fā)生在早高峰或晚高峰，所以系統(tǒng)的瓶頸也集中在這兩個(gè)時(shí)間段。

第三個(gè)是數(shù)據(jù)庫(kù)的延時(shí)，業(yè)務(wù)一般都會(huì)有超時(shí)時(shí)間的設(shè)置，數(shù)據(jù)庫(kù)的延時(shí)是非常敏感的。

一個(gè)查詢進(jìn)入到數(shù)據(jù)庫(kù)再到返回結(jié)果的延時(shí)，這里的延遲指的不是我們平常意義上的主從同步數(shù)據(jù)的延時(shí)，指的是對(duì)業(yè)務(wù) SQL 的響應(yīng)時(shí)間，在線 DDL 的表結(jié)構(gòu)修改也會(huì)影響到延時(shí)。

最后就是工作的多樣性。

主要關(guān)注模塊

做自動(dòng)化運(yùn)維，之前的模塊肯定是不能丟掉的。之前，我們的高可用、數(shù)據(jù)備份、監(jiān)控報(bào)警、在線 DDL 系統(tǒng)等重點(diǎn)關(guān)注模式是使用 PT，現(xiàn)在我們改用了 ghost。

在完成整個(gè)運(yùn)維自動(dòng)化的過程中，我們做的第一步是 DBA 的自動(dòng)化運(yùn)維，其次是數(shù)據(jù)庫(kù)系統(tǒng)服務(wù)化。

當(dāng)然現(xiàn)在我們的功能還達(dá)不到云服務(wù)商提供的那樣，但是業(yè)務(wù)如果需要申請(qǐng)一個(gè) DB，相關(guān)人員在平臺(tái)上操作幾步就可以自己完成。

既然要做自動(dòng)化運(yùn)維，那么所有的東西就必須要標(biāo)準(zhǔn)化。我們根據(jù)之前的架構(gòu)做了一些標(biāo)準(zhǔn)化的工作。

例如 OS 初始化的標(biāo)準(zhǔn)化（文件系統(tǒng)，內(nèi)核設(shè)置，磁盤掛載目錄等）和數(shù)據(jù)庫(kù)層面的標(biāo)準(zhǔn)化（配置文件、部署路徑、多實(shí)例目錄命名規(guī)則以及 ID 的命名規(guī)則）。

上圖是滴滴 DB 自動(dòng)化架構(gòu)的細(xì)節(jié)展示。

在線業(yè)務(wù)系統(tǒng)的最左側(cè)是 VIP，第二列是代理層中間件，第三列是 MySQL，在這一層我們一般是用 MHA 來保證 MySQL 的高可用。

第四列是數(shù)據(jù)總線，很多人可能不理解數(shù)據(jù)總線，我舉個(gè)簡(jiǎn)單的例子，如果乘客或者司機(jī)想要查詢歷史訂單，那么你當(dāng)然不能直接去線上的訂單庫(kù)里查詢。

線上訂單庫(kù)一般是按城市來分的，所以你還需要按照司機(jī)或乘客的 ID 將訂單數(shù)據(jù)哈希到另一張表里，并且在這個(gè)新的庫(kù)里進(jìn)行歷史數(shù)據(jù)的查詢，相當(dāng)于對(duì)數(shù)據(jù)重新做了一次分發(fā)和哈希。

在線輔助系統(tǒng)主要包括 MySQL 集群 meta 信息、在線 DDL、SQL 審計(jì)、SQL 統(tǒng)計(jì)等。

自動(dòng)化運(yùn)維系統(tǒng)的 Web 層更多的是前端、界面化的東西，接下來是 API 層、調(diào)度層和執(zhí)行層。

API 層聯(lián)動(dòng)著很多操作，假設(shè)我現(xiàn)在去 Web 端申請(qǐng)了一個(gè)實(shí)例，那么接下來 API 層就會(huì)有一些動(dòng)作。

例如新建實(shí)例、新建 MySQL 集群、新建 dbproxy，之后還需要做備份相關(guān)的東西。

自動(dòng)化模塊

在線業(yè)務(wù)系統(tǒng)

中間件的擴(kuò)容指的是 dbproxy 層，可能我們最開始只有三臺(tái)，但是隨著訪問的增多，它本身也需要擴(kuò)容。

DB 層，就如我們剛才看到的 MHA 那一塊，一開始我們可能申請(qǐng)了三臺(tái)，一個(gè)主庫(kù)、一個(gè)備主庫(kù)和一個(gè)從庫(kù)，我們需要進(jìn)行部署、擴(kuò)容和備份。

上圖中的拆分主要是根據(jù) QPS/TPS 來進(jìn)行拆分，還有就是一些故障機(jī)的下線。

數(shù)據(jù)鏈路層，這一層做的功能還是比較強(qiáng)大的，因?yàn)楹枚鄸|西都依賴這一層。

我們是利用了開源的 canal+kafka+zookeeper，對(duì)數(shù)據(jù)重新做哈希，比如我上游可能是根據(jù)城市來分表的，那我下游就有可能把多個(gè)城市的表聚合起來。

在線輔助系統(tǒng)

[[226748]]

在線輔助系統(tǒng)就是之前說的備份系統(tǒng)、高可用、SQL 審計(jì)以及它的優(yōu)化建議，監(jiān)控報(bào)警、定時(shí)任務(wù)、數(shù)據(jù)鏈路的耗時(shí)分析。

定時(shí)任務(wù)怎么理解？實(shí)際應(yīng)用可能會(huì)有一些按天數(shù)分表的情況，一般來說，業(yè)務(wù)肯定不會(huì)每天去建一個(gè)新表。

所以這些操作都會(huì)由定時(shí)任務(wù)調(diào)度來處理，還有一些監(jiān)控腳本、備份腳本、歷史數(shù)據(jù)刪除腳本都會(huì)在定時(shí)任務(wù)里。

數(shù)據(jù)鏈路的耗時(shí)分析，如果前端要訪問數(shù)據(jù)庫(kù)，那么需要經(jīng)過的層比較多，先要通過 dbproxy，再要通過 MySQL，MySQL 回包……

這整個(gè)過程中，哪個(gè)過程是最耗時(shí)的？我們會(huì)繪制一個(gè)整個(gè)過程的時(shí)間序列圖，這樣就可以一目了然的看出哪里耗時(shí)最嚴(yán)重。

自動(dòng)化運(yùn)維系統(tǒng)

自動(dòng)化運(yùn)維系統(tǒng)的調(diào)度層我們是基于 Python 和 tornado，底層執(zhí)行是采用 saltstack。

上面這張圖片有 tornado 和 saltstack 的官網(wǎng)鏈接，大家可以參考。

在線 DDL

下面我再講幾個(gè)案例。根據(jù)架構(gòu)，我們首先要去細(xì)分需要做哪些東西？分析完之后，我們還需要從中挑選出更為重要的模塊，例如占用工時(shí)較久的部署，優(yōu)先自動(dòng)化。

在線 DDL 是一個(gè)比較重要的模塊，它的業(yè)務(wù)峰值是比較集中的，有可能一個(gè)表是非常大的，你想避開高峰期，例如想在晚 10 點(diǎn)到早 8 點(diǎn)做完，但是有可能是做不完的。

時(shí)間跨度大一直是在線 DDL 的一個(gè)痛點(diǎn)，而且有些大表的業(yè)務(wù)修改是很敏感的。

在線 DDL 的一般邏輯就是先創(chuàng)建一個(gè)空表，修改空表的表結(jié)構(gòu)，把歷史數(shù)據(jù)和增量數(shù)據(jù)同步到新表中，最后一步就是 rename table，對(duì)新表和舊表做一次交換。

我們之前數(shù)據(jù)量不是很大的時(shí)候使用的是 pt。pt 的話，歷史數(shù)據(jù)一般是通過 INSERT LOW_PRIORITY IGNORE INTO ，而增量數(shù)據(jù)是通過 trigger 來做的。

但是這種方法會(huì)有個(gè)問題，你對(duì)原表的操作都會(huì)通過觸發(fā)器來觸發(fā)一個(gè)相應(yīng)的操作，它對(duì)于 QPS 來說是雙倍的，而且是同時(shí)。

例如你在對(duì)一個(gè)表訪問，它上面 100 多個(gè) TPS，對(duì)于業(yè)務(wù)來說，正常情況可能是 100 毫秒或者是幾毫秒的耗時(shí)，但你在修改這個(gè)的時(shí)候，耗時(shí)會(huì)很長(zhǎng)，甚至有可能會(huì)訪問不成功。

后來，我們經(jīng)過調(diào)研就選擇了 inception+ghost，沒有觸發(fā)器。

它的原理是先去建一個(gè)新表，對(duì)新表進(jìn)行表結(jié)構(gòu)的修改，再去解析一個(gè)從庫(kù)對(duì)舊表操作的 binlog 來回放增量數(shù)據(jù)的處理。

原有的老數(shù)據(jù)也是通過單個(gè) chunk 的方式復(fù)制到新表中，新數(shù)據(jù)通過回放從庫(kù)對(duì)舊表的操作 binlog 來回寫到新表中。

所以對(duì)于主庫(kù)的壓力比較低，主庫(kù)上舊表和新表的寫入也是異步的，避免了觸發(fā)器同步執(zhí)行的弊端，比如新加一個(gè)字段或者修改字段的類型。

當(dāng)然它也是有版本迭代的，大家可以根據(jù)自己的需求來進(jìn)行修改。

Saltstack實(shí)例

這個(gè)是前面提到的 saltstack 實(shí)例，如何通知底層來做相關(guān)的新建任務(wù)？其實(shí)就是通過 saltstack 來去調(diào)用底層執(zhí)行。

假設(shè)我現(xiàn)在要新建一個(gè) MySQL 的主從實(shí)例，最上面是服務(wù)名稱，這個(gè)服務(wù)名稱一般都是以用途來命名。

接下來是選擇版本和 port，還要選擇主庫(kù)、備主庫(kù)、從庫(kù)，如果你的 QPS 非常高，那三臺(tái)機(jī)器是不夠的，需要增加幾臺(tái)，直接加在后面就可以了。

針對(duì) MySQL 的新建，我們會(huì)有一個(gè)模板一樣的數(shù)據(jù)文件，其中已經(jīng)包含了 MHA 所需要的用戶信息，類似于連接信息、授權(quán)等等都會(huì)在這個(gè) Demo 的文件里。

新建 MySQL，相當(dāng)于我先去拷一個(gè)模板文件，調(diào)用接口，新建端口，這個(gè)端口一般來說是多實(shí)例的。

dst 一般是根據(jù)你申請(qǐng)的數(shù)據(jù)庫(kù)或者服務(wù)名來定義目標(biāo)機(jī)器的目錄名稱。傳進(jìn)來之后，就要判斷機(jī)器上這個(gè)端口是否存在。

如果存在的話，是不可以再新建一個(gè)同樣的端口；如果不存在的話，我們下一步就是判斷目錄是否存在。

這里需要強(qiáng)調(diào)的一點(diǎn)是，salt 是一步一步開始執(zhí)行的，一旦哪個(gè)步驟出現(xiàn)錯(cuò)誤，那就是直接失敗，不再接著往下繼續(xù)了。

原數(shù)據(jù)的 Demo 數(shù)據(jù)文件建好了，下一步就是建立模板的配置文件。配置文件和數(shù)據(jù)文件有很多相似之處，都是先去判斷端口是否存在，數(shù)據(jù)文件目錄是否存在，然后創(chuàng)建目錄。

salt 其實(shí)在系統(tǒng)里面內(nèi)置了很多命令可供用戶調(diào)用，最后判斷 MySQL 版本來拉取模板配置文件。

因?yàn)槟０迮渲梦募峭ㄓ玫模韵乱徊骄褪切薷呐渲梦募热?port 信息，datadir、binlogdir 等等。

這個(gè)部分也是一個(gè) salt 模塊，就是把模板文件中的 port 替換成你傳進(jìn)來的 port。

下一步就是啟動(dòng) MySQL，數(shù)據(jù)文件拉取過來了，配置文件修改完成了，直接去啟動(dòng) MySQL 就可以了。

啟動(dòng)之后，因?yàn)槟憬⒌氖且粋€(gè)主從復(fù)制關(guān)系的集群，假設(shè)現(xiàn)在建立了三個(gè)實(shí)例，而復(fù)制關(guān)系還沒有配置，這個(gè)地方就相當(dāng)于傳一些參數(shù)來配置復(fù)制關(guān)系的。

以上是 MySQL 新建的過程，dbproxy 的新建過程大致也是差不多的。一般都會(huì)做 Demo 的東西拉取過來，之后修改配置文件，再去啟動(dòng)。

后續(xù)補(bǔ)充項(xiàng)

MySQL、dbproxy 和 MHA 的搭建備份都已經(jīng)實(shí)現(xiàn)自動(dòng)化了，但是我們現(xiàn)在還有一些東西沒有實(shí)現(xiàn)自動(dòng)化，例如以下幾點(diǎn)：

• 資源管理和分配，申請(qǐng)一個(gè)實(shí)例，資源池中的機(jī)器如何選擇還沒有自動(dòng)化。
• VIP 自動(dòng)分配，其實(shí)在我司是運(yùn)維來做的，VIP 是綁定在后端 dbproxy 機(jī)器上的，沒有自動(dòng)化的原因是因?yàn)槲覀儾惶猛苿?dòng)。
• 細(xì)粒度的監(jiān)控報(bào)警，服務(wù)器的動(dòng)態(tài)或者數(shù)據(jù)庫(kù)的連接信息或者狀態(tài)，你是可以看到的。但是如果線上新上線了一個(gè)東西，但是庫(kù)里還沒有新加字段。

如果是不重要的模塊，可能直接跑一個(gè)腳本。我們希望做到 dbproxy 層的報(bào)警都可以直接發(fā)給集群的創(chuàng)建者。

• 慢查分析，優(yōu)化建議，現(xiàn)在我們有搜集慢查分析的相關(guān)信息，但是沒有做到自動(dòng)化的頁(yè)面上去。

[[226750]]

朱進(jìn)卓，滴滴資深 DBA，主要負(fù)責(zé)專車、快車等核心業(yè)務(wù)線數(shù)據(jù)庫(kù)維護(hù)，數(shù)據(jù)庫(kù)架構(gòu)設(shè)計(jì)、優(yōu)化、高可用維護(hù)，滴滴內(nèi)部自動(dòng)化平臺(tái) RDS 部分模塊開發(fā)。先后就職于搜狐暢游和金山，技術(shù)涉獵 MySQL 、Redis、MongoDB、OpenStack、Python、Go。