一文講透貨拉拉混合云數(shù)據(jù)庫體系化建設(shè)

作者簡介：

蔡鵬

前餓了么，螞蟻金服技術(shù)專家，現(xiàn)任貨拉拉數(shù)據(jù)庫部門負(fù)責(zé)人，負(fù)責(zé)貨拉拉混合云化業(yè)務(wù)場景下整體數(shù)據(jù)庫，消息隊(duì)列，緩存，數(shù)據(jù)庫中間件的穩(wěn)定性建設(shè)工作。

內(nèi)容摘要：

貨拉拉作為一家業(yè)務(wù)遍及多個(gè)國家及地區(qū)的物流公司其面臨的技術(shù)環(huán)境是非常復(fù)雜的，在云時(shí)代的浪潮里基于混合云快速構(gòu)建環(huán)境搭建系統(tǒng)成了我們必然的選擇。但是在混合云上如何對(duì)基于各家云構(gòu)建的系統(tǒng)進(jìn)行有效的管理是個(gè)挑戰(zhàn)，尤其對(duì)處在系統(tǒng)最底層的數(shù)據(jù)庫層面臨的問題，業(yè)務(wù)訴求，各方痛點(diǎn)，是我及我的團(tuán)隊(duì)重點(diǎn)解決的。

混合云數(shù)據(jù)庫治理背景介紹

從內(nèi)容上我們可以看到我們面臨的治理環(huán)境其實(shí)是非常復(fù)雜的，幾乎可以用頭大來形容。由于歷史上的種種原因，數(shù)據(jù)庫選型眾多(主要原因是DBA不夠強(qiáng)勢(shì)被研發(fā)主導(dǎo)，研發(fā)想怎么來就怎么來，DBA也沒有替代的解決方案跟合理的拒絕理由，同時(shí)也有語言選型上的Bug:PHP，PHP幾乎是所有問題的萬惡之源，不僅僅體現(xiàn)在DB上還為我們整個(gè)技術(shù)中心的服務(wù)治理埋下很多的坑，此處省略10萬字！致敬這款偉大的語言默默地滋潤了貨拉拉這么多年)，同時(shí)在部署上也缺乏統(tǒng)一規(guī)范，有直接使用云服務(wù)的，也有通過ECS自建的。整體管理水平非常弱，整個(gè)DBA團(tuán)隊(duì)當(dāng)時(shí)也非常弱勢(shì)被研發(fā)拖著走，故障頻發(fā)。

治理面臨的挑戰(zhàn)

1.第一次使用云，對(duì)云的套路不熟悉踩了不少坑，交了很多學(xué)費(fèi)，比如：默認(rèn)打開了某云數(shù)據(jù)庫的回溯功能造成的額外成本問題；某云的續(xù)費(fèi)方式差異造成的額外成本；某云的空閑代理使用問題造成無故的成本問題......這些問題都是我們?cè)诓粩嗟膶?duì)云的了解后發(fā)現(xiàn)的一些問題。這些冤枉成本足夠給公司全體研發(fā)同學(xué)每頓都加只雞腿。

2.除了環(huán)境復(fù)雜外，很多數(shù)據(jù)庫及中間件也是我第一次接觸(也刷新了我對(duì)DBA這個(gè)職業(yè)的新認(rèn)知，或者說擴(kuò)展了我的技能樹)，這么多DB及中間件選型也很難有把握管理的都很到位。

3.云商間的產(chǎn)品化差異也給統(tǒng)一治理&管控帶來很大的挑戰(zhàn)，比如實(shí)現(xiàn)分庫分表可以使用阿里云的DRDS如果換到aws呢？又或者其他云呢？各家云產(chǎn)品解決方案是有差異的，這就給產(chǎn)品跨云移植帶來很大挑戰(zhàn)。

4.面對(duì)當(dāng)前這種多云環(huán)境+多數(shù)據(jù)庫選型如何解決多站點(diǎn)一站式運(yùn)維管控+多云環(huán)境下一致性的運(yùn)維與研發(fā)體驗(yàn)是有一定難度的。

多站點(diǎn)一站式運(yùn)維管控：我不希望每個(gè)數(shù)據(jù)庫及中間件都要單獨(dú)做一個(gè)系統(tǒng)去管控然后各個(gè)站點(diǎn)都單獨(dú)部署一套，這樣做最大的問題是管理分散，DBA運(yùn)維過程體感非常差，這是我非常不希望看到的也是絕對(duì)不能容忍的，我們要做的就是一站式的跨云多站點(diǎn)統(tǒng)一管控平臺(tái)，雖然略微復(fù)雜但是用戶使用體驗(yàn)非常好，技術(shù)本身就是把復(fù)雜留給自己簡單留給用戶，即使是內(nèi)部系統(tǒng)自己使用也堅(jiān)決不妥協(xié)。

多云環(huán)境下的一致性運(yùn)維與研發(fā)體驗(yàn)：比如對(duì)DB來說，我希望經(jīng)過系統(tǒng)對(duì)底層基礎(chǔ)設(shè)施的差異做了屏蔽后會(huì)做一個(gè)統(tǒng)一的呈現(xiàn)而不是對(duì)各個(gè)云商產(chǎn)品進(jìn)行針對(duì)性的設(shè)計(jì)系統(tǒng)，避免造成運(yùn)維過程中的困惑。對(duì)研發(fā)同學(xué)來說，他是完全不需要關(guān)心各家云商產(chǎn)品間的差異性問題，同時(shí)也無需考慮多云環(huán)境下研發(fā)日常涉及數(shù)據(jù)庫的變更/資源申請(qǐng)/數(shù)據(jù)訂閱等可能存在的差異性問題，這些復(fù)雜性由系統(tǒng)統(tǒng)一包掉。

痛點(diǎn)&訴求

1.穩(wěn)定性

歷史上日常故障率實(shí)在是太高了，隔三差五的故障，P2-3家常便飯，P0-1也非常多見

2.研發(fā)效率

DBA完全靠人肉來滿足研發(fā)訴求，研發(fā)跟DBA的交互完全靠吼，研發(fā)很多資源訴求、需求處理、問題排查都難以快速高效的滿足。不過這只是當(dāng)初的表象問題，更大的問題在于如果這些問題不能快速得到解決后續(xù)隨著業(yè)務(wù)的快速發(fā)展技術(shù)團(tuán)隊(duì)的規(guī)?？焖僭鲩L，作為基礎(chǔ)技術(shù)支撐團(tuán)隊(duì)一定會(huì)出現(xiàn)更多更嚴(yán)重的問題，這些都是可以預(yù)想到的畢竟經(jīng)歷過類似的快速成長的公司基本上會(huì)有相應(yīng)的心理預(yù)判。

3.成本

在自建機(jī)房時(shí)代只要購買一次機(jī)器可以用上3~5年這期間可以不用一直付費(fèi)，云上付費(fèi)方式的差異可能會(huì)讓老板覺得一直在花錢(畢竟每個(gè)月都有賬單)。也許這是開玩笑不過當(dāng)時(shí)是非常難以理解在一個(gè)快速成長的公司成本訴求來的太早了，這會(huì)對(duì)業(yè)務(wù)發(fā)展甚至穩(wěn)定性產(chǎn)生一些掣肘。不過在一年后的今天來看確實(shí)是非常有必要的(我們?cè)谄脚_(tái)化后通過初步的數(shù)據(jù)分析后發(fā)現(xiàn)資源使用不合理居然普遍存在，我們?cè)贒B上節(jié)約的成本就相當(dāng)可觀，后續(xù)會(huì)介紹)。

不管是面對(duì)研發(fā)還是DBA自身又或者是老板各種的“不講道理”都有不小的壓力，但這又是不得不解決的問題。

治理基本思路

1.做減法

從一個(gè)我看到的現(xiàn)象說起，我注意到研發(fā)有高頻的訂正數(shù)據(jù)的需求，正常我想這是不應(yīng)該的，除了個(gè)別的誤操作及運(yùn)營特殊需求不應(yīng)該有這樣的需求。后來經(jīng)過了解后發(fā)現(xiàn)這樣的一個(gè)現(xiàn)象比如由于訂單邏輯的復(fù)雜性一部分?jǐn)?shù)據(jù)在落庫時(shí)寫MySQL，一部分?jǐn)?shù)據(jù)要寫mongo或者ES或者Redis，用這些產(chǎn)品本身是沒問題的但是如果打包到一個(gè)業(yè)務(wù)邏輯里面就有問題了總會(huì)出現(xiàn)類似無法保證事務(wù)一致性的問題。當(dāng)然里面有業(yè)務(wù)使用姿勢(shì)的問題，但是另外一個(gè)非常重要的原因是業(yè)務(wù)在設(shè)計(jì)之初缺乏合理的設(shè)計(jì)，或者說為了簡單濫用了數(shù)據(jù)庫的某些能力，比如為避免關(guān)系型數(shù)據(jù)庫ddl麻煩的問題就想著用mongo來代替 最終也是一個(gè)挖坑操作，另外一方面很多數(shù)據(jù)庫選型是我們hold不住的，不是不能投入時(shí)間去研究而是在有限的時(shí)間要解決最關(guān)鍵的問題。結(jié)合我過往的經(jīng)驗(yàn)看，還沒見到一家公司的業(yè)務(wù)復(fù)雜到需要近10款數(shù)據(jù)庫類型才能支撐的(警惕研發(fā)的肆意的缺乏大局觀的數(shù)據(jù)庫選型DBA有權(quán)利say no)，因此砍掉一些數(shù)據(jù)庫選型盡管有不理解但是也要堅(jiān)決的推行，DBA也不再接受研發(fā)過去的套路(通常的臺(tái)詞是：系統(tǒng)已經(jīng)開發(fā)完畢了明天要上線...)找回DBA丟失的話語權(quán)也是給DBA對(duì)外打交道上建立一點(diǎn)自信，當(dāng)然減少數(shù)據(jù)庫選型也一定程度上降低了后續(xù)平臺(tái)化的復(fù)雜度，畢竟時(shí)間有限。

2.定義規(guī)范

過去是完全沒有規(guī)范的或者錯(cuò)誤的規(guī)范，同時(shí)我們要明確DBA的職責(zé)及SLA保障標(biāo)準(zhǔn)，目的就是告訴研發(fā)該做什么不該做什么(比如研發(fā)過程使用某種我們不支持的數(shù)據(jù)庫則不準(zhǔn)上線！)及各種要遵循的規(guī)范化的內(nèi)容。DBA提供SLA保障標(biāo)準(zhǔn)也是對(duì)DBA嚴(yán)格要求，通過建立規(guī)范標(biāo)準(zhǔn)讓DBA有“法”可依，最起碼也是起到保護(hù)DBA的作用。規(guī)范的建立如果只是文字性的內(nèi)容往往是沒有意義的，必須是能寫進(jìn)代碼里同時(shí)也要做好系統(tǒng)收口才能良好的執(zhí)行，否則就是一紙空文(只有在跟產(chǎn)研打官司的時(shí)候有用，只是不希望發(fā)生這種情況)，因此平臺(tái)化是非常必要的。

3.建能力

如何通過平臺(tái)化方式解決當(dāng)下的問題，或者落地具體的治理手段。

4.70分標(biāo)準(zhǔn)

我們沒有非常充足的時(shí)間去追求完美，優(yōu)先解決核心的問題做到差不多就行了，然后解決另外一個(gè)核心問題，也就是小步快跑絕對(duì)不在某個(gè)不完美的點(diǎn)上磨磨唧唧，留在后續(xù)在不斷的迭代優(yōu)化穩(wěn)步向前推進(jìn)，但是也要爭取做一個(gè)功能就成功一個(gè)，否則面對(duì)這么多功能要做總是失敗會(huì)打擊自己跟團(tuán)隊(duì)的自信，先取得一個(gè)個(gè)的小目標(biāo)再計(jì)劃后續(xù)。

5.優(yōu)先解決生存問題

DBA很長一段時(shí)間里陷入到對(duì)研發(fā)人工支持上，比如：經(jīng)常忙到很晚的發(fā)布，日常的資源交付，協(xié)助研發(fā)線上問題排查，各類研發(fā)工單處理等。這些日常事務(wù)極大的消耗了DBA的精力，DBA長期掙扎在這些日常事務(wù)處理上無暇他顧形成惡性循環(huán)。如何通過平臺(tái)化手段解決這些問題讓DBA從泥潭中抽身是所有問題中的最優(yōu)先要解決的。

平臺(tái)整體架構(gòu)

1.技術(shù)棧

應(yīng)該算是相對(duì)主流的技術(shù)棧選擇，語言選擇上沒有優(yōu)劣，只要自己掌握的了都不影響實(shí)現(xiàn)結(jié)果。只是不同語言特性的可能會(huì)比較適合解決特定場景下的問題，比如我們要做Agent選擇Python顯然就不是一個(gè)特別好的選擇。

2.功能層面

主要面向跟DBA跟研發(fā)，為了方便DBA能隨時(shí)隨地處理問題，做了自己的小程序，比如在地鐵里能做一下工單的審批及其他常規(guī)操作需求，或者躺床上盯盤等，提升工作效率跟幸福感。研發(fā)能自助解決日常的大部分問題避免跟DBA有過度交互。

3.統(tǒng)一網(wǎng)關(guān)

一般簡易的單點(diǎn)平臺(tái)是不需要網(wǎng)關(guān)層的，一個(gè)Django就解決了。由于我們要通過一個(gè)平臺(tái)解決多節(jié)點(diǎn)管控問題，我們平臺(tái)服務(wù)層(Service-API)都是微服務(wù)化多站點(diǎn)部署的，此時(shí)微服務(wù)化的下統(tǒng)一網(wǎng)關(guān)就顯得很有必要。前端跟后端交互時(shí)只要在Header里面帶上Region信息即可正確的路由到指定的服務(wù)節(jié)點(diǎn)。

平臺(tái)在設(shè)計(jì)之初就考慮到多站點(diǎn)的統(tǒng)一管理問題，我是非常不希望看到一套系統(tǒng)在各個(gè)站點(diǎn)反復(fù)部署的使用體驗(yàn)簡直不要太差！這里是稍微介紹一下為什么需要統(tǒng)一網(wǎng)關(guān)如圖：

這種微服務(wù)化的架構(gòu)在部署跟實(shí)際使用過程中對(duì)DBA及研發(fā)體驗(yàn)都非常好。

數(shù)據(jù)總線：

主要用于數(shù)據(jù)(監(jiān)控metric類數(shù)據(jù)非業(yè)務(wù)數(shù)據(jù))傳輸使用，比如從最遠(yuǎn)端的站點(diǎn)A到集中管控系統(tǒng)部署站點(diǎn)的網(wǎng)絡(luò)延遲在600ms如果A站點(diǎn)的監(jiān)控?cái)?shù)據(jù)要往管理站點(diǎn)上報(bào)要通過網(wǎng)絡(luò)直接上報(bào)就顯得很困難。

為了減少過多的Kafka部署增加運(yùn)維的復(fù)雜性我們其他站點(diǎn)的監(jiān)控?cái)?shù)據(jù)統(tǒng)一上報(bào)到一個(gè)網(wǎng)絡(luò)距離上處在相對(duì)中間的kafka集群，然后在通過mirror的方式將監(jiān)控?cái)?shù)據(jù)同步到管控節(jié)點(diǎn)進(jìn)行集中的消費(fèi)處理，整體看監(jiān)控?cái)?shù)據(jù)從最遠(yuǎn)端的站點(diǎn)傳回到集中管控節(jié)點(diǎn)通常控制在1s內(nèi)整體可以接受，其實(shí)最主要的是監(jiān)控?cái)?shù)據(jù)寫到Kafka避免監(jiān)控?cái)?shù)據(jù)因?yàn)榫W(wǎng)絡(luò)原因?qū)е聛G失。

平臺(tái)組件集：

其他組件后續(xù)會(huì)陸續(xù)介紹，這里簡單介紹一下任務(wù)調(diào)度

DBA日常工作中肯定會(huì)有很多定時(shí)任務(wù)要維護(hù)即使平臺(tái)化了也仍舊需要，過去DBA是將這些任務(wù)通過crontab進(jìn)行管理，但是這樣是很局限的，比如獲取執(zhí)行狀態(tài)、結(jié)果、日志比較麻煩，存在單點(diǎn)問題，腳本分散化不利于維護(hù)，年久容易失修一但被遺忘里面的腳本邏輯中可能會(huì)產(chǎn)生破壞作用，存在安全隱患，為此我們單獨(dú)實(shí)現(xiàn)了一個(gè)調(diào)度管理系統(tǒng)對(duì)散落在各個(gè)站點(diǎn)上的任務(wù)進(jìn)行統(tǒng)一集中管理。

調(diào)度本身實(shí)現(xiàn)是比較簡單的可以理解成crontab的網(wǎng)絡(luò)版，只是在調(diào)度本身的基礎(chǔ)上添加了一些管理模塊如:節(jié)點(diǎn)注冊(cè)，通訊模塊，心跳檢測(cè)等，如果不清楚crontab實(shí)現(xiàn)原理的可以搜索Github有比較多的實(shí)現(xiàn)參考方式。其實(shí)功能還是比較簡單的只是實(shí)現(xiàn)了調(diào)度的基本功能跟分布式部署，時(shí)間關(guān)系(70分標(biāo)準(zhǔn))并未來得及將節(jié)點(diǎn)實(shí)現(xiàn)集群化避免調(diào)度單點(diǎn)問題比如某一個(gè)調(diào)度節(jié)點(diǎn)down機(jī)其他節(jié)點(diǎn)會(huì)自動(dòng)接管。

添加一個(gè)任務(wù)：

注冊(cè)一個(gè)腳本:

任務(wù)管理：

通過調(diào)度系統(tǒng)很快就完成收攏散落在各個(gè)站點(diǎn)上的crontab任務(wù)。

MySQL平臺(tái)化建設(shè)

監(jiān)控報(bào)警

健康大盤:

通過對(duì)數(shù)據(jù)庫近50個(gè)監(jiān)控指標(biāo)的權(quán)重打分得到一個(gè)數(shù)據(jù)庫實(shí)例的健康度，Dashboard直接按照健康度排序即可一眼看透當(dāng)前所有實(shí)例的健康狀況，同時(shí)在做權(quán)重打分時(shí)也會(huì)順帶將有問題的地方做好描述，方便DBA直接通過系統(tǒng)一眼定位問題。大致是這樣的:

當(dāng)然為了方便DBA能對(duì)問題進(jìn)行快速深入的分析處理，我們幾乎將DBA所有常用操作都封裝到了監(jiān)控大盤的快捷操作中。如：SQL快照(包含用戶，狀態(tài)，時(shí)間，鎖信息等)，實(shí)時(shí)抓取SQL信息，Kill SQL，SQL限流/熔斷，報(bào)警屏蔽等。日常工作中盡量避免DBA通過命令行登錄到數(shù)據(jù)庫實(shí)例進(jìn)行黑屏操作，這個(gè)是我們形成共識(shí)，不管多么資深的DBA一定在命令行模式下犯過一些低級(jí)錯(cuò)誤??！因此平臺(tái)化要能覆蓋到這些微小的點(diǎn)。

報(bào)警：

我們數(shù)據(jù)庫的報(bào)警量還是比較多的（每天2-500條左右），這也是我們做的不夠好的地方，回顧我經(jīng)歷過的一些公司或者了解到的一些公司幾乎都是有類似的問題，甚至每天收到上千條報(bào)警的也不在少數(shù)，報(bào)警看似是非常簡單的但是要做好其實(shí)是非常困難的，既想報(bào)警少，又想核心報(bào)警不能漏，有時(shí)大家為了減少報(bào)警甚至是想干掉報(bào)警本身，而不是是去想著去解決問題，這是本末倒置的。

其實(shí)很多報(bào)警是可以不用發(fā)出來的，因?yàn)榘l(fā)出來也沒有人去進(jìn)一步處理或者被自愈系統(tǒng)自動(dòng)處理掉了，但是種種原因考慮又不得不發(fā)，在治理水平跟不上時(shí)寧愿多報(bào)也不能漏報(bào)(漏報(bào)關(guān)鍵報(bào)警信息是非常嚴(yán)重的，如果有問題則罪加一等)。報(bào)警多其實(shí)反應(yīng)的是治理水平?jīng)]有跟上，有些問題看似是非致命性問題，但是如果長期不去處理問題最終會(huì)被放大甚至惡化成故障。我們的做法是將報(bào)警數(shù)據(jù)化統(tǒng)計(jì)分析呈現(xiàn)每日趨勢(shì)重點(diǎn)盯住報(bào)警趨勢(shì)線安排專人跟進(jìn)，將趨勢(shì)線控制在合理的范圍，從統(tǒng)計(jì)數(shù)據(jù)上解決面的問題而不是點(diǎn)對(duì)點(diǎn)的解決某一個(gè)問題。

運(yùn)維管理

此前數(shù)據(jù)庫的基礎(chǔ)信息一直是存放Excel里面的所以很難想象這種Excel式運(yùn)維有多痛苦！需要通過系統(tǒng)方式進(jìn)行有效管理，只有這些基本元數(shù)據(jù)信息有效的管理起來后續(xù)功能才能依次展開，比如集群包含的實(shí)例信息，集群與集群組間的關(guān)系等，數(shù)據(jù)庫與集群的關(guān)系，數(shù)據(jù)庫內(nèi)的對(duì)象信息等等。有了這些基本信息在對(duì)其打上各類運(yùn)維需要的標(biāo)簽信息方便做更多細(xì)粒度的管理工作。

運(yùn)維中很重要的一個(gè)工作就是發(fā)布尤其是在公司高速發(fā)展階段產(chǎn)品功能快速迭代自然就涉及大量的發(fā)布工作，為了減輕DBA的負(fù)擔(dān)讓研發(fā)不在受制于DBA人力問題我們需要將他自助化。

研發(fā)可以通過系統(tǒng)自助完成發(fā)布工作，這里比較麻煩的是如何做好用戶間的權(quán)限隔離避免誤發(fā)布，這里需要結(jié)合公司SSO+系統(tǒng)元數(shù)據(jù)管理，其中系統(tǒng)元數(shù)據(jù)的有效性是整個(gè)系統(tǒng)能否做成功的最關(guān)鍵的因素，我們不能依靠DBA來維護(hù)元數(shù)據(jù)信息，必須依靠完善的系統(tǒng)機(jī)制保證做到元數(shù)據(jù)接近準(zhǔn)實(shí)時(shí)狀態(tài)，比如DB跟用戶組織結(jié)構(gòu)的關(guān)聯(lián)問題，我們采用類似協(xié)商的機(jī)制來保障他們間的絕對(duì)準(zhǔn)確，比如A先認(rèn)領(lǐng)了數(shù)據(jù)庫DB1,B用戶也來認(rèn)領(lǐng)該數(shù)據(jù)庫如果他們同屬一個(gè)組織結(jié)構(gòu)則B的認(rèn)領(lǐng)是合法的否則會(huì)被系統(tǒng)拒絕，后續(xù)如果A或者B組織結(jié)構(gòu)發(fā)生調(diào)整則涉及該數(shù)據(jù)庫的發(fā)布操作將被禁止，用戶必須內(nèi)部完成協(xié)商要么帶走這個(gè)數(shù)據(jù)庫(別人取消認(rèn)領(lǐng))，要么留下這個(gè)數(shù)據(jù)庫(自己取消認(rèn)領(lǐng))。類似的場景在系統(tǒng)里面有多處，如果依靠DBA來管理這些變化是非常困難的，因此元數(shù)據(jù)的自閉環(huán)管理是整個(gè)系統(tǒng)最底層的邏輯，元數(shù)據(jù)必須是100%可靠的。很多系統(tǒng)比如CMDB之所以難做或者很少有公司CMDB能做好，個(gè)人理解很重要的一個(gè)原因就是在這里沒做好。

發(fā)布系統(tǒng)實(shí)現(xiàn)上其實(shí)是有很多的復(fù)雜性的不僅僅是業(yè)務(wù)邏輯復(fù)雜，比如Sharding表跟普通表如何區(qū)分，Sharding表要怎么處理才能保證效率跟安全問題，大量DDL任務(wù)下發(fā)到執(zhí)行服務(wù)器（DDL執(zhí)行節(jié)點(diǎn)）如何保證執(zhí)行節(jié)點(diǎn)不被打掛（我們基于gh-ost改造實(shí)現(xiàn)DDL，DDL過程會(huì)有非常大的Binlog解析動(dòng)作，如果并發(fā)控制不好會(huì)導(dǎo)致執(zhí)行節(jié)點(diǎn)網(wǎng)卡被打爆）等等這些都是比較復(fù)雜的問題。當(dāng)然整個(gè)發(fā)布流程還涉及很多基礎(chǔ)組件的設(shè)計(jì)開發(fā)工作，比如SQLReview/gh-ost/Rollback后續(xù)篇幅將依次介紹，發(fā)布系統(tǒng)使用簡單但是開發(fā)過程確是一個(gè)系統(tǒng)性的工程有比較大的工作量，我們目前研發(fā)自助發(fā)布率幾乎接近100%，DBA不用在忙到半夜搞發(fā)布。

應(yīng)急/自愈

數(shù)據(jù)庫需要應(yīng)急的場景最多的就是SQL把數(shù)據(jù)庫打垮了，此前我們是通過操作阿里云的管理后臺(tái)實(shí)現(xiàn)限流，但是這個(gè)方法只能使用于阿里云數(shù)據(jù)庫，我們還有其他云數(shù)據(jù)庫選型，而且操作阿里云限流效率不是特別的高，要登錄到控制臺(tái)，然后還要根據(jù)出問題的InstanceID找對(duì)應(yīng)的實(shí)例，再找到管理頁面操作......而且沒有提供SDK操作不夠便利，還記得我們前面一直提到的提供一致性的運(yùn)維與研發(fā)體驗(yàn)嗎？作為平臺(tái)研發(fā)就要考慮通用的解決方案，比如通過我們自己的中間件來實(shí)現(xiàn)統(tǒng)一限流這樣就不存在云上產(chǎn)品差異的問題，內(nèi)部系統(tǒng)操作上也便利，也有sdk接口跟我們的DMS系統(tǒng)對(duì)接。

還有諸如冒煙事件處理自愈系統(tǒng)會(huì)實(shí)時(shí)檢測(cè)系統(tǒng)存在的異常比如:未提交事務(wù)，鎖等待，連接數(shù)飆升，長查詢，SQL執(zhí)行堆積，CPU飆升等系統(tǒng)會(huì)實(shí)時(shí)檢測(cè)并針對(duì)性的啟動(dòng)相關(guān)處理規(guī)則將冒煙撲滅避免冒煙演變成火災(zāi)。

數(shù)據(jù)統(tǒng)計(jì)分析

通過平臺(tái)的任務(wù)管理部署采集腳本每天對(duì)系統(tǒng)表:tables，table_io_waits_summary_by_index_usage，table_io_waits_summary_by_table進(jìn)行采集分析我們可以清楚的知道當(dāng)前那些DB/Table的冷熱度情況，每張表的每個(gè)索引使用情況(那些未使用)，為后續(xù)治理提供數(shù)據(jù)支撐，比如隨著業(yè)務(wù)的迭代很多庫跟表已經(jīng)被遺棄了但是長期存在于數(shù)據(jù)庫中DBA又不能刪除清理掉，尤其在云上這就涉及資源閑置跟成本浪費(fèi)，即使出于DBA的潔癖也應(yīng)該及時(shí)識(shí)別出這些數(shù)據(jù)進(jìn)行清理(這些殘留信息存在的越久則治理越腐朽)。

慢查詢是相對(duì)簡單的功能，但是由于各家云上產(chǎn)品差異，我們系統(tǒng)對(duì)每家云產(chǎn)品特點(diǎn)做了針對(duì)性封裝，比如阿里云我們直接通過SDK獲取，AWS則要下載文件到本地化然后進(jìn)行分析然后在統(tǒng)一呈現(xiàn)，這還是比較麻煩的，我們目前已經(jīng)放棄該方案，所有DB都已經(jīng)接了數(shù)據(jù)庫中間件，所有的SQL都通過旁路的方式落庫，數(shù)據(jù)庫中間件對(duì)SQL打有足夠多的標(biāo)簽描述不僅僅能反應(yīng)出慢查詢的情況，還能根據(jù)全量SQL做更多分析工作，由于SQL量非常巨大要想存儲(chǔ)起來分析是很難的我們采用了折中的方案，中間件會(huì)根據(jù)SQL指紋對(duì)SQL采用聚合這樣落庫的SQL數(shù)量就呈現(xiàn)指數(shù)級(jí)下降便于統(tǒng)計(jì)與分析。

DB上云與自建的差別

上述功能其實(shí)都不涉及傳統(tǒng)自建時(shí)代圍繞基礎(chǔ)設(shè)施做的一系列的建設(shè)工作，功能本身更多是聚焦業(yè)務(wù)功能本身，因此開發(fā)過程中相對(duì)還是輕量的。如果自建則要考慮的問題非常多從硬件，系統(tǒng)，數(shù)據(jù)庫，HA等等都是非常復(fù)雜的，過去DBA在這塊積累的大量的經(jīng)驗(yàn)每個(gè)資深DBA可能在這塊都有專屬于自己的黑科技，這也是DBA過去比較有價(jià)值跟難以替代的地方，但是隨著DB的上云成為趨勢(shì)傳統(tǒng)的做法正在成為歷史也逐漸的被新入行的DBA所淡忘，云對(duì)基礎(chǔ)設(shè)施的封裝是時(shí)代的進(jìn)步。

回想10年前入行的時(shí)候那時(shí)還是11k/15k的SAS盤，還在折騰什么場景該用Raid10，還是Raid5，是Write Through還是Write Back，不同機(jī)型配置下my.cnf該怎么設(shè)置，OS內(nèi)核調(diào)參，不同數(shù)據(jù)庫版本下特性有什么不同尤其復(fù)制的改進(jìn)對(duì)實(shí)現(xiàn)HA起到什么影響，HA該怎么選做是MMM還是MHA還是ORC還是自己做一個(gè)HA系統(tǒng)，如何快速安裝部署，快速搭建主從，備份是物理還是邏輯備份等等，這些隨著技術(shù)的進(jìn)步及云的進(jìn)一步滲透這些正在成為遠(yuǎn)古記憶。

MySQL中間件建設(shè)

自建中間件其實(shí)是有很多考量因素主要集中在這3點(diǎn):

1.統(tǒng)一數(shù)據(jù)庫保護(hù)層

前文提到混合云下云產(chǎn)品的差異性不同，不同云產(chǎn)品對(duì)數(shù)據(jù)庫保護(hù)機(jī)制不一樣也不開放SDK，此外由于云上實(shí)例規(guī)格普遍都是小規(guī)格一般都是購買4C/8C這樣規(guī)格，這樣的小規(guī)格下應(yīng)對(duì)異常情況下的抗壓能力其實(shí)是非常差的，跟自建時(shí)普遍32C的規(guī)格比可能一個(gè)執(zhí)行計(jì)劃不是非常理想的查詢就可以導(dǎo)致cpu被打滿導(dǎo)致數(shù)據(jù)庫進(jìn)一步惡化加速，為此我們建設(shè)了自己的數(shù)據(jù)庫中間件提供統(tǒng)一的保護(hù)機(jī)制，中間件有一個(gè)SQL執(zhí)行隊(duì)列，一但遇到數(shù)據(jù)庫性能惡化RT增加隊(duì)列就會(huì)堆積中間件就會(huì)感知到數(shù)據(jù)庫的響應(yīng)異常會(huì)主動(dòng)的啟動(dòng)保護(hù)機(jī)制，此時(shí)DBA監(jiān)控系統(tǒng)也會(huì)感知到DB的異常情況此時(shí)借助DMS的快速分析處理能力可以快速定位具體的SQL緊接著就可以啟動(dòng)針對(duì)SQL的限流或者熔斷機(jī)制，保證數(shù)據(jù)庫的安全。

2.數(shù)據(jù)庫可擴(kuò)展問題

即使在云上數(shù)據(jù)庫規(guī)格也是有限的，貨拉拉運(yùn)營這么多年加上近兩年訂單不斷的翻倍累計(jì)了幾百TB的數(shù)據(jù)，這些數(shù)據(jù)很難通過單實(shí)例的方式存儲(chǔ) 雖然過去貨拉拉也做了分庫分表但是支撐非常困難（這些開源的中間件問題比較多很難被hold住距離一款商業(yè)化的產(chǎn)品還有比較遠(yuǎn)的距離，因此一個(gè)開源產(chǎn)品如果用于核心場景必須是能hold住的，否則出問題那叫一個(gè)干著急?。?。

云上目前已經(jīng)有很多分布式數(shù)據(jù)庫或者可以水平擴(kuò)展的數(shù)據(jù)庫選型但還是不能被我們直接使用，一方面不夠熟悉，另一方面各家云商產(chǎn)品標(biāo)準(zhǔn)不一樣，最后就是價(jià)格太貴何況我們也還沒到海量數(shù)據(jù)的程度殺雞無需用牛刀，而且引入一款新的數(shù)據(jù)庫考慮因素太多了如果只是單一云環(huán)境嘗鮮新數(shù)據(jù)庫選型也可以考慮但是多云環(huán)境下按照云商的推薦去搞會(huì)導(dǎo)致數(shù)據(jù)庫選型泛濫最終會(huì)制造無限的麻煩，還是盡量選擇能被完全把控的方案相對(duì)穩(wěn)妥。可以預(yù)見未來企業(yè)肯定也是以混合云為主如何做好產(chǎn)品選擇是很重要的，一定要考慮好產(chǎn)品間的兼容性與業(yè)務(wù)系統(tǒng)程序的可移植性，避免跨云移植水土不服，不兼容是必然存在的作為核心基礎(chǔ)設(shè)施的我們?cè)谀芰ㄔO(shè)上要充分的考慮跟對(duì)應(yīng)的能力建設(shè)工作。

3.多語言統(tǒng)一訪問層

創(chuàng)業(yè)型公司語言選擇往往是很混亂的PHP，Python，Go，Java可能都會(huì)有，幾年前在餓廠的時(shí)候就聽過這樣一句話:“語言的選擇可能會(huì)決定一家公司的成敗”，比如貨拉拉以PHP為主，它的整個(gè)生態(tài)或者語言局限給后續(xù)上規(guī)?；蟮墓芾怼⑦\(yùn)維、服務(wù)治理帶來很多問題，甚至這種小語種都找不到靠譜的開發(fā)更別提其生態(tài)建設(shè)了。比如在數(shù)據(jù)庫上普遍采用短連接有的核心服務(wù)就有幾百個(gè)Pod高峰期數(shù)據(jù)庫連接數(shù)大幾千個(gè)，這對(duì)于小規(guī)格內(nèi)存只有16G/32G左右的實(shí)例來說實(shí)在是太重了，接入中間件后連接數(shù)直接能從5000降低到300這還是非?？捎^的。這里順便說一句之所以緩存既選擇了Codis又有哨兵，還有Cluster，這里跟PHP都有一定關(guān)系，其中PHP業(yè)務(wù)就是Codis為主（所以前面吐槽php的原因就在這里，當(dāng)然吐槽的不僅僅是數(shù)據(jù)庫還有服務(wù)治理上的...），為了適應(yīng)PHP的長期存在我們也在對(duì)Redis進(jìn)行Mesh化建設(shè)與治理暫且按下不表。

同時(shí)的在數(shù)據(jù)庫的深度可觀測(cè)性上可以做更多工作，過去對(duì)熱點(diǎn)SQL/SQL分布/RT分布是很難有合適的手段的（雖然后續(xù)有了PS功能但是還是顯得很局限），通過中間件旁路這些信息可以輕松獲取到。

有了中間件的加持+DBA服務(wù)治理+平臺(tái)建設(shè)數(shù)據(jù)庫的穩(wěn)定性有了長效的保障機(jī)制。中間件的建設(shè)也為了解決一致性運(yùn)維與研發(fā)體驗(yàn)提供一些支持。

MySQL基礎(chǔ)工具建設(shè)

自愈系統(tǒng)：

系統(tǒng)會(huì)實(shí)時(shí)感知到數(shù)據(jù)庫負(fù)載情況，結(jié)合數(shù)據(jù)庫中間件的能力快速作出決策進(jìn)行限流或者SQL查殺，同時(shí)基于云的彈性能力進(jìn)行自動(dòng)擴(kuò)容云上都有類似的ModifyDBInstanceSpec接口，比如檢測(cè)到空間不足則立即擴(kuò)容，因此我們可以將實(shí)例空間維持在一個(gè)很高的使用水位盡量成本合理化。

SQLReview

目前在業(yè)內(nèi)有很多開源的解決方案但是我還是堅(jiān)持自己做了一個(gè)，理由也很簡單可以自由靈活的個(gè)性化定制，不僅僅覆蓋面要全面，同時(shí)也融入DBA經(jīng)驗(yàn)性的內(nèi)容，可以基于統(tǒng)計(jì)數(shù)據(jù)做公司內(nèi)的“大數(shù)據(jù)”分析可以清楚的知道大家整體容易在什么地方犯錯(cuò)，哪些團(tuán)隊(duì)做的好哪些團(tuán)隊(duì)做的差等。同時(shí)自研一個(gè)因?yàn)橥耆躧old住跟其他自研系統(tǒng)可以無縫對(duì)接高度的靈活，此外還針對(duì)性的對(duì)貨拉拉過去規(guī)范上的錯(cuò)誤或者不足做出識(shí)別與糾正，如果基于開源就不太容易做到或者有一定改造成本。

SQLReview核心模塊就是SQL解析這個(gè)參考了TIDB的實(shí)現(xiàn)模塊有興趣的可以看下其核心解析模塊：githup.com/pingcap/tidb/ast，githup.com/pingcap/tidb/parser，不過這塊隨著源碼的不斷提交會(huì)有一定的差異，如果我們一直跟著官方最新代碼包去編譯容易產(chǎn)生非預(yù)期問題，建議是本地化包管理或者干脆把這個(gè)解析模塊單獨(dú)扣出來。

關(guān)于審核規(guī)則一方面充分吸收了開源系統(tǒng)的的一些規(guī)則還融入了一些DBA經(jīng)驗(yàn)理解及過往錯(cuò)誤規(guī)則糾正:

這些會(huì)在研發(fā)提交到發(fā)布系統(tǒng)前進(jìn)行統(tǒng)一的校驗(yàn)。

gh-ost建設(shè)

gh-ost(相信很多人已經(jīng)對(duì)他很熟悉了)只是一個(gè)單純的DDL工具，如果跟平臺(tái)進(jìn)行整合還是要做一些改動(dòng)的，以適應(yīng)我們多站點(diǎn)化的部署：

根據(jù)統(tǒng)計(jì)我們平均每天的DDL量超過200+，如果是sharding一個(gè)邏輯表的DDL會(huì)被拆分成1024個(gè)DDL，如果這些DDL由一臺(tái)機(jī)器來完成是非常困難的，而且研發(fā)在提交發(fā)布的時(shí)候可能都集中在發(fā)布窗口自動(dòng)打開之后的一段時(shí)間內(nèi)，因此即使在同一個(gè)站點(diǎn)內(nèi)執(zhí)行節(jié)點(diǎn)也需要部署多個(gè)，每次向執(zhí)行節(jié)點(diǎn)分發(fā)任務(wù)都會(huì)根據(jù)執(zhí)行節(jié)點(diǎn)的任務(wù)數(shù)來做均衡分發(fā)。之所以還需要在每個(gè)執(zhí)行節(jié)點(diǎn)維護(hù)一個(gè)執(zhí)行隊(duì)列，主要是因?yàn)間h-ost本身導(dǎo)致的簡單回顧一下其基本原理：

由于其通過拉取并解析Binlog來代替PT的觸發(fā)器機(jī)制因此當(dāng)對(duì)Binlog產(chǎn)生量比較大的實(shí)例進(jìn)行DDL時(shí)網(wǎng)絡(luò)帶寬會(huì)比較高，當(dāng)多個(gè)任務(wù)同時(shí)進(jìn)行時(shí)帶寬可能會(huì)被打滿(在云上DMS使用的ECS，EC2網(wǎng)絡(luò)配置都不是特別高基本都在4C~8C、2Gb~5Gb帶寬)，同時(shí)CPU也會(huì)很高主要是gh-ost要對(duì)記錄做循環(huán)的逐行逐列處理，系統(tǒng)高負(fù)載下會(huì)導(dǎo)致DDL失敗的概率增加。所以在每個(gè)執(zhí)行節(jié)點(diǎn)上都加入了一個(gè)任務(wù)隊(duì)列通過線程池做穩(wěn)妥的并行化控制避免相互影響。

此外還通過網(wǎng)絡(luò)模塊對(duì)其進(jìn)行良好的控制比如優(yōu)雅終止，還有日志的閹割(其日志實(shí)在是有點(diǎn)啰嗦)，由于比較簡單不做贅述。

Flashback(DML回滾)

我們并沒有將回滾內(nèi)置到DMS發(fā)布系統(tǒng)里面主要還是嫌麻煩，畢竟實(shí)際需要回滾的場景還是非常稀少的，內(nèi)置到發(fā)布系統(tǒng)做起來有點(diǎn)重當(dāng)然好處是需要用的時(shí)候很快捷，我們是在gh-ost執(zhí)行過程中埋點(diǎn)關(guān)鍵點(diǎn)位信息：start binlogfile~end binlogfile，start pos~end pos，ThreadID 有這幾個(gè)關(guān)鍵點(diǎn)位信息根據(jù)ThreadID可以精確獲取對(duì)應(yīng)變更的BinlogEvents然后生成逆向SQL，其實(shí)很多開源的系統(tǒng)也是這么做的，所不同的是直接根據(jù)Binlog QueryEventData里面的Threadid一邊DML一邊進(jìn)行Binlog解析然后拼裝成對(duì)應(yīng)的逆向SQL保存當(dāng)需要的時(shí)候直接執(zhí)行。

很早以前對(duì)誤操作或者閃回DBA也是傷透腦筋，甚至想出了各種各樣的黑科技做法，比如以正則表達(dá)式為代表的腳本工具類的居多，但是這些都是不靠譜的，隨著對(duì)MySQL的進(jìn)一步深入及開源化建設(shè)（或者說生態(tài)逐步完善）這些實(shí)現(xiàn)變的越來越廉價(jià)，適當(dāng)?shù)恼莆找欢ㄩ_發(fā)能力可能都會(huì)輕松實(shí)現(xiàn)。

不過僅僅是基于一下開源的堆砌是難以做到合理的平臺(tái)化整合，只有深入理解或者對(duì)其代碼邏輯結(jié)構(gòu)有比較多的理解，然后在此基礎(chǔ)上進(jìn)行深入改造融合才能用起來比較趁手。

我們MySQL主要還是圍繞云服務(wù)來進(jìn)行建設(shè)，但是我們還是做了大量的基本能力建設(shè)工作，不是說上云了就是萬事大吉還是有很多事情要去做，云解決了基礎(chǔ)設(shè)施的SLA保障問題，但是業(yè)務(wù)層面的問題還是需要我們自己來解決。

我們的系統(tǒng)完全由DBA自己開發(fā)完成，從前端到服務(wù)端到架構(gòu)到各個(gè)數(shù)據(jù)庫平臺(tái)具體功能細(xì)節(jié)，DBA基本已經(jīng)不是單純的DBA了，在云時(shí)代下DBA需要更加的多元化的能力模型，入門門檻很低（會(huì)操作就行）但是要求確非常高(全棧工程師的要求)，很多新手DBA在云時(shí)代下越來越難以接觸到數(shù)據(jù)庫完整的生命周期管理(從硬件->軟件->資源交->HA...)更多越來越偏向業(yè)務(wù)本身，因此相比過去的老一代DBA是缺少了一點(diǎn)點(diǎn)底蘊(yùn)，不過新手DBA一定不要陷入一個(gè)誤區(qū)：以為會(huì)操作就是玩轉(zhuǎn)了數(shù)據(jù)庫，殊不知當(dāng)前之所以能玩得轉(zhuǎn)可能是因?yàn)闃?gòu)建在當(dāng)前運(yùn)維管理體系下的，如果有一天脫離了這個(gè)體系自己是否還能hold得住。

Redis平臺(tái)化建設(shè)

由于很多因素我們Redis服務(wù)是基于云ECS自建的，Redis本身的運(yùn)維其實(shí)是非常簡單的沒有MySQL那么多復(fù)雜的東西，在基礎(chǔ)功能上涵蓋了DBA日常用到的絕大部分功能。功能實(shí)現(xiàn)上也沒有特別多的復(fù)雜內(nèi)容簡單上圖:

監(jiān)控大盤

出于個(gè)人喜好的原因Redis沿襲了MySQL的大盤套路：

總的來說就要達(dá)到一眼定位問題，同時(shí)將所有DBA排查定位問題，日常操作等功能都集成進(jìn)來比如:

實(shí)例替換

可以快速完成實(shí)例的遷移替換及某一臺(tái)機(jī)器的快速替換。主要用在服務(wù)器內(nèi)存超賣策略下某一個(gè)機(jī)器內(nèi)存不足或者單個(gè)實(shí)例過大時(shí)的便捷操作。由于我們整個(gè)db/緩存/隊(duì)列的資源交付統(tǒng)一是資源id的交付模式原則上底層資源變動(dòng)對(duì)上游業(yè)務(wù)無感:

研發(fā)不用關(guān)注數(shù)據(jù)源的配置是什么，只要將資源id跟appid建立綁定關(guān)系即可訪問到數(shù)據(jù)。

擴(kuò)縮容

擴(kuò)縮縮容的背后系統(tǒng)維護(hù)了一個(gè)資源池我們會(huì)常態(tài)化的保持池內(nèi)有一定的閑置資源確保隨時(shí)可以使用。

全量Key分析

Redis運(yùn)維過程中非常重要的事情就做好Key的分析與監(jiān)測(cè)比如Big key。此前我們做這個(gè)功能的時(shí)候是在每臺(tái)機(jī)器上部署任務(wù)定時(shí)將RDB保存到共享存儲(chǔ)里面然后進(jìn)行集中分析的，這種方案非常的笨重低效，在Agent開發(fā)完善后我們做了全面的改進(jìn):

Agent內(nèi)置了rdb分析功能，同時(shí)也有網(wǎng)絡(luò)模塊提供對(duì)外調(diào)用，由于我們一臺(tái)ecs上部署了多個(gè)節(jié)點(diǎn)，如果Agent同時(shí)分析會(huì)對(duì)服務(wù)器有一定的入侵比如會(huì)占用一定的內(nèi)存資源。為此每個(gè)Service都內(nèi)置一個(gè)調(diào)度模塊做任務(wù)調(diào)度協(xié)調(diào)與任務(wù)分發(fā)，避免集中分析對(duì)服務(wù)器的侵入。我們對(duì)rdb的分析本身也做了很多細(xì)致工作，比如我們?cè)谕ㄟ^開源工具分析rdb時(shí)發(fā)現(xiàn)，對(duì)于比較大的rdb文件分析時(shí)會(huì)占用非常多的系統(tǒng)內(nèi)存，這是不符合Agent低侵入要求的，我們經(jīng)過通過Agent做超過20G的rdb分析Agent整體內(nèi)存也始終會(huì)控制在100MB以內(nèi)。

Agent基于go實(shí)現(xiàn)無其他依賴，每臺(tái)DBA交付的ECS/EC2上默認(rèn)會(huì)部署并啟動(dòng)Agent，Agent會(huì)主動(dòng)報(bào)告我是誰(ip)在哪里(region:區(qū)域/節(jié)點(diǎn))，因此基于Agent我們可以做很多自動(dòng)化運(yùn)維的事情，比如做自動(dòng)化的安裝部署等。

由于歷史原因選型上有云redis/哨兵(占比80%)/codis/cluster，出于統(tǒng)一運(yùn)維標(biāo)準(zhǔn)的考慮，統(tǒng)一采用cluster模式，因此其他選型到今天已基本被淘汰，cluster在可擴(kuò)展性上會(huì)有更多的優(yōu)勢(shì)也是未來的主流方向，但是我們還有很多php的服務(wù)從codis改造到cluster后也出現(xiàn)了很多其他的一些問題：

1. 連接壓力會(huì)比較大主要是一些高頻的CLUSTER SLOTS請(qǐng)求導(dǎo)致clusterReplyMultiBulkSlots占用大量cpu資源整體性能消耗比較高。

2. java客戶端不統(tǒng)一對(duì)pipline支持有差異，同時(shí)也在Lettuce重連機(jī)制上多次采坑，云上ECS都是跨AZ的云上有時(shí)會(huì)遇到網(wǎng)絡(luò)抖動(dòng)情況，一但出現(xiàn)網(wǎng)絡(luò)問題Lettuce就會(huì)有問題詳見:https://www.debugger.wiki/article/html/1615624562913635 為此我們框架層對(duì)Lettuce重連機(jī)制做了改動(dòng)才最終解決這個(gè)問題。

3. cluster這種多節(jié)點(diǎn)的集群模式會(huì)多分配很多內(nèi)存資源跟服務(wù)器資源，同時(shí)我們經(jīng)過統(tǒng)計(jì)50%的實(shí)例使用率都低于1GB，集群內(nèi)存使用率非常低(我們最小規(guī)格為3M3S 3GB內(nèi)存資源)。再加上slave是有很大程度的資源浪費(fèi)的

總的來說在redis的基礎(chǔ)運(yùn)維上全面實(shí)現(xiàn)cluster化后我們當(dāng)前的方式是沒有太大問題的，但是在進(jìn)一步的深入治理上我們還是做的不夠的，因此我們也正在做我們的mesh化建設(shè)。

Redis ServiceMesh建設(shè)

所謂mesh化其實(shí)就是將proxy本地化內(nèi)置到客戶端服務(wù)器即sidecar模式。local proxy可以充分利用客戶端資源，縮短鏈路減少云上跨AZ帶來網(wǎng)絡(luò)上的不確定性，我們前面在codis上也出現(xiàn)過客戶端跨多AZ跟proyx間網(wǎng)絡(luò)問題導(dǎo)致部分client有影響。

服務(wù)&成本治理

a. 多語言統(tǒng)一訪問層：這里跟前面講的數(shù)據(jù)庫中間件性質(zhì)類似不做贅述

b. 多租戶：前面介紹過cluster模式下的天然資源浪費(fèi)，單純依靠運(yùn)維手段是難以很好的解決的，我們?yōu)榱私鉀Q這個(gè)問題我們引入了多租戶的概念，即一個(gè)cluster集群在proxy層進(jìn)加一個(gè)邏輯劃分既：namespace，同時(shí)基于user/pasword的認(rèn)證，用戶在讀取寫入時(shí)會(huì)給每一個(gè)key強(qiáng)制加上一個(gè)key前綴來避免key沖突:

但是這也還是有缺陷的，雖然集群內(nèi)部key是可以避免沖突的但是沒辦法做到資源的隔離，只是邏輯的隔離，我們將一些小容量的cluster集中遷移到統(tǒng)一的大集群中進(jìn)行租戶劃分，盡管無法做到資源隔離但是通過適度的資源冗余也能很好的避免性能問題，同時(shí)由于混部集中會(huì)有效減少資源浪費(fèi)，根據(jù)我們現(xiàn)有的數(shù)據(jù)測(cè)算可以節(jié)約40%~60的內(nèi)存成本，同時(shí)有效減少現(xiàn)有集群規(guī)模跟節(jié)點(diǎn)數(shù)量。

c. 在可觀測(cè)性上，通過proxy對(duì)key的旁路與分析可以實(shí)時(shí)感知到大key(雖然通過Agent可以每日分析但是這個(gè)實(shí)時(shí)性比較差會(huì)漏掉已過期的key)、熱key、及每個(gè)命令類型的rt分布情況。

d. 輔助治理：比如可以實(shí)時(shí)檢測(cè)到非法命令的使用及攔截、同時(shí)每個(gè)key都有特定的用戶標(biāo)簽遇到大key、熱key比較容易定位所屬研發(fā)

e. 研發(fā)友好：統(tǒng)一的pipline，通過proxy本地化熱key緩存等。

f. 副作用：key長度增加

Kafka平臺(tái)化建設(shè)

Kafka治理背景

1. 一種開源工具拼湊的管理系統(tǒng)

? 部署在各個(gè)IDC，管理分散，功能弱，不成體系

2. 管控能力弱，碎片化監(jiān)控

? 消費(fèi)延遲監(jiān)控不直觀，單純Offset Lag沒有意義

?  Broker監(jiān)控要額外部署相關(guān)Export及監(jiān)控報(bào)警系統(tǒng)

? Topic相互之間資源競爭，多次出現(xiàn)一些高流量的topic將整個(gè)系統(tǒng)資源打滿影響其他topic的正常使用。

3. 集群內(nèi)部對(duì)象狀態(tài)缺乏感知

? consumer/topic/partition等核心對(duì)象無收集統(tǒng)計(jì),無法主動(dòng)感知業(yè)務(wù)異常

? 核心對(duì)象缺乏基礎(chǔ)監(jiān)控?cái)?shù)據(jù)無法做沉淀分析，運(yùn)維靠人肉經(jīng)驗(yàn)指導(dǎo)

? 問題定位缺乏必要的數(shù)據(jù)支持，服務(wù)穩(wěn)定性完全依靠人工死磕

4. 平臺(tái)化建設(shè)缺乏有效參考

? 業(yè)內(nèi)開源系統(tǒng)稀少，沒有可以直接使用的

? 可觀測(cè)性不夠友好或者目前只對(duì)java會(huì)比較好

Kafka平臺(tái)

集群管理

此前我們都是在各個(gè)站點(diǎn)進(jìn)行分別部署對(duì)應(yīng)的開源管理系統(tǒng)，管理比較分散，現(xiàn)在得益于現(xiàn)有架構(gòu)的實(shí)現(xiàn)我們可以輕松實(shí)現(xiàn)一站式管控

Topic管理

除了對(duì)topic的常規(guī)操作封裝到平臺(tái)外，還通過對(duì)topic元數(shù)據(jù)信息落庫我們可以在全局的角度分析一些問題比如當(dāng)前那些topic是熱點(diǎn)topic，那些topic msg body比較大(可能需要DBA找下業(yè)務(wù)方確認(rèn)合理性，很多數(shù)據(jù)來源是canal->mysql->kafka研發(fā)為了簡單可能會(huì)將全字段寫入kafka)，那些topic體量比較大等等。

Topic詳細(xì)信息：

通過對(duì)每個(gè)topic的消息大小采樣，可以知道消息體大小分布情況及通過采樣消息分析消息體大小突變的原因，方便作出優(yōu)化處理。

Topic分區(qū)信息:

同時(shí)對(duì)topic的分區(qū)分布情況進(jìn)行展示(實(shí)現(xiàn)對(duì)kafka對(duì)象信息的完整覆蓋，完全實(shí)現(xiàn)了kafka-manager的全部功能，篇幅原因不做詳細(xì)介紹)

同時(shí)為了方便研發(fā)&DBA臨時(shí)查看消息的訴求也提供基礎(chǔ)的查詢能力。

Consumer管理

系統(tǒng)將topic跟consumer的關(guān)系進(jìn)行采集保留方便運(yùn)維需要。

Consumer Lag:

一般的kafka延遲通常以lags來衡量，但是lags最大的問題在于難以做時(shí)間維度的量化，以至于難以判斷延遲的真正程度，也不方便提供研發(fā)訂閱(研發(fā)需要知道自己消費(fèi)延遲情況但是lags對(duì)研發(fā)不夠直觀友好)，比如上圖lag=250k表達(dá)出來的意思就不如延遲時(shí)間=600s來的直觀，基于時(shí)間的延遲實(shí)現(xiàn)我們?cè)谔峁┭邪l(fā)做報(bào)警訂閱時(shí)就有了直觀的衡量標(biāo)準(zhǔn)。

但是受到kafka HW及consumer延遲commit的影響要獲取consumer的精確延遲時(shí)間是不可能的，以上圖為例這是典型的大數(shù)據(jù)消費(fèi)處理的特征：消費(fèi)一批數(shù)據(jù)后在做commit，這時(shí)我們觀察到他的延遲時(shí)間就跟commit時(shí)機(jī)有非常大關(guān)系，呈現(xiàn)出了周期性波動(dòng)，但是實(shí)際上延遲的真實(shí)時(shí)間是小于600s的，但是受到上述機(jī)制的影響我們沒有辦法做精確計(jì)算。

如上圖，我們可推測(cè)該consumer消費(fèi)時(shí)就是典型的生產(chǎn)業(yè)務(wù)消費(fèi)特征:逐條或者小批量消費(fèi)后立即commit。我們看到他的延遲就相對(duì)穩(wěn)定(生產(chǎn)與消費(fèi)比較穩(wěn)定無明顯的周期波動(dòng))波動(dòng)在正常范疇內(nèi)。

計(jì)算延遲時(shí)間思路:

1.基于msg body時(shí)間戳法:

delay~= (hw offset msg body).timestamp-(consumer offset msg body).timestamp

通過獲取兩個(gè)offset點(diǎn)位的消息體中的時(shí)間戳做減法的方式效率比較低理論上準(zhǔn)確度好一點(diǎn)。

2.max(分區(qū)延遲lags/平均分區(qū)生產(chǎn)速度)

非常高效但是準(zhǔn)確度稍差，目前主要采用這種方式。

說明：實(shí)際實(shí)現(xiàn)要稍微復(fù)雜一點(diǎn)點(diǎn)，兩種方案都會(huì)遇到很多細(xì)節(jié)要處理，篇幅原因不在細(xì)節(jié)上面面俱到，再次申明這是不精確的，只是相比lags要更加可度量，方便做報(bào)警配置及研發(fā)訂閱告警。

Broker管理

我們對(duì)broker做了zone分組方便實(shí)現(xiàn)后續(xù)的資源隔離。

元數(shù)據(jù)網(wǎng)關(guān)

目前研發(fā)消費(fèi)topic時(shí)只需要拿到topic所在集群地址即可消費(fèi)，這樣就給我們管理帶來一定問題同時(shí)也不夠安全。

前面提到，我們現(xiàn)在所有的資源交付都是通過資源id進(jìn)行交付的，研發(fā)也必須只能通過資源id才能訪問到Kafka，因此我們網(wǎng)關(guān)就基于這個(gè)點(diǎn)進(jìn)行建設(shè)：用戶的consumer必須在DBA交付的資源ID中建立topic跟consumer的綁定關(guān)系，用戶在拿資源id時(shí)需要對(duì)其指定的password/topic跟consumer進(jìn)行綁定關(guān)系驗(yàn)證(框架對(duì)kafka client做了封裝)否則就拿不到資源id，當(dāng)然這個(gè)實(shí)現(xiàn)肯定是不完美的，聰明的研發(fā)肯定能想到辦法繞過，比較理想的做法就是將綁定關(guān)系內(nèi)置到kafka server中，但是目前由于還沒有精力進(jìn)行這方面的投入。

多租戶隔離

我們目前kafka使用呈現(xiàn)出了兩極分化的趨勢(shì)，一個(gè)是超大規(guī)格的topic另外就是小規(guī)格topic，尤其在高峰期時(shí)網(wǎng)絡(luò)帶寬非常高單機(jī)網(wǎng)卡流量能打到7Gb+，這影響了其他小規(guī)格的topic業(yè)務(wù)正常使用，我們知道在云上cpu，網(wǎng)絡(luò)，存儲(chǔ)資源都是比較貴的，而kafka這種特性決定了我們可以選擇cpu規(guī)格規(guī)格略低一點(diǎn)，但是網(wǎng)絡(luò)、存儲(chǔ)要求比較高，不過遺憾的是云上cpu/網(wǎng)絡(luò)/存儲(chǔ)是存在比例關(guān)系的。有時(shí)為了獲取更大規(guī)格的網(wǎng)絡(luò)跟存儲(chǔ)資源需要購買規(guī)格更大的機(jī)器。這樣就造成了資源上的浪費(fèi)同時(shí)topic間也相互影響。

我們對(duì)集群的broker劃分成多個(gè)zone，每個(gè)zone里面一般由3~5個(gè)broker組成:

每個(gè)zone可以根據(jù)topic的場景或者業(yè)務(wù)場景或業(yè)務(wù)線來進(jìn)行分配，比如zone_1可以分配給風(fēng)控業(yè)務(wù)的大規(guī)模數(shù)據(jù)處理使用，zone_2則分配給一下小的業(yè)務(wù)場景混合使用，同時(shí)正對(duì)zone_1的業(yè)務(wù)場景我們分配給他高配的機(jī)器，zone_2我們分配給他低配置的機(jī)器，這樣一方面做到資源隔離另一方面做到資源的合理使用最大化發(fā)揮機(jī)器能力。這樣似乎還是有不完美比如：當(dāng)zone里面有topic規(guī)格發(fā)生變化需要升級(jí)配置或者降低配置的時(shí)候就會(huì)對(duì)現(xiàn)有zone的資源進(jìn)行調(diào)整。為此我們也是有解決方案：依靠監(jiān)控我們可以清楚的知道topic的及zone中broker的容量情況的，當(dāng)資源不足時(shí)我們可以加新的broker，或者將topic調(diào)度到其他zone中。

目前平臺(tái)基礎(chǔ)功能已基本覆蓋了開源的kafka-manager同時(shí)我們也對(duì)比較好的開源實(shí)現(xiàn)思路整合進(jìn)平臺(tái)，而且我們也做了很多的數(shù)據(jù)沉淀為我們更好的治理提供依據(jù)。

ES，RabbitMQ，Canal平臺(tái)建設(shè)背景

難以想象這些中間件的管理系統(tǒng)加起來有幾十個(gè)之多。難以忍受！！

ES，Canal，MQ其自身的可觀測(cè)不是特別的好。不過好在他們都再帶了自己的web-admin這就給實(shí)現(xiàn)集中式管理提供了可能，除了我們通過分析起web-admin api將其關(guān)鍵元數(shù)據(jù)緩存之外我們DMS平臺(tái)的諸多功能都是對(duì)現(xiàn)有web-admin的api的調(diào)用實(shí)現(xiàn)，一種非常取巧的實(shí)現(xiàn)方式。同時(shí)元數(shù)據(jù)的采集也對(duì)我們更好的維護(hù)治理這些基礎(chǔ)中間件提供更好的依據(jù)。

ES

對(duì)集群有了更多運(yùn)維屬性的標(biāo)簽便于維護(hù)

通過DMS對(duì)索引添加研發(fā)屬性描述，便于后續(xù)維護(hù)

資源申請(qǐng)與統(tǒng)一交付

索引輪轉(zhuǎn)統(tǒng)一管理，減輕研發(fā)心智

MQ

一個(gè)完整版的MQ-Admin，實(shí)現(xiàn)管理從分散到集中化的管理，操作便捷高效。

Canal

完整版本的CanlAdmin

流程化數(shù)據(jù)訂閱：Canal->Kafka->研發(fā)消費(fèi)，DBA高效交付，研發(fā)使用便捷。

關(guān)鍵監(jiān)控點(diǎn)采集可視化提供統(tǒng)一預(yù)警。

研發(fā)自助化平臺(tái)建設(shè)

服務(wù)一個(gè)幾千人的研發(fā)團(tuán)隊(duì)，如果依靠DBA人肉支持后果是難以想象的。DMS滿足了開發(fā)同學(xué)對(duì)研發(fā)過程中對(duì)DBA的訴求，所有的操作基本都可以通過平臺(tái)化手段進(jìn)行自助。DBA如何變被動(dòng)為主動(dòng)？平臺(tái)化就是關(guān)鍵手段。

研發(fā)想要的我們都提供，同時(shí)也主動(dòng)展示給研發(fā)一些開發(fā)過程中暴露出來的問題，方便研發(fā)改造。

包含mysql/redis/es/kafka的查詢等。

從運(yùn)維走向運(yùn)營

經(jīng)過一年的馬不停蹄，雖然數(shù)據(jù)庫類型很多但是我們還是基本上完成了每款數(shù)據(jù)庫及中間件的核心功能的建設(shè)工作，但是我們并沒有考慮跟進(jìn)一步走向所謂的智能化階段，應(yīng)該來說目前業(yè)內(nèi)呈現(xiàn)的智能化還是一個(gè)很虛的概念真正付出實(shí)踐的太少了，或者大多數(shù)都是基于規(guī)則引擎的更高程度的自動(dòng)化，對(duì)于一些體量不大公司基本上屬于KPI驅(qū)動(dòng)的產(chǎn)物。對(duì)于當(dāng)下貨拉拉我覺得比較務(wù)實(shí)的舉動(dòng)就是實(shí)現(xiàn)運(yùn)維的數(shù)字化運(yùn)營這是當(dāng)前正在做的方向，其實(shí)也比較簡單就是基于平臺(tái)的數(shù)據(jù)沉淀對(duì)核心指標(biāo)進(jìn)行展示體現(xiàn)出整體穩(wěn)定性治理的趨勢(shì)，云上資源利用率分布變化等等。

近一年治理成效

經(jīng)過一年的建設(shè)我們?cè)诜€(wěn)定性上有了長足的進(jìn)步，同時(shí)基于平臺(tái)化建立起標(biāo)準(zhǔn)化的運(yùn)維體系(我們一直說標(biāo)準(zhǔn)化與體系化，那么是什么標(biāo)準(zhǔn)化跟體系化？如何來踐行？我個(gè)人的理解就是通過編程的方式將我們的標(biāo)準(zhǔn)規(guī)范流程固化到系統(tǒng)里統(tǒng)一接收外界輸入或者對(duì)外界統(tǒng)一輸出)。

在這一年里我們以超越預(yù)期的速度進(jìn)行瘋狂輸出，也很慶幸結(jié)果也都超預(yù)期否則很難想象今天可以輕松服務(wù)與幾千人的研發(fā)團(tuán)隊(duì)！

我們?cè)谄脚_(tái)化沒有成型前是沒有數(shù)據(jù)支撐我們做成本的優(yōu)化的，有了數(shù)據(jù)的支持我們發(fā)現(xiàn)資源的浪費(fèi)其實(shí)還是很嚴(yán)重的，好在云上都具備規(guī)格彈性能力，經(jīng)過合理的縮容/資源合并/老舊業(yè)務(wù)下線改造等方式在成本上有著非常可觀的節(jié)約。

上述平臺(tái)建設(shè)與治理內(nèi)容我們用了一年的時(shí)間走完了3年的歷程，一方面有云的加持另一方面我們也多了大量的投入。平臺(tái)人員投入2.5人(我算半個(gè))今天也就3個(gè)平臺(tái)研發(fā)，從前端React到后端Python/go到框架到架構(gòu)設(shè)計(jì)幾乎是全棧DBA，很多數(shù)據(jù)庫選型我們都是第一次接觸但是絲毫不會(huì)阻礙進(jìn)度，比如Kafka從0認(rèn)知到完整的平臺(tái)化也不超過3個(gè)月，ES/MQ也幾乎是1~2個(gè)月就落地的。應(yīng)該說我們不再是單純DBA的定位，這種多元/綜合的能力建立是我對(duì)整個(gè)DBA團(tuán)隊(duì)后續(xù)的期望跟要求！

云時(shí)代下對(duì)DBA的思考

云極大的簡化傳統(tǒng)自建時(shí)代圍繞基礎(chǔ)設(shè)施穩(wěn)定性建設(shè)的復(fù)雜性，云已經(jīng)成為了一種新的基礎(chǔ)設(shè)施。

DBA職責(zé)轉(zhuǎn)變：

云上數(shù)據(jù)庫的可靠性穩(wěn)定性在云能力的加持下不再是核心工作，DBA將更加偏向業(yè)務(wù)比如性能優(yōu)化，成本優(yōu)化等等。

我們?cè)谧越〞r(shí)代也會(huì)考慮成本但是通常都非常難做到非常高的資源利用率，這里面有非常多的原因，近幾年也看到將db搬到k8s的做法其實(shí)本質(zhì)的就是想通過這樣的手段來達(dá)到類似云的能力，但是這個(gè)投入是非常大的甚至超過了收益，也伴隨很多的風(fēng)險(xiǎn)，非常不建議中小公司做這種嘗試，個(gè)人也非常不看好k8s里面跑db的做法(云原生才是未來)，千萬不要以為能將它跑起來就是能駕馭的了他。

能力模型改變：

圍繞自建打造的傳統(tǒng)能力將沒有生命力(還有比一個(gè)SDK來的更簡單高效的嗎)，DBA在自建時(shí)代的很多“黑科技”將逐步失去用武之地。過去DBA深入研究數(shù)據(jù)庫內(nèi)核比如對(duì)MySQL的各種原理機(jī)制理解的非常透徹，雖然這些也還是非常重要但是留給DBA的操作空間并不大，比如云上有規(guī)格跟參數(shù)模板嚴(yán)格的參數(shù)控制，基于開源理解的特性跟云上優(yōu)化或者改造后的并不完全一致，因此DBA深入理解云產(chǎn)品比深如理解數(shù)據(jù)庫本身可能更有幫助(不過遺憾的是目前云產(chǎn)品本身的幫助文檔還非常的不健全或者介紹的過于簡單了)

上云誤區(qū)：

云上DBA仍舊有用武之地，仍舊有很多有挑戰(zhàn)的事情要去解決。

轉(zhuǎn)型思考：

擁抱變化上云不可抵抗，不要把自己定位是一個(gè)DBA這太局限了(省略后續(xù)雞湯)。

實(shí)際使用云的過程中從各家云提供的SDK已經(jīng)高度模塊化了，稍微有點(diǎn)編程能力就可以將這些SDK組裝起來平湊成你要的樣子，很大程度上降低了開發(fā)的復(fù)雜性。

不知道我們是否思考過一個(gè)問題:為什么每家工作不管是DBA還是其他運(yùn)維部門都還在不遺余力的做平臺(tái)？這些平臺(tái)其實(shí)功能都是同質(zhì)化的，或者說高度的重復(fù)性建設(shè)，雖然呈現(xiàn)形態(tài)不一樣但是內(nèi)部的機(jī)制幾乎都一樣。我覺得未來這種局面會(huì)隨著云上對(duì)運(yùn)維標(biāo)準(zhǔn)的定義跟建立而發(fā)生很大改變，或許以后我們不用在建立平臺(tái)直接使用云平臺(tái)，或者采購三方開發(fā)者提供的標(biāo)準(zhǔn)化解決方案。

云正在重新塑造整個(gè)IT行業(yè)，作為從業(yè)者積極調(diào)整改變很重要，如果打不過他們就加入他們(云廠商)。

生成海報(bào)

免責(zé)聲明：本網(wǎng)站內(nèi)容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準(zhǔn)確性及可靠性，但不保證有關(guān)資料的準(zhǔn)確性及可靠性，讀者在使用前請(qǐng)進(jìn)一步核實(shí)，并對(duì)任何自主決定的行為負(fù)責(zé)。本網(wǎng)站對(duì)有關(guān)資料所引致的錯(cuò)誤、不確或遺漏，概不負(fù)任何法律責(zé)任。任何單位或個(gè)人認(rèn)為本網(wǎng)站中的網(wǎng)頁或鏈接內(nèi)容可能涉嫌侵犯其知識(shí)產(chǎn)權(quán)或存在不實(shí)內(nèi)容時(shí)，應(yīng)及時(shí)向本網(wǎng)站提出書面權(quán)利通知或不實(shí)情況說明，并提供身份證明、權(quán)屬證明及詳細(xì)侵權(quán)或不實(shí)情況證明。本網(wǎng)站在收到上述法律文件后，將會(huì)依法盡快聯(lián)系相關(guān)文章源頭核實(shí)，溝通刪除相關(guān)內(nèi)容或斷開相關(guān)鏈接。