本文主要圍繞資料庫相關的主題，內容包括美團資料庫自動化運維繫統構建、點評側 MySQL 自動化服務平臺 RDS、美團資料庫中介軟體、和小米高階 DBA 帶來的 Redis Cluster 的大規模運維實踐。

講師簡介

寧龍，美團網高階 DBA，現負責美團資料庫自動化運維繫統的架構和開發工作。

目錄

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

• 第一部分是美團在資料庫自動化運維繫統構建前的煩惱，DBA 手動運維 DB 的時候遇到的各種問題；

• 第二個是我們在構資料庫運維自動化系統過程中的一些坎坷和思考，這裡我會說我們的 1.0 版系統，還有 1.0 版的系統為什麼要到 2.0 版的，以及現在 2.0 版系統線上上的使用情況，在 2.0 版系統的基礎上，我會給大家介紹三個典型的案例，可能大家平時會用到的；

• 最後說一下我們 2.0 版系統構建之後線上跑的效果，以及我們做的後期改進的計劃，也可以說是 3.0；

• Q&A 環節。

構建前的苦惱——一線運維 DBA

首先說一下資料庫運維自動化系統構建前，運維 DBA 都有哪些煩惱？

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

構建前的苦惱——手動運維的煩惱

接下來，我們先看一下美團點評初期資料庫系統的架構：一開始是兩層的架構，在主從庫的基礎上配置讀寫 DNS，後來引入 LVS。這個兩層或者三層的資料庫架有什麼問題呢？

比如底層的資料庫做切換了，上層的 DNS 配置也要變更，生效到各個機房，幾分鐘過去了……

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

所以說，這樣的資料庫架構在切換或者從庫上下線流量的時候，都會導致業務的報錯，業務接受不了。

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

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

最後一個煩：RD 經常不按照規範做事，包括上線一些大 SQL、慢查詢。程式不加重試，在網路抖動的時候，發現資料庫怎麼連線斷了？他就會找到你。還有一些誤操作，前幾天有一個 RD 半夜打電話跟我說，線上資料誤刪除了需要恢復，通過我們平臺去 Delete 資料的話，是很好恢復的，但是他說不好意思，我通過帳號直連線上刪了資料。有些明白的 RD 會不好意思，知道資料不好恢復；但是，有些 RD 會說：“你 DBA 就是幹這個事兒的，你就是得幫我恢復資料。”

大家很鬱悶，在沒有自動化運維繫統之前的 DBA 還是非常苦惱的。

構建中的坎坷和思考——1.0 版系統設計之初的考慮

以上講完了資料庫運維自動化系統構建前 DBA 的苦惱，接下來說一說我們如果想去構建一套資料庫自動化運維繫統應該從哪裡開始著手，我這裡列的都是非常重要的。

第一個就是 CMDB，如果你做的自動化系統中沒有 CMDB，那麼，我覺得你做的自動化系統就不叫自動化系統。做自動化其實就是做標準化，這樣的話，你在做自動化運維的時候，CMDB 可以很方便的讓你查詢到資訊，對業務進行合理的描述，這樣的話有一個基本的地方，其實就是資料標準，我後面會說。

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

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

最後就是開發形式，我們整個大的運維部是有開發人員相關資源的，我們找到他們去幫我們做一些頁面，這樣的話，你就會迅速的搭建你的 1.0 版本。

以上就是我要說的四點。

構建中的坎坷和思考——1.0 版系統架構設計 & 使用情況

大家可以看一下我們 1.0 版系統的整體框圖，使用者就不說了，前端模組主要是 Django+MVC 的方式，前端開發是不懂 DBA 業務的，他們需要做什麼事情呢？他們把使用者提交的任務寫到資料庫的 task 表中，我們後臺的 DBA 去寫一些指令碼，去把前端提交的任務拉出來，拉出來之後如果有日誌，會反寫到 task 表裡，這就是我們 1.0 版的架構，非常的簡單，但是也是非常的實用，右邊這個圖是我們 1.0 版的效果，其實我後來加了 DML，一開始只有 DDL，業務他只需要選擇他所需要變更的 SQL 型別之後，提交到後端 DB 的 task 表。後臺會有一個常駐記憶體的程式，掃描這個 DB，去發現當前有沒有需要我去執行的任務，如果有就拉出去執行，執行的過程中會有一些日誌，會回填到這個 DB 中，前端從 DB 拉去日誌資訊，就可以展示了。當時的效果，日均的訂單是 1840，2015 年初，公司正是快速增長期的時候，現在應該比這個稍微少一點，當時使用人數大概 600 人，雖然是很簡單的一套架構，但是使用的人數還是非常多。

構建中的坎坷和思考——1.0 版的反思

1.0 版的系統做完了之後為什麼做 2.0 版的系統呢？

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

1.0 版有什麼問題呢？

首先是前瞻模組重，開發人員很多，因為我們當時都是公用開發人員，開發人員很多，依賴也非常多，其實我開發習慣不太喜歡依賴什麼太多的框架、組建，這樣的話感覺很重，可能導致你程式碼的遷移、擴充套件性差。

第二個是沒有介面化，RD 不方便接入，很深刻的一個例子就是，有一個業務，他可能到某天的凌晨需要建跟時間相關的表，需要刪表、建表，他每次都等到凌晨的時候去平臺提交去做，他覺得很辛苦，於是就問我：“你們有沒有介面讓我去調，我寫個指令碼到那個時間就把我的表建上，因為每個時間表結構都是一樣的”。如果你的平臺沒有介面化很不方便，特別有一些需要定期跑的業務。

第三個就是開發週期長、成本高，得跟他們溝通，需求調整複雜。當然它主要在高併發、高效能上很差，原因是什麼？因為後臺是一個常駐記憶體的程式，我當時只起了大概可能是 6 個執行緒就跑了，併發的話只能跑 6 個，我們 2.0 版的系統你想跑多少個就跑多少個，我一會兒給大家介紹一下怎麼做的，不易擴充套件，這個也不方便擴充套件，後臺的任務就一個，掛了就掛了，圖象化做的也不好，畢竟是找人家幫我們做的，效果也不是太好。這個是我們為什麼做 2.0 下定決心的一個原因吧！

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

構建中的坎坷和思考——2.0 版架構設計

隨著業務的發展，1.0 版系統已經不能滿足我們現在的需求，我們就做了 2.0 版。

2.0 版需要遵循三個方面：標準化、自助化、自動化。

第一個標準化，指的是：介面標準、資料標準、流程標準。介面標準。你不能說，我的平臺（WEB 前端）提交的是一種方式，API 介面提交是另一種方式，這是不行的。資料標準，就是 CMDB，一定要準，一定要實時得更新，不然整個上層，它是基石，整個上面的框架搭起來都是白費的。流程標準，你需要制定 ABCD 各種各樣的流程，很多 DBA，他有自己的方式、方法。比如說對於拆分來說，A 有它的方法，B 有它的方法，可能都能達到目的，但是標準化，只能用一種方式。

第二個自助化，操作自助，只要能放給 RD 自主操作的就自主操作。問題定位的自助，RD 碰到了資料庫相關的問題，不是第一時間找 DBA，而是第一時間在你平臺上可以看到現在資料庫的狀況，定位到現在資料庫的問題，去操作相關業務邏輯解決問題。

第三個自動化，高可用和報警自動處理。高可用，從庫當機你可以把它剔掉；報警自動處理，對於收到報警看一眼，後臺有報警自動處理的程式就給它處掉了。

這是我們需要遵循的三個化，標準化、自助化和自動化。

構建中的坎坷和思考——2.0 版架構設計

介紹 2.0 版系統整體的架構之前，我先給大家介紹一下兩個開源的元件，第一個是 RabbitMQ，這是一種應用程式對應用程式的通訊方法，這個端對於另一個端的通訊，它是通過這個端來發訊息，另一個端接訊息，從而連線了兩個端，很簡單，其實他的作用就是連線訊息的橋樑，美團點評現在做的 O2O，就是連線人和服務，你不需要自己找，你只需要在 APP 上操作就行了。對於訊息佇列，你只需要提交到對應的佇列中去就行了。

構建中的坎坷和思考——2.0 版架構設計

第二個就是 Celery，這個 Rabbit 的中文翻譯是兔子，Celery 翻譯成中文就是芹菜，兔子和芹菜構建了我們 2.0 版系統。大家可以這麼理解，Celery 其實就是封裝在訊息佇列上面一個非常好用的任務排程者，是基於 Python 開發的，他可以幫你幹什麼呢？可以幫你發任務，可以幫接任務，可以幫你定時的起任務，我今天凌晨 2 點拆分，可以白天提交，凌晨 Celery 幫你排程。它是對於訊息中介軟體上面很好用的封裝。

構建中的坎坷和思考——2.0 版架構設計

說完了以上兩個開源的組建，我們接下來說整個 2.0 版系統的架構，一點點的放出來，首先是使用者，通過前端的 Web，他的所有的操作全部打到我們的 API 層，業務模組：指令碼也好，系統也好，也是打到我們的 API 層，這樣做到了介面的統一，後端的處理都是一樣的，不管是任何人，對於我來說都是我的一個端。

API 層它可以做兩個事情，比如我想查詢當前資料庫的主從架構情況，當前服務裡的資料庫列表，那麼 API 層直接跟 CMDB 互動獲取資料並返回。第二種是需要後臺做任務的，比如搭建，擴容，拆分這些都是任務，它們需要到後臺的任務管理模組去做。任務管理模組會把任務分發下去。這中間會有 CMDB。任務管理模組可以詳細講一下，這個就是剛才我所說的 MQ 的訊息管道，這裡是 Celery，這裡有兩個 Celery，你可以理解為它是 MQ 的封裝，你只需要給 Celery 通訊就可以了。TaskControl 是掛載到整個訊息中介軟體上面的一個任務處理者。它會生成父子程式去處理任務。

構建中的坎坷和思考——2.0 版架構設計

我剛才說的為什麼任務是可以無限地增加，前提是在機器可以承載的情況下無限增加。第一步，TaskControl 先 fork 出一個子程式，第二步，子程式 1 再 fork 出一個子程式，這個子程式 2，是真正得做任務的程式，這個程式再呼叫任務執行指令碼或者模組去進行任務操作。子程式 1，它會把子程式 2 的一些資訊，比如程式 PID，回填到資料庫裡，子程式一 1 就退出了，子程式 1 退出之後，它跟子程式 2 的關係就斷開了，這裡要說一點，子程式 1 得忽略回收子程式，這時候子程式 2 就託管給了 init 程式，這樣的話就生成了這麼一個任務執行單元。任務執行單元只是需要自己去做任務，比如說它去做 DDL，這個子程式 2 是父程式，會去做子程式的回收操作，任務日誌的回填工作等。

構建中的坎坷和思考——2.0 版架構設計

最後的效果大家可以看到，就是右下角這樣的，這個 TaskControl，每次生成父子程式完成之後，它就回去從訊息佇列去拿新的任務，一臺機器上，好多個父子程式，併發高的時候，這些任務會有一百多個，這樣的話，大大提升了整個系統的併發性，正常的話，這裡起 6 個子程式就夠了，用來監聽任務，生成任務執行單元。我看有些公司會起很多很多模組去處理，用這種技巧的話，就可以讓任務的執行脫離整個任務系統。

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

構建中的坎坷和思考——2.0 版功能實現案例一：叢集搭建

說完了上面的整體架構之後我會給大家講三個案例：

第一個案例是我們現有的叢集的搭建過程，我先說一下我們線上跑的整體資料庫的四層架構：第一層是業務層，業務層，訪問我們都是通過 DNS，DNS 下面掛的是虛 IP 層，虛 IP 層下面會掛我們的中介軟體，atlas，每個機房會有並行得部署多個，最下面掛的是資料庫主從架構，這個是現在美團用的線上資料庫主流架構。

構建中的坎坷和思考——2.0 版功能實現案例一：叢集搭建

現在開始說搭建流程，我說了這麼多，大家沒看到我們系統的廬山真面目，這個是我們 2.0 版本系統的頁面。對於搭建，DBA 需要先點選一下服務組初始化，首先需要去建立一個服務，我們每一個 DB 叢集在資料庫裡面都是有一個標識的，被稱做服務組。

構建中的坎坷和思考——2.0 版功能實現案例一：叢集搭建

接著，需要選擇你要搭建的型別，我剛才說的四層的架構是這裡的 A 套餐，但是如果說是一些統計、運營類的庫，我們可能會用到 BCD 套餐，後面三個套餐用的比較少。當然因為這裡有四個，可能涉及到的情況非常多：有沒有 atlas、有沒有 MGW、有無 DNS…… 可能至少得有八種情況。有時候大家做自動化的時候，就會遇到矛盾，這種情況怎麼辦？現在給 DBA 的四個套餐其實就是制定標準，就是你搭建的資料庫叢集，都是按照我的標準來的，只有這四種，DBA 就說了：你有時候不滿足我的情況，DBA 就要手動去做，怎麼辦？

構建中的坎坷和思考——2.0 版功能實現案例一：叢集搭建

你的系統不能夠相容 DBA 的需求的時候怎麼辦呢？這個時候確實很麻煩，它手動運維在後面搞一搞，很有可能造成你的 CMDB 資訊缺失等問題，這個就很麻煩。

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

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

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

構建中的坎坷和思考——2.0 版功能實現案例一：叢集搭建

在大家選完套餐之後就可以到這個介面了，做資料庫運維自動化系統有很多流程性的東西，你接下來需要走哪一步，選完套餐之後讓他選機器，你的監控是什麼，buffer pool 多大，下面會給他展示一個實時的拓撲；你要把你的使用者當小白鼠，你得告訴他現在長什麼樣子了，不然的話他提交出錯了，又回來找你。

構建中的坎坷和思考——2.0 版功能實現案例一：叢集搭建

第二個我們去選擇 atlas，根據分組選擇 atlas，就是資料庫中介軟體，選擇完之後就可以形成這樣的圖。

構建中的坎坷和思考——2.0 版功能實現案例一：叢集搭建

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

構建中的坎坷和思考——2.0 版功能實現案例一：叢集搭建

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

構建中的坎坷和思考——2.0 版功能實現案例一：叢集搭建

這樣形成最後一個大的 JSON，讓 DBA 去做確認，你申請的服務名稱、你當前資料庫的機器、中介軟體的機器、你的虛 IP 層和域名，包括你的 DB，會有一個整體的拓撲圖，這樣的話。然後把整個的引數，所有的需要你完成這個資料庫叢集搭建的引數合成一個大的 JSON。發到 API 層，API 層會做引數校驗，你當前搭建的引數是否滿足系統的要求，如果滿足要求，就會發到後臺的流程引擎中，就是後臺系統去做任務。做任務的時候，大家可能說，我需不需要有什麼高深的語言，這個無所謂了，你可以是指令碼，也可以是程式。我們現線上上，搭建的話用的還是 DBA 他們一開始寫的搭建指令碼，只需要把指令碼改造一下，輸入，輸出標準化一下，你能夠識別指令碼的輸出輸入就行了。

大家說自動化很艱辛，很艱難。其實身邊有很多的資源就是DBA手中平時做的一些指令碼，

有一些指令碼可能DBA自己用，寫的不太好。但是他本身，他是有非常大的價值的，因為他是長年累月改過的，可能第一版不行改第二版、第二版不行改第三版，他可能改了一年，他的整個指令碼跑起來還是非常流利的，我們指令碼搭建很穩定得跑了10個月的時間，主要的原因是因為我們DBA很靠譜，積累的很多實用的指令碼。有些純開發的人去做DBA的自動化系統，他很難理解DBA的需求，有時候DBA也講不清楚，所以通過你做系統，他做指令碼的方式去合作，真的很靠譜。因為做出來的系統是非常穩定的。

構建中的坎坷和思考——2.0 版功能實現案例二：線上表變更

說完了資料庫叢集搭建這個案例，我們說第二個案例：線上表變更是怎麼做的。首先批量的 DDL 或者 DML 打造我們的 API 層，我們 API 層會做兩個事情，第一個是語法檢測，語法檢測有兩種方式，一種是測試庫，一種是 sqlparser；比如，對於 autoddl 的 create 操作，你可以在測試庫上建一下這個表，你就知道語法對不。或者是說 alter 操作，你可能先從線上把表結構拉到測試環境，在測試庫上先建上，再把 alter 語句用到這個表上，你看 alter 能不能通過，這樣很方便就繞過了 sqlparser。

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

構建中的坎坷和思考——2.0 版功能實現案例二：線上表變更

大家可以看看這是我們現在的線上表變更的提交頁面。這裡也是先選業務，選完相關的業務，你選庫，選操作型別，我們這裡會有一個業務高峰的描述，比如對於 pt-online-schema-change 在做表變更的時候，他會有一個資料拷貝的過程，所以說我們會有一個業務高峰，在業務高峰的時候 RD 發起的任務是不能被執行的。還有任務操作時間區間，RD 也可以選，比如我選今天晚上凌晨變更或者什麼時候變更都是 OK 的，RD 把他的 SQL 批量粘到這裡。對於線上的分表，粘一個母表就行了，下面我們自動生成帶數字的語句會給他操作。這樣也方便我們後臺的處理，對於 512 的分表，我們只校驗第一個語法語義就行了，不然的話，會產生很多效能問題。

構建中的坎坷和思考——2.0 版功能實現案例二：線上表變更

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

構建中的坎坷和思考——2.0 版功能實現案例二：線上表變更

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

構建中的坎坷和思考——2.0 版功能實現案例二：線上表變更

這個就是我們整個任務執行的一個詳情的單子，就是 RD 在提交完任務之後在這個頁面看到他任務執行的詳細的資訊，這上面是一些元資訊，包括他提交的時間，他服務的資訊，下面會有一個詳細的執行日誌發給他，你在做任務操作的時候，你把你的任務相關的資料實時回填到任務表裡，前端只需要讀這個任務表就行了。

構建中的坎坷和思考——2.0 版功能實現案例三：高可用解決方案（MHA）

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

到了第 2 步，調 MHA 去做主從切換。切換完之後呢，他會通過 API 去改 CMDB 的資訊，CMDB 裡面會描述資料庫的主從的架構，描述完之後，他會去調介面，通知中介軟體變更主從資訊，那麼到 3.2 為止服務就恢復了。我們現在自動和手動做切換，時間都在 10 秒左右，如果 RD 程式有資料庫重試的話應該是沒有影響的。切換完之後會到第 4 步，其實這裡很簡單，就是告訴哨兵主從結構變了，告訴他重新監聽新的主從結構就 OK，這是我們現在平臺去做切換的過程，大家可以借鑑一下。

構建之後的效果和後期計劃——構建之後的效果

說完我們整體的 1.0 版的資料庫自動化運維繫統、2.0 版的系統，以及三個案例之後我們來看一下現在整個線上構建之後的效果，以及我們後期的計劃。這個統計圖是一個開源元件統計的，他可以分析每天我們的一個使用者量，我們每天在這個平臺上跑的 RD 的使用者量大概是在三百多。每天會有三百多 RD 在我們的平臺上做操作，累計的 RD 數目大概是 1461 個，這些是需要跟 DB 打交道的 RD 數量。這個是我們整體平臺跑的效果，你的自動化運維繫統做出來之後做的怎麼樣？不是嘴說的，還是要有質量運營的資料。我們做質量運營，包括使用者數，任務的成功率，平臺的接入率，功能的覆蓋率去衡量整個平臺的指標。

構建之後的效果和後期計劃——後期計劃

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

第三個這個任務執行者現在用不著重，因為他現在需要處理後端的各種各樣的任務，他會越來越重，DBA 可能想要加一個功能，也只能找我加或者我們組內的人去加這個功能，這裡能不能讓 DBA 也參與進來。

構建之後的效果和後期計劃——wew 後期計劃

在這個做完之後我們會有一個後期的計劃，我們需要把整個的架構改造成這樣的，加入兩個東西，一個是核心功能庫和核心元件庫，這兩個東西包含了 API 基礎的核心功能，包括日誌，包括統計，包括許可權校驗都放在核心功能裡，核心元件包括一些 DNS 元件，Atlas 元件、監控都放在這裡操作，API 層只需要負責他的邏輯就行了。

任務執行者也是隻做通用，我只幫你分發任務，幫你做任務的子程式生成，具體誰去做，去調任務執行平臺去做，這樣的話，我只要任務平臺做的足夠好，DBA 或者 RD 只需要把你的指令碼放在這個平臺的下面的目錄裡，就能呼叫整個系統，這樣的話非常方便，讓更多的人蔘與你整個平臺的建設、開發和改造的過程中來。

【本文轉載自美團技術團隊微信公眾號，公眾號ID：meituantech，作者：寧龍，轉載授權請聯絡原作者】

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/31077337/viewspace-2168447/，如需轉載，請註明出處，否則將追究法律責任。