餓了麼資料庫發展中的解決方案
餓了麼經過了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元件的設計研發再到成熟執行所花費的成本非常高，投入的資源、人員以及驗證週期花費都非常高；整體來看目前運轉效率和利用率並不是非常高，在業務的高峰時資源需要加入進去，但是在業務低谷時卻退不下來，所以就使得業務低峰時利用率非常低，並且伸縮性也非常差。此外，新技術的迭代非常快，而餓了麼並不具備技術的規模效應，一些技術問題可能代價過高自身難以解決。餓了麼目前期望是資源隨時要隨時有，可以彈性伸縮，有足夠豐富的生態來支援，維護簡單並且使用的產品有相應的規模效應，經過了大規模的驗證。
餓了麼如今已經成為了阿里雲的重度使用者，首先目前我們的開發測試環境完全基於阿里雲，因為需求提出很快，但是生命週期很短。其次由於餓了麼的業務特點就是中午和晚上是兩個訂單的尖峰，所以資源在高峰時需求比較大，但是高峰過了之後就相對平緩，因此餓了麼希望通過雲的能力實現彈性擴縮容，提高資源利用率。再次我們目前的多活架構實現很大部分也是在阿里雲的機房中的，使用阿里雲機房的好處就是能逐步地調整在阿里雲上的流量，而不用一開始就投入大量的資源，穩定後就可以逐步讓雲承載主要的流量，最終成為主力節點。最後雖然餓了麼做了很多的元件和產品，但是對於阿里雲的產品而言其實只是一個子集而已，整套的解決方案在阿里雲上都能找到。對於高速發展的行業而言，大多數公司技術還是為業務服務的，不能夠讓技術成為限制業務發展的阻礙，而應該讓技術快速滿足業務發展需求，促進業務更快發展，所以雲的成熟方案應該是價效比很高的選擇。