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

[[226747]]

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

今天的分享主要分為五個部分：

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

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

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

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

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

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

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

上圖的架構(gòu)就是我們在做自動化運維的初始部署，我們希望能夠完成從業(yè)務(wù)申請到部署完成的一系列連貫動作。

主要工作內(nèi)容

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

一周時間，RD 申請 30—50 個實例在我們的工作中是很常見的，這時如果沒有自動化運維，單純靠自己手工部署的話，是很消耗時間的。

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

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

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

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

我們的工作痛點前面也提到了一部分，第一個就是因為量大，我們每周都會有很多的新申請，所以這部分工作的自動化是迫在眉睫的。

其次，我們的業(yè)務(wù)還有一個特點就是峰值比較集中，因為打車一般都集中發(fā)生在早高峰或晚高峰，所以系統(tǒng)的瓶頸也集中在這兩個時間段。

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

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

最后就是工作的多樣性。

主要關(guān)注模塊

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

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

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

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

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

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

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

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

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

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

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

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

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

自動化模塊

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

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

DB 層，就如我們剛才看到的 MHA 那一塊，一開始我們可能申請了三臺，一個主庫、一個備主庫和一個從庫，我們需要進行部署、擴容和備份。

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

數(shù)據(jù)鏈路層，這一層做的功能還是比較強大的，因為好多東西都依賴這一層。

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

在線輔助系統(tǒng)

[[226748]]

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

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

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

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

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

自動化運維系統(tǒng)

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

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

在線 DDL

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

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

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

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

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

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

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

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

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

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

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

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

Saltstack實例

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

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

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

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

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

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

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

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

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

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

因為模板配置文件是通用的，所以下一步就是修改配置文件，比如 port 信息，datadir、binlogdir 等等。

這個部分也是一個 salt 模塊，就是把模板文件中的 port 替換成你傳進來的 port。

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

啟動之后，因為你建立的是一個主從復(fù)制關(guān)系的集群，假設(shè)現(xiàn)在建立了三個實例，而復(fù)制關(guān)系還沒有配置，這個地方就相當(dāng)于傳一些參數(shù)來配置復(fù)制關(guān)系的。

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

后續(xù)補充項

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

• 資源管理和分配，申請一個實例，資源池中的機器如何選擇還沒有自動化。
• VIP 自動分配，其實在我司是運維來做的，VIP 是綁定在后端 dbproxy 機器上的，沒有自動化的原因是因為我們不太好推動。
• 細(xì)粒度的監(jiān)控報警，服務(wù)器的動態(tài)或者數(shù)據(jù)庫的連接信息或者狀態(tài)，你是可以看到的。但是如果線上新上線了一個東西，但是庫里還沒有新加字段。

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

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

[[226750]]

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