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

[[226747]]

在這種情況，靠純人工去做運維是不可能的了，下面和大家我們自動化運維從 0 到 1 的實踐。

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

• 滴滴 DB 架構介紹
• 主要工作內容
• 主要關注模塊
• 自動化模塊
• 后續(xù)補充項

滴滴 DB 架構介紹

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

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

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

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

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

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

主要工作內容

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

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

工單處理的工作內容基本就是做一些 DDL、表結構的變更，白名單以及其他需求。

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

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

其中，部署和工單處理是我們日常工作的重頭，其占比大約為 70%。但是這一部分工作很容易自動化，一旦實現(xiàn)自動化，我們的工作強度會大大降低。

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

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

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

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

最后就是工作的多樣性。

主要關注模塊

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

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

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

既然要做自動化運維，那么所有的東西就必須要標準化。我們根據之前的架構做了一些標準化的工作。

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

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

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

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

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

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

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

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

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

自動化模塊

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

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

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

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

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

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

在線輔助系統(tǒng)

[[226748]]

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

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

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

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

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

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

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

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

在線 DDL

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

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

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

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

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

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

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

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

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

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

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

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

Saltstack實例

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

后續(xù)補充項

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

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

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

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

[[226750]]

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