餓了麼資料庫發展中的解決方案

餓了麼經過了10年的發展，日訂單量從幾十萬到了千萬，資料增長如此之快，資料庫管理人員如何保障業務快速發展，實作高可用以及資料安全并且提高運維效率呢？本文中餓了麼資料技術部負責人虢國飛就為大家揭曉答案。

餓了麼的資料庫需求背景

對于創業公司或者高速發展的行業而言，通路量或者資料量都是呈指數級别地上升的，餓了麼也是其中的一個案例。那麼在業務資料增長如此之快的情況下，如何保證資料庫的容量、高可用、資料安全以及運維的效率呢？

這次分享主要談以下幾點：首先需要有好的資料架構，這樣能夠保證容量的充足；其次需要提高資料庫的可用性，以及對于資料流的控制和對于資料安全的保證，再有就是如何高效地完成大規模的資料運維，最後一點就是應該如何充分借助阿裡雲的力量。

可能大家對于餓了麼的了解也是在最近三四年的時間，但是餓了麼已經創辦10年了。在2015年的時候，餓了麼每天也就隻有幾十萬個訂單，而到了2016年因為出現O2O熱點，訂單規模就到了每天百萬級，到2016年底，每日訂單量就到了8、9百萬，并且有了上百萬的商戶。2017年到現在，無論是訂單還是運單都是每天千萬級别的規模，還有幾百萬商戶加上百萬騎手。整個鍊路還是比較深的，我們稱之為“CBD”，所謂“C”就是使用者，“B”就是商戶，“D”就是物流。整個的鍊條非常長，每個環節都是千萬級的規模，是以沉澱的資料也是非常大的。

餓了麼資料庫架構演進之路

那麼餓了麼資料庫架構是如何演進的呢？首先在2015年~2016年，訂單從幾十萬到了幾百萬，餓了麼就做了資料庫垂直拆分的方案。對于核心系統，預估它有多少QPS和TPS，原有的資料庫架構無法支撐這樣量級，就需要對于業務中相對獨立的子產品進行拆分，這樣就可以用多套環境來支援通路壓力，在這個結構下就支撐了兩三百萬單的規模。但是到了2016年，從業務預估的趨勢來看，這套架構系統将會很快再次面臨這樣的瓶頸。為了解決容量的問題需要過渡到下一個階段，就是把資料庫的核心表進行水準的切分。因為垂直拆分是無法突破核心系統的瓶頸的，為了支撐上面的容量，那麼就必須對核心的表進行拆解分壓。一張邏輯表可能拆分成數千張小表，這樣就能夠保證核心系統的壓力能夠合理地分散到多張表不同叢集中去，為業務的發展提供了比較好的底層技術擴容支援。

但是這樣就足夠了嗎？在2017年的時候，餓了麼資料庫架構底層也面臨新的問題，雖然能夠在技術層面支撐技術擴容，但是機房的容量卻是有限的，能放入的機器數量是有限的，此時瓶頸就又出現了。是以，在2017年餓了麼做了“多活”的架構，可以用多個機房來支援業務發展。

在這個過程中，有兩個與資料庫緊密相關的元件。一個是自研的DB Proxy層面的DAL元件，它主要完成了分表和分庫的功能，通過這個元件就實作了底層資料的切片擴容以及讀寫分離功能，在它上面還實作了連接配接池和連接配接隔離，還可以對資料層做更多的保護，比如銷峰、限流以及黑白名單等機制。另外業務上可能有多元度分表需求，比如對于餓了麼訂單而言，有商戶次元，也有使用者次元，當下單的時候他們都是高頻操作，此時就需要實作多元的切片，既滿足使用者也滿足商戶。當然，DAL元件對于業務也有一定的侵入性，會要求限制某些SQL的操作。

第二個重要的元件就是在做多活的時候有一個跨機房的資料同步的DRC元件，其主要實作的功能就是監控機房的資料變更，也就是BinLog的變化，再将這些變化Push到對端的機房中去，這樣就能完成跨機房的資料同步，還可以做資料壓縮、回放、幂等的處理以及過濾傳輸的工作，相對于MySQL原生的資料同步而言會有很大的優勢。

當解決了容量的瓶頸之後，對于網站或者資料庫而言，還需要提升整體的可用性。這裡可以從幾個大層面來講，首先任何的機器和裝置都可能出問題，好的HA方案是必備的，餓了麼使用開源的MHA，但是也做了相應的封裝和改造，保證當主庫挂掉的時候能夠快速切換和批量管理，也能夠完成各個元件之間消息的通訊（改造後我們叫EMHA），這樣就解決了單台機器出現問題時造成的可用性問題。第二種提升可用性的方式就是将核心業務分為多片，當單片資料出問題，對于業務的影響就是1/N，是以也提升了整體可用性。此外，通過異地多活帶來了機房級别或者地域級别的可用性，同時也給大型的維護操作提供了Online的支援。

下面看下資料流，首先需要對它足夠可控，流入的資料需要確定是沒有風險的，對于資料流異常過大的時候能對底層環境進行相應的保護。在DAL元件中就可做這樣的工作，包括有風險的SQL語句就需要被拒絕掉。當資料進入之後，在落地的時候需要有一些規則和規範，這樣就能保證資料的高效性。還有資源需要進行相應的隔離，不能因為因為某一業務的問題導緻其他業務出現問題。再有在資料處理完成之後，需要将資料及時推送給其他的消費方進行消費，比較典型的就是搜尋和大資料。比方對于大資料而言，之前抽取資料做報表的時效性非常低，而通過DRC元件的消息訂閱能夠做到分鐘甚至秒級别的延遲，及時地看到業務資料變化。最後一點就是落地的資料在很多時候需要與其他環境互通，如經常需要從開發向測試導入資料，此時需要給出一些資料導出規範，對于一些敏感内容需要進行脫敏和過濾。

解決完容量、可用性以及資料流的問題，可以看到有很多元件出現。在大規模資料的情況下，如果沒有相應的流程規範支援以及運維效率工具，是很再通過人力進行資料庫維護的。這裡我抽取了一些在做資料庫運維時可能會頻繁遇到的關鍵點。比如SQL治理，前期SQL在建表以及編寫的過程中需要有一個自動稽核機制，保證符合規則以及設計高效率原則。另外，上到生産環境的SQL就必須要有對應的SQL跟蹤監控機制，能夠及時發現有問題的SQL。此外，對于資料庫變更和釋出而言，餓了麼多的時候每天可能有幾百個DDL表的變更，前期DBA壓力比較大，後面我們實作了研發自助釋出的平台，DBA就不需要參與釋出的過程了，但是需要保證平台的穩定和釋出風險可控。還有冷熱資料的分離，在生産環境中存放資料的硬體成本都是很高的，是以需要進行資料的冷熱分離，将使用者經常通路的資料留在生産環境中，而将不經常通路的資料轉移到比較便宜的存儲上面去，實作資料歸檔，保證生産的高效和成本降低，目前這一塊我們平台也讓研發能夠自助了。為了保證資料安全，餓了麼實作了資料備份救援的系統，包含自動備份、閃回和備份自動驗證等功能。此外，還有需求就是經常需要做資料遷移，是以我們研發了D-Bus工具，DBA隻需要配置好規則，系統就能自動進行資料搬遷了。

資料庫架構演進之後仍然存在的問題

以上就是餓了麼在處理資料這部分所做的一些關鍵點。其實，以上對于問題的解決目前來看仍然是存在很多問題的。首先，投入非常大，無論是DAL還是DRC元件的設計研發再到成熟運作所花費的成本非常高，投入的資源、人員以及驗證周期花費都非常高；整體來看目前運轉效率和使用率并不是非常高，在業務的高峰時資源需要加入進去，但是在業務低谷時卻退不下來，是以就使得業務低峰時使用率非常低，并且伸縮性也非常差。此外，新技術的疊代非常快，而餓了麼并不具備技術的規模效應，一些技術問題可能代價過高自身難以解決。餓了麼目前期望是資源随時要随時有，可以彈性伸縮，有足夠豐富的生态來支援，維護簡單并且使用的産品有相應的規模效應，經過了大規模的驗證。

餓了麼如今已經成為了阿裡雲的重度使用者，首先目前我們的開發測試環境完全基于阿裡雲，因為需求提出很快，但是生命周期很短。其次由于餓了麼的業務特點就是中午和晚上是兩個訂單的尖峰，是以資源在高峰時需求比較大，但是高峰過了之後就相對平緩，是以餓了麼希望通過雲的能力實作彈性擴縮容，提高資源使用率。再次我們目前的多活架構實作很大部分也是在阿裡雲的機房中的，使用阿裡雲機房的好處就是能逐漸地調整在阿裡雲上的流量，而不用一開始就投入大量的資源，穩定後就可以逐漸讓雲承載主要的流量，最終成為主力節點。最後雖然餓了麼做了很多的元件和産品，但是對于阿裡雲的産品而言其實隻是一個子集而已，整套的解決方案在阿裡雲上都能找到。對于高速發展的行業而言，大多數公司技術還是為業務服務的，不能夠讓技術成為限制業務發展的阻礙，而應該讓技術快速滿足業務發展需求，促進業務更快發展，是以雲的成熟方案應該是成本效益很高的選擇。