作者簡介：

蔡鵬

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

內(nèi)容摘要：

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

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

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

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

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

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

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

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

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

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

痛點&訴求

1.穩(wěn)定性

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

2.研發(fā)效率

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

3.成本

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

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

治理基本思路

1.做減法

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

2.定義規(guī)范

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

3.建能力

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

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

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

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

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

平臺整體架構(gòu)

1.技術(shù)棧

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

2.功能層面

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

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

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

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

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

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

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

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

平臺組件集：

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

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

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

添加一個任務(wù)：

注冊一個腳本:

任務(wù)管理：

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

MySQL平臺化建設(shè)

監(jiān)控報警

健康大盤:

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

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

報警：

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

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

運維管理

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

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

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

應(yīng)急/自愈

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

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

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

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

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

DB上云與自建的差別

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

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

MySQL中間件建設(shè)

自建中間件其實是有很多考量因素主要集中在這3點:

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

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

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

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

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

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

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

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

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

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

自愈系統(tǒng)：

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

SQLReview

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

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

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

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

gh-ost建設(shè)

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

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

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

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

Flashback(DML回滾)

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

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

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

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

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

Redis平臺化建設(shè)

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

監(jiān)控大盤

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

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

實例替換

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

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

擴(kuò)縮容

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

全量Key分析

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

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

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

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

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

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

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

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

Redis ServiceMesh建設(shè)

所謂mesh化其實就是將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模式下的天然資源浪費，單純依靠運維手段是難以很好的解決的，我們?yōu)榱私鉀Q這個問題我們引入了多租戶的概念，即一個cluster集群在proxy層進(jìn)加一個邏輯劃分既：namespace，同時基于user/pasword的認(rèn)證，用戶在讀取寫入時會給每一個key強(qiáng)制加上一個key前綴來避免key沖突:

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

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

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

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

f. 副作用：key長度增加

Kafka平臺化建設(shè)

Kafka治理背景

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

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

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

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

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

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

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

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

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

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

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

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

? 可觀測性不夠友好或者目前只對java會比較好

Kafka平臺

集群管理

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

Topic管理

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

Topic詳細(xì)信息：

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

Topic分區(qū)信息:

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

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

Consumer管理

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

Consumer Lag:

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

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

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

計算延遲時間思路:

1.基于msg body時間戳法:

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

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

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

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

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

Broker管理

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

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

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

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

多租戶隔離

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

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

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

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

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

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

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

ES

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

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

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

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

MQ

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

Canal

完整版本的CanlAdmin

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

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

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

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

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

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

從運維走向運營

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

近一年治理成效

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

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

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

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

云時代下對DBA的思考

云極大的簡化傳統(tǒng)自建時代圍繞基礎(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)化等等。

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

能力模型改變：

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

上云誤區(qū)：

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

轉(zhuǎn)型思考：

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

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

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

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

生成海報

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