與「十「俱進 阿里數據庫運維10年演進之路

導語
阿里巴巴集團擁有超大的數據庫實例規模，在快速發展的過程當中咱們在運維管理方面也在不斷的面臨變化，從物理器到容器、從獨佔到混布、從本地盤到存儲計算分離、從集團內到大促雲資源，從開源的MySQL到自研分佈式數據庫，運維管控進行了自我革新與進化。

做者——譚宇（花名：茂七），阿里巴巴高級技術專家。2009年加入阿里，對分佈式系統和數據庫領域有很大的興趣。目前負責阿里巴巴集團數據庫中臺建設，支撐了集團數據庫在容器化、存儲計算分離、在離線混部、大規模遷移建站以及智能運維等技術探索與落地。

本文梳理了阿里巴巴數據庫運維發展歷程以及對將來數據庫自治時代的見解，期待與諸位一塊兒討論。

正文
我在阿里快十年了，前五年作一些分佈式系統開發相關的工做，參與的系統包括TFS/Tair/OceanBase，後五年聚焦在數據庫運維平臺及服務的建設，從搭建數據庫集羣、數據採集等底層運維到外部客戶服務、POC支持等都有所經歷，好的想法從來稀少，外加我的天資愚鈍，不敢說有什麼首創的想法，都是實踐過程當中的一些感悟，且與你們分享，也是對過去一段時間的總結。

關於阿里的數據庫，你們可能已經據說過不少，阿里巴巴數據庫技術的發展與整個集團的技術發展相似，從商業到開源再到自主研發。早在09年之前，阿里巴巴數據庫或DBA團隊已經在業界很是知名，擁有多名Oracle ACE / ACE Director，外加自發性的與業界的交流、分享以及著做，構建了很是強的影響力，不少人所以吸引而加入，這是一段榮耀時光，當時不少知名人物如今有的在創業、有的仍在集團不一樣的領域奮鬥，江湖中仍然能夠搜索到他們的傳說。

後來就是轟轟烈烈的去IOE運動了，剛入職時常常在內部BBS上看到各類成功去除Oracle的帖子，基本套路就是DBA和業務開發一塊兒配合，經過各類腳本把數據遷移到MySQL上。在這個過程當中，遇到過不少問題，也在積極尋求各類新的技術，好比爲了突破磁盤性能問題，在當時主流的仍是機械硬盤的時候，使用了Fusion-IO等，也在MySQL內核上開始各類改進，造成了AliSQL。

關於去IOE、各自數據庫內核技術、支撐的業務這些方面，講的不少，你們能夠搜到各自技術相關的文章，但不多有人講過這背後有一個什麼樣的平臺來支持這些業務變化以及技術迭代。過去的5年裏，我和個人團隊一直在作數據庫運維或者是服務方面的事情，很難，我相信各位若是有作過這方面經驗會感同身受。

一方面，這是運維類或服務類系統的「原罪」，這類系統造成初期，它只是一個工具或一個平臺，使命是支撐好業務，本身並不實際產生價值。全部的技術要在這裏落地，等落完地好像和你又沒什麼關係，價值感比較弱。今天K8S等系統的出現說明這個也能夠作得很好，但相對來講這是一個更難作好的領域。

另外一方面，業務的複雜性、技術棧的多樣性以及所依賴的組件決定了這個系統在實現層面很難，你須要把各個組件一層一層的串聯起來。從業務訪問到數據庫內核再到底層的網絡、存儲、OS、硬件等，任何一個層面出了問題都會集中反應到你的系統中，實現人員面臨着從上到下各個層面問題的理解、異常的處理，對團隊及我的能力要求極高。

一個很具體的例子，咱們的運維繫統涉及了前端、大數據處理、算法、數據庫、底層軟硬件等各個技術領域。在最初期團隊不可能有各個領域的專家，須要每一個同窗瞭解並解決不一樣的領域的問題。

我想就這些方面，系統性地跟你們介紹一下咱們所作的一些工做。主要包括三個方面：第一，咱們整個系統的發展歷程，所謂從歷史看將來，不知道過去，沒法推斷出將來咱們的樣子。第二，現階段的技術和產品，好比咱們如何支撐咱們現有的工做，雙11大促等。第三，從過去和如今出發，咱們將來一段時間要到達的樣子。

1. 從歷史看將來

阿里巴巴數據庫運維發展的歷程，主要有這幾個階段。09年之前，以商業數據庫爲主，去IOE也纔開始。以前沒有總體運維規劃、運維平臺。使用了各種腳本、工具。

在09年之後，因爲規模迅速膨脹，這個時候天然產生了一些工具團隊，把各種腳本拼在一塊兒，弄個界面，造成了最初的產品。

接着，隨着複雜度進一步增長，以及雲計算的推進。交付方面有了更高的要求，造成了服務化，好比DBaaS等。

近年來，隨着大數據、機器學習等技術的發展，AIOPS催生智能化。在智能化的基礎之上，對各種服務平臺的服務質量的進一步要求，也就是自治。

整體來說，有兩次比較大的革新。

第一次是從產品化到服務化。最初，咱們的產品造成很是簡單。沒有什麼平臺，沒有什麼系統，你們一邊幹活一邊沉澱一些腳本，處處分發。隨着規模的增加，原來的那套腳本須要管理起來了，我相信不少團隊最開始都會設立一個工具組，專門來幹這個事情。這就會演變成一個團隊作工具，另外一個團隊來使用，慢慢的二者之間的GAP就出現了。工具團隊有工具團隊的KPI，業務團隊有業務團隊的KPI，分歧會逐漸增大。

另一個問題則是你們都在攢工具，攢平臺。結果這些平臺之間是相互不能通訊的。好比一個應用開發，須要數據庫、搜索、分佈式存儲等各個系統，開發人員須要去逐個申請，效率不高。

服務化的變革就是在這種狀況下發生的。咱們不提供工具、平臺，而提供服務。這些服務之間相互打通，而且咱們對提供的服務有相關SLA保證。此次革新能夠說是雲計算的基礎，雲計算的本質是IT資源交付技術的進步，這是雲計算帶給咱們的最大價值。

第二次革新是自治，咱們目前正處於此次革新中。

對SLA或者服務質量的追求是沒有止境的。如今很火的Cloud Native、Serverless本質上都是對更高服務質量的一種追求。要提高服務水平，關鍵點有兩個，一是規模，規模大了才能作更多事情，好比混合部署、智能調度、機器學習，都要求必定的規模和大量的數據。這也符合當前提供基礎服務的雲計算趨於集中的趨勢。

規模也是問題的根源，管理一千個實例和十萬個實例所需的技術徹底不同，因此另外一個關鍵點是技術水平，有了規模還必須有相應的技術，好比容器化、機器學習、存儲計算分離、RDMA網絡等技術的提高。

1. 理想照進現實

固然技術的積累是一個長期的過程，積累到必定程度就會引發質變。咱們這些年在系統建設、技術積累方面所作了許多工做。先來看一組數據，這是剛剛過去的雙十一數據庫相關的一些狀況。

你們可能看過一些數據，好比成交額，交易峯值。對於背後的數據庫而言，每秒有超過5000萬次的訪問。特別是在高峯期，讀寫比是和平時不同的。一般通常系統讀寫比大約是9：1或者7：1。但在雙11高峯時，數據庫的讀寫比多是2：1。在寫入比例極高的狀況下，要求數據庫不能出現任何抖動或者延遲，咱們對任何一種新技術的引入都很是嚴格。

另外，阿里巴巴大促場景很是複雜，包括線上線下以及海內外多種場景。基礎設施分佈在全球多地，數十個機房同時支撐，系統複雜性很是高。

總結來看，咱們的業務場景大體有如下幾個特色：

業務多樣性。做爲數據庫中臺，數據庫團隊要支撐集團全部業務。包括核心電商、線下新零售場景以及各個獨立子公司。各類場景對數據庫的要求也不同，好比線上場景就要求高併發低延時，故障快速恢復。線下場景則要求絕對可用，並且接入及使用數據庫的方式都不受控制。而新加入阿里體系的收購公司，有原來的運維體系，要求他們作改變也不太現實。總之需求的多樣性對數據庫的要求很是高。
基礎設施多樣化，數據中心分佈在全球，有的用公有云、有的有自建機房，有的用物理機，有的用Docker、用彈性計算等，整個集團就是一個超級大的混合雲。
雙11超級大熱點，除了成本和性能方面，雙11在彈性方面有很高的要求。咱們也不可能爲雙11買這麼多機器，那太浪費了。早期，會在不一樣的業務線之間進行拆借，好比借雲的機器或者借離線的機器，大促後歸還，全靠人肉搬機器。整個大促週期很是長，人力成本和機器成本都很高。

針對以上狀況，咱們造成了以下架構。主要思路是向下層屏蔽差別，向上層提供多樣化服務能力，中間圍繞着彈性、穩定性、智能化進行建設。

早期的運維繫統由於各類緣由，沒有設計好的架構致使難以擴展，最後愈來愈臃腫，推翻重構的事情並很多見。現今，咱們設計了服務化的運維繫統總體架構：

一來能夠清晰地理順系統各個模塊之間的交互方式並標準化，完全解決原來工具時代遺留下來的各自爲政，各個功能散落在不一樣地方的問題，整個系統的發展再也不揹負歷史包袱；
二來能夠解決技術棧太多的問題，從前端到底層採集、算法分析，咱們不可能統一成一個框架、一種語言。讓這些模塊能互不影響、互相交互，是整個系統能作強的基礎；
三來能夠將整個系統的數據集中起來，爲後續智能化所須要的統一數據、統一算法提供基本要素；四來能夠向外提供統一形式、功能多樣化的服務。要想作好作強一個服務類的系統，服務化是第一步。
在底層，咱們作了統一的資源調度層，用來屏蔽底層計算、存儲、網絡資源的差別，向上交付標準的容器。

中間是數據庫層。由於業務的多樣性，數據庫類型多種多樣，運行在不一樣的環境，咱們經過統一的命令通道和採集通道的抽象來屏蔽這些差別。

再往上是傳統的數據庫運維層，包括常見的數據庫的生命週期管理，咱們稱之爲Lego，但願OPS這樣的基礎功能能像樂高同樣百變組合，迅速搭建咱們想要的功能。還包括數據採集、處理存儲的模塊Kepler，咱們但願把全部的運行數據實時採集到，而後經過大數據處理、機器學習等手段發掘出深層價值，採集的數據包括OS、網絡、存儲，數據庫的SQL流水、性能指標等等，整個處理的數據量很是大，而且全部指標都要求是秒級的。每秒都要處理超過100G的原始報文。

再往上是智能決策層，這一層完成自動修復與優化的工做，好比預期內的故障，異常處理。也經過採集到的數據，作一些分析和決策。

咱們把整個系統的功能以服務的形式提供出來，你們能夠在這個基礎之上定製想要的功能。過去幾年，咱們在架構實現方面一直堅持「一個平臺、一套架構，集團孵化、雲上輸出」的策略，集團內部數據庫管控平臺提供服務，全部模塊在一套架構下實現，產品在集團檢驗後開始在雲上輸出。不一樣的時期有不一樣的堅持，在智能化時代，咱們對這個架構及策略也有所調整，這個在後面會說起。

解決架構問題後，咱們過去兩年主要圍繞幾個能力進行建設，一是容器化與存儲計算分離，二是快速彈性與混部的能力，三是規模化交付與智能運維，這幾項工做都是今天可以發展成爲集團數據庫中臺以及支撐雙十一的關鍵能力。

第一，容器化是技術的量變到質變，容器並無不少開創性的技術，各類技術合在一塊兒開闢了新的思路。因此在把數據庫放到容器裏首先要突破咱們的運維思路，堅決能夠把數據庫放到容器裏的這個想法。固然這個過程當中也遇到過穩定性和性能問題，好比網絡在使用bridge模式的時候，會有些CPU的增長。

最終在網絡團隊不斷優化後，基本能夠作到與物理機持平。容器化一方面解決了不少環境問題，另外一方面也爲數據庫的調度提供了可能，咱們從16年開始作數據庫容器化，到今年，絕大部份的數據庫都跑在了容器裏。

第二，存儲計算分離。其實數據庫最開始就是存儲計算分離架構的。在互聯網時代，這個架構在最初遇到了瓶頸，由於互聯網時代的容量擴張很是快。而後出現了分佈式系統，把計算搬到數據所在的地方。可是隨着技術的發展，特別是雲的交付方式，存儲計算分離的交付則更爲便捷。交付多少計算能力，交付多少存儲，一目瞭然。

另外，存儲和計算的發展也不太均衡，好比雙11的時候，我要求的是計算能力，其實存儲並無增長多少。因此隨着技術的發展，咱們這一圈基本上又轉了回來。固然存儲計算分離要不要上，咱們也是通過了很長時間的討論，今天來看，上存儲計算分離這個決定是對的。在這個過程當中也遇到不少問題，主要是延遲的問題，畢竟通過一層網絡，IO時間是有增長的。

咱們最開始上了左邊這個架構，將遠程存儲掛載到本地，這個延遲要較本地盤大不少，核心業務難以接受，在這個基礎之上，咱們大規模引入RDMA網絡，經過DBFS　bypass掉kernel，延時基本能和本地盤至關，因此今年全部的核心業務就跑在了這個架構上。

有了容器化和存儲計算分離的基礎，就能夠比較好的解決彈性問題了。以前咱們的彈性主要靠搬數據加搬機器，如今數據能夠不用搬了。咱們大促所用的機器主要來自兩個地方，一個是離線資源，另一個是雲資源，咱們用完以後雲能夠繼續對外售賣。

你們知道，雙11的高峯期主要在零點時段。因此咱們在高峯期來的時候彈性擴容，高峯期結束當即縮容，還機器給別人用。咱們結合集團的調度，作了一套混部調度系統，能夠作到數據庫快上快下，今年咱們的核心集羣10分鐘就能夠完成彈性擴縮，而咱們最終的目標是在1分鐘內完成。

第三，交付和診斷。咱們說雲計算是IT資源交付能力的進步。咱們基本完成了向用戶交付數據庫資源，開發人員能夠經過系統自助完成數據庫資源的申請與使用。若是隻是把交付理解爲用戶自助獲取數據庫資源的話，咱們已經完成得很好了。

但集團有更嚴苛和複雜的交付任務。好比下面兩個例子：大促時須要在上十萬個數據庫實例裏擴容數千甚至上萬個實例，大促完成後還須要縮容回來。每一年有固定的或臨時的建站、遷站等操做，例現在年的一路向北和上海、張北屢次建站，可能會涉及到數萬數據庫實例及數十PB數據，這些都很是考驗咱們交付的能力。

以前的常規作法是讓人來評估，肯定好操做的數據庫範圍，算好須要多少機器資源，如何擺放等，再經過咱們提供的遷移操做來完成。人須要來控制其中的每個步驟，這是一個至關繁瑣的工做。每一年都要作那麼幾回，在咱們今天要求快上快下的時候就顯得特別力不從心。

因此咱們提出軟件定義部署的概念，相似常說的編排。主要作兩個事情，一是把咱們的這些操做都精肯定義和記載下來，線上的運行環境也能用代碼精肯定義出來。二是把中間的騰挪步驟交給系統，人只須要描述最終的狀態，在咱們預測準確到必定程度後，這個最終描述狀態也能夠由系統來完成，真正的完成大促自動化交付。

能夠看到，咱們的鏈路其實很長，中間的各個組件出了問題診斷是一件很難的事情。Gartner有一個名詞叫AIOPS，相信你們都據說過，其實Gartner提出AIOPS很早，最開始指的是基於算法的OPS，隨着AI技術的發展呢，他順勢把這個詞的寫法給改了，但本質上沒有變，仍然是依託大數據、算法來改變OPS。

應該說這也是個樸素的概念，咱們在差很少時刻也提出了這個想法，最開始叫作數據驅動，後來更名爲運行數據與數據運營，也是經過各類算法，好比基線、異常檢測、關聯分析、趨勢預測等等來自動決策或輔助咱們決策。

這即是CloudDBA的初衷，先把各類採集到的數據匯聚統1、預處理再加上領域知識和算法，打通從用戶到DB，從DB到底層硬件這兩個鏈路。在雙11的時候也能實時的診斷訪問鏈路。固然這裏待挖掘的還很是多，如今咱們能夠說只應用了很是小的一部份。

最後，我把以前講的這些都融進了一個產品HDM，全稱是混合雲數據庫管理平臺。Gartner有一份報告指出，到2020年的時候，有85％的企業會使用混合雲的架構。這和咱們的判斷是一致的。以前提到過，阿里巴巴集團就是一個超大的混合雲，因此咱們推出了HDM，幫助企業把混合雲數據庫架構打通。

HDM主要提供兩大功能，一是統一管理，無論是雲上的仍是雲下仍是其餘雲的數據庫，均可以進行統一管理與診斷。二是彈性擴展，一鍵把數據庫上雲也再也不是夢想。在數據庫層消除本地IDC和雲的區別。

在提出HDM後一段時間裏，我一度認爲這基本上就是數據庫服務的將來了。但這些年，無論是數據庫領域，仍是運維領域，都在飛速的向前發展，咱們彷佛又到了一個技術集中爆發的時間點。一方面是新的軟硬件技術，好比容器、高速網絡，機器學習，另一個是雲計算的發展，都在不斷的推進咱們向前，提供更好的交付及服務。

1. 通往智能之路:自治數據庫平臺

在數據庫領域，有自治數據庫、智能數據庫，在運維領域，有AIOPS等等。這對數據庫運維來講到底意味着什麼，咱們結合過去和如今的狀況，提出了自治數據庫平臺。這個定義是不少人一塊兒討論了好久才定出來的。

首先是平臺的能力和目標，咱們但願能作到自動駕駛，簡單的說就是不須要人的參與。要作到這個，就要具有自感知、自決策、自恢復、自優化四大能力。其次是平臺能爲數據庫賦能，今天的現狀是咱們用了不少種數據庫，不能對每一個數據庫有很高的要求才能自治，咱們能夠進行能力分級。

咱們也有很是明確的業務目標，這是阿里數據庫事業部掌門人公開的目標：在2020財年結束的時候，阿里集團85％的數據庫實例要能作到自動駕駛。我爲此定了兩個評估指標，一是沒有人接收這些數據庫的報警，另外一個是穩定性要達到99.995%。

目標有了，具體怎麼實現？首先，自治是一個技術的量變到質變的過程。在過去的一段時間裏，咱們應用了大量的新技術，包括存儲計算分離，大數據處理與機器學習等等，掌握好這些技術是自治的基礎。

有了這些技術，還須要革新咱們的思路，就像今天的電動汽車或自動駕駛，由傳統廠商來製造，都顯得差強人意，這一方面是思惟定勢，另外一方面則是有它的歷史包袱。

咱們須要破除這些，好比咱們以前的數據、運維、資源都是分割開來的，所謂自動處理都是先接收一個報警，而後根據報警的內容作自動化，這明顯沒辦法造成一個統一的總體。今天咱們須要先去構建整個骨架，而後讓數據、算法去豐富、去潤滑整個系統。

另外還須要專業知識。數據庫是高度專業的系統，以前可能由DBA、內核開發人員去調校，靠數據，靠試錯，靠經驗。這些知識如何精確化、數字化下來，讓系統也具有這些能力，是咱們要去努力的事情。

最後，重要的一點是要持續提高原有的基礎能力，不是說咱們今天智能化、自治化就是數據和算法，其餘基礎能力同等重要，好比OPS，咱們提出了一個ad-hoc執行：假如決策模塊做出了一個決策是全網內存水位高於95％的數據庫實例作一個action，你要可以很快執行下去。

咱們目前正在向這個方向前進，預計很快咱們就會對一部份數據庫實例實施自治，歡迎有興趣的同窗加入一塊兒建設，共同迎接自治時代的到來。