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

[[226747]]

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

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

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

滴滴 DB 架構介紹

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

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

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

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

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

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

主要工作內容

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

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

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

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

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

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

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

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

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

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

最后就是工作的多樣性。

主要關注模塊

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

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

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

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

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

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

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

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

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

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

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

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

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

自動化模塊

在線業務系統

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

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

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

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

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

在線輔助系統

[[226748]]

在線輔助系統就是之前說的備份系統、高可用、SQL 審計以及它的優化建議，監控報警、定時任務、數據鏈路的耗時分析。

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

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

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

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

自動化運維系統

自動化運維系統的調度層我們是基于 Python 和 tornado，底層執行是采用 saltstack。

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

在線 DDL

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

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

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

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

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

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

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

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

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

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

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

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

Saltstack實例

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

后續補充項

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

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

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

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

[[226750]]

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