本文整理自美團點評技術沙龍第10期：數據庫技術架構與實踐。

美團點評技術沙龍由美團點評技術團隊主辦，每月一期。每期沙龍邀請美團點評及其它互聯網公司的技術專家分享來自一線的實踐經驗，覆蓋各主要技術領域。

目前沙龍會分別在北京、上海和廈門等地舉行，要參加下一次最新沙龍活動？趕快關注微信公眾號“美團點評技術團隊”。

本次沙龍主要圍繞數據庫相關的主題，內容包括美團數據庫自動化運維系統構建、點評側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的小團，它每天需要對接很多的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還是非常苦惱的。

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

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

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

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

最后就是開發形式，我們整個大的運維部是有開發人員相關資源的，我們找到他們去幫我們做一些頁面，這樣的話，你就會迅速的搭建你的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版的系統做完了之后為什么做2.0版的系統呢？

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

1.0版有什么問題呢？

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

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

第三個就是開發周期長、成本高，得跟他們溝通，需求調整復雜。當然它主要在高并發、高性能上很差，原因是什么？因為后臺是一個常駐內存的進程，我當時只起了大概可能是6個線程就跑了，并發的話只能跑6個，我們2.0版的系統你想跑多少個就跑多少個，我一會兒給大家介紹一下怎么做的，不易擴展，這個也不方便擴展，后臺的任務就一個，掛了就掛了，圖象化做的也不好，畢竟是找人家幫我們做的，效果也不是太好。這個是我們為什么做2.0下定決心的一個原因吧！

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

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

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

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

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

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

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

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

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

說完了以上兩個開源的組建，我們接下來說整個2.0版系統的架構，一點點的放出來，首先是用戶，通過前端的Web，他的所有的操作全部打到我們的API層，業務模塊：腳本也好，系統也好，也是打到我們的API層，這樣做到了接口的統一，后端的處理都是一樣的，不管是任何人，對于我來說都是我的一個端。 API層它可以做兩個事情，比如我想查詢當前數據庫的主從架構情況，當前服務里的數據庫列表，那么API層直接跟CMDB交互獲取數據并返回。第二種是需要后臺做任務的，比如搭建，擴容，拆分這些都是任務，它們需要到后臺的任務管理模塊去做。任務管理模塊會把任務分發下去。這中間會有CMDB。任務管理模塊可以詳細講一下，這個就是剛才我所說的MQ的消息管道，這里是Celery，這里有兩個Celery，你可以理解為它是MQ的封裝，你只需要給Celery通信就可以了。TaskControl是掛載到整個消息中間件上面的一個任務處理者。它會生成父子進程去處理任務。

我剛才說的為什么任務是可以無限地增加，前提是在機器可以承載的情況下無限增加。第一步，TaskControl先fork出一個子進程，第二步，子進程1再fork出一個子進程，這個子進程2，是真正得做任務的進程，這個進程再調用任務執行腳本或者模塊去進行任務操作。子進程1，它會把子進程2的一些信息，比如進程PID，回填到數據庫里，子進程一1就退出了，子進程1退出之后，它跟子進程2的關系就斷開了，這里要說一點，子進程1得忽略回收子進程，這時候子進程2就托管給了init進程，這樣的話就生成了這么一個任務執行單元。任務執行單元只是需要自己去做任務，比如說它去做DDL，這個子進程2是父進程，會去做子進程的回收操作，任務日志的回填工作等。

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

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

說完了上面的整體架構之后我會給大家講三個案例： 第一個案例是我們現有的集群的搭建過程，我先說一下我們線上跑的整體數據庫的四層架構：第一層是業務層，業務層，訪問我們都是通過DNS，DNS下面掛的是虛IP層，虛IP層下面會掛我們的中間件，atlas，每個機房會有并行得部署多個，最下面掛的是數據庫主從架構，這個是現在美團用的線上數據庫主流架構。

現在開始說搭建流程，我說了這么多，大家沒看到我們系統的廬山真面目，這個是我們2.0版本系統的頁面。對于搭建，DBA需要先點擊一下服務組初始化，首先需要去創建一個服務，我們每一個DB集群在數據庫里面都是有一個標識的，被稱做服務組。

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

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

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

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

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

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

第二個我們去選擇atlas，根據分組選擇atlas，就是數據庫中間件，選擇完之后就可以形成這樣的圖。

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

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

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

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

說完了數據庫集群搭建這個案例，我們說第二個案例：在線表變更是怎么做的。首先批量的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，這個是一個開源工具，它做操作的時候，可以做到在線改表的時候不鎖表，當然還會有一些其他的問題，這里不是我們今天所說的重點，大家如果以后有遇到這個工具有什么相關的問題都可以找我們，美團還是踩了非常多的坑，有比較多的經驗。

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

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

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

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

第三個案例是什么呢？就是我們的高可用的解決方案，上面已經列了，美團現在用的是開源的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也參與進來

在這個做完之后我們會有一個后期的計劃，我們需要把整個的架構改造成這樣的，加入兩個東西，一個是核心功能庫和核心組件庫，這兩個東西包含了API基礎的核心功能，包括日志，包括統計，包括權限校驗都放在核心功能里，核心組件包括一些DNS組件，Atlas組件、監控都放在這里操作，API層只需要負責他的邏輯就行了。 任務執行者也是只做通用，我只幫你分發任務，幫你做任務的子進程生成，具體誰去做，去調任務執行平臺去做，這樣的話，我只要任務平臺做的足夠好，DBA或者RD只需要把你的腳本放在這個平臺的下面的目錄里，就能調用整個系統，這樣的話非常方便，讓更多的人參與你整個平臺的建設、開發和改造的過程中來。

總結

以上是生活随笔為你收集整理的美团数据库运维自动化系统构建之路的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。