一文講透貨拉拉混合云數據庫體系化建設

作者簡介：

蔡鵬

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

內容摘要：

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

混合云數據庫治理背景介紹

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

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

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

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

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

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

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

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

痛點&訴求

1.穩(wěn)定性

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

2.研發(fā)效率

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

3.成本

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

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

治理基本思路

1.做減法

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

2.定義規(guī)范

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

3.建能力

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

4.70分標準

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

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

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

平臺整體架構

1.技術棧

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

2.功能層面

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

3.統(tǒng)一網關

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

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

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

數據總線：

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

為了減少過多的Kafka部署增加運維的復雜性我們其他站點的監(jiān)控數據統(tǒng)一上報到一個網絡距離上處在相對中間的kafka集群，然后在通過mirror的方式將監(jiān)控數據同步到管控節(jié)點進行集中的消費處理，整體看監(jiān)控數據從最遠端的站點傳回到集中管控節(jié)點通常控制在1s內整體可以接受，其實最主要的是監(jiān)控數據寫到Kafka避免監(jiān)控數據因為網絡原因導致丟失。

平臺組件集：

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

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

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

添加一個任務：

注冊一個腳本:

任務管理：

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

MySQL平臺化建設

監(jiān)控報警

健康大盤:

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

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

報警：

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

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

運維管理

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

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

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

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

應急/自愈

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

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

數據統(tǒng)計分析

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

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

DB上云與自建的差別

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

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

MySQL中間件建設

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

1.統(tǒng)一數據庫保護層

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

2.數據庫可擴展問題

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

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

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

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

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

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

MySQL基礎工具建設

自愈系統(tǒng)：

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

SQLReview

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

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

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

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

gh-ost建設

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

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

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

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

Flashback(DML回滾)

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

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

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

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

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

Redis平臺化建設

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

監(jiān)控大盤

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

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

實例替換

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

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

擴縮容

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

全量Key分析

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

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

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

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

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

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

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

總的來說在redis的基礎運維上全面實現cluster化后我們當前的方式是沒有太大問題的，但是在進一步的深入治理上我們還是做的不夠的，因此我們也正在做我們的mesh化建設。

Redis ServiceMesh建設

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

服務&成本治理

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

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

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

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

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

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

f. 副作用：key長度增加

Kafka平臺化建設

Kafka治理背景

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

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

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

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

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

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

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

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

? 核心對象缺乏基礎監(jiān)控數據無法做沉淀分析，運維靠人肉經驗指導

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

4. 平臺化建設缺乏有效參考

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

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

Kafka平臺

集群管理

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

Topic管理

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

Topic詳細信息：

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

Topic分區(qū)信息:

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

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

Consumer管理

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

Consumer Lag:

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

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

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

計算延遲時間思路:

1.基于msg body時間戳法:

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

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

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

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

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

Broker管理

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

元數據網關

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

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

多租戶隔離

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

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

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

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

ES，RabbitMQ，Canal平臺建設背景

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

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

ES

對集群有了更多運維屬性的標簽便于維護

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

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

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

MQ

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

Canal

完整版本的CanlAdmin

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

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

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

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

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

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

從運維走向運營

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

近一年治理成效

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

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

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

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

云時代下對DBA的思考

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

DBA職責轉變：

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

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

能力模型改變：

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

上云誤區(qū)：

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

轉型思考：

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

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

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

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

生成海報

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