全面總結！阿里巴巴資料庫運維演進之路

一直以來想寫一篇關於阿里巴巴資料庫運維相關的文章，囿於業務及個人惰性一直沒有開始，正好11月份CNUTCon全球運維大會上我有一個主題講資料庫運維相關的話題，借這個機會理一下阿里巴巴資料庫運維發展歷程以及對未來的一些看法，與諸位一起討論。

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

關於阿里的資料庫，大家可能已經聽說過很多，阿里巴巴資料庫技術的發展與整個集團的技術發展類似，從商業到開源再到自主研發。早在09年以前，阿里巴巴資料庫DBA團隊已經在業界非常知名，擁有多名Oracle ACE / ACE Director，外加自發的與業界的交流、分享以及著作，構建了非常強的影響力，很多人因此吸引而加入。這是一段榮耀時光，當時很多知名人物現在有的在創業、有的仍在集團不同的領域奮鬥，江湖中仍然可以搜尋到他們的傳說。

後來就是轟轟烈烈的去IOE運動了，剛入職時經常在內部BBS上看到各種成功去除Oracle的帖子，基本套路就是DBA和業務開發一起配合，透過各種指令碼把資料遷移到MySQL上。在這個過程中，遇到過很多問題，也在積極尋求各種新的技術，比如為了突破磁碟效能問題，在當時主流的還是機械硬碟的時候，使用了Fusion-IO等，也在MySQL核心上開始各種改進，形成了AliSQL。2010年的時候還成立了OceanBase團隊，當時集團去O已經基本接近尾聲，後來OceanBase轉戰螞蟻以及雲的快速發展，遂形成了今天大集團範圍內，集團、螞蟻、雲三支資料庫力量。三支資料庫力量有各自的品牌，集團是X-DB，螞蟻是OceanBase，雲則是PolarDB。

關於去IOE、各自資料庫核心技術、支撐的業務這些方面，講的很多，大家可以搜到各自技術相關的文章，但很少有人講過這背後有一個什麼樣的平臺來支援這些業務變化以及技術迭代。過去的5年裡，我和我的團隊一直在做資料庫運維或者是服務方面的事情。很難，我相信各位如果有做過這方面經驗會感同身受。一方面，這是運維類或服務類系統的“原罪”，這類系統形成初期，它只是一個工具或一個平臺，使命是支撐好業務，自己並不實際產生價值。所有的技術要在這裡落地，等落完地好像和你又沒什麼關係，價值感比較弱。今天K8S等系統的出現說明這個也可以做得很好，但相對來說這是一個更難做好的領域。另一方面，業務的複雜性、技術棧的多樣性以及所依賴的元件決定了這個系統在實現層面很難，你需要把各個元件一層一層的串聯起來。從業務訪問到資料庫核心再到底層的網路、儲存、OS、硬體等，任何一個層面出了問題都會集中反應到你的系統中，實現人員面臨著從上到下各個層面問題的理解、異常的處理，對團隊及個人能力要求極高。一個很具體的例子，我們的運維繫統涉及了前端、大資料處理、演算法、資料庫、底層軟硬體等各個技術領域。在最初期團隊不可能有各個領域的專家，需要每個同學瞭解並解決不同的領域的問題。

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

阿里巴巴資料庫運維發展的歷程，主要有這幾個階段。09年以前，以商業資料庫為主，去IOE也才開始。之前沒有整體運維規劃、運維平臺。使用了各類指令碼、工具。

在09年以後，由於規模迅速膨脹，這個時候自然產生了一些工具團隊，把各類指令碼拼在一起，弄個介面，形成了最初的產品。

接著，隨著複雜度進一步增加，以及雲端計算的推動。交付方面有了更高的要求，形成了服務化，比如DBaaS等。

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

總體來講，有兩次比較大的革新。

第一次是從產品化到服務化。最初，我們的產品形成非常簡單。沒有什麼平臺，沒有什麼系統，大家一邊幹活一邊沉澱一些指令碼，到處分發。隨著規模的增長，原來的那套指令碼需要管理起來了，我相信很多團隊最開始都會設立一個工具組，專門來幹這個事情。這就會演變成一個團隊做工具，另一個團隊來使用，慢慢的兩者之間的GAP就出現了。工具團隊有工具團隊的KPI，業務團隊有業務團隊的KPI，分歧會逐漸增大。

另外一個問題則是大家都在攢工具，攢平臺。結果這些平臺之間是相互不能通訊的。比如一個應用開發，需要資料庫、搜尋、分散式儲存等各個系統，開發人員需要去逐個申請，效率不高。

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

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

對SLA或者服務質量的追求是沒有止境的。現在很火的Cloud Native、Serverless本質上都是對更高服務質量的一種追求。要提升服務水平，關鍵點有兩個，一是規模，規模大了才能做更多事情，比如混合部署、智慧排程、機器學習，都要求一定的規模和大量的資料。這也符合當前提供基礎服務的雲端計算趨於集中的趨勢。規模也是問題的根源，管理一千個例項和十萬個例項所需的技術完全不一樣，所以另一個關鍵點是技術水平，有了規模還必須有相應的技術，比如容器化、機器學習、儲存計算分離、RDMA網路等技術的提升。

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

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

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

總結來看，我們的業務場景大致有以下幾個特點。

1. 業務多樣性。作為資料庫中臺，資料庫團隊要支撐集團所有業務。包括核心電商、線下新零售場景以及各個獨立子公司。各種場景對資料庫的要求也不一樣，比如線上場景就要求高併發低延時，故障快速恢復。線下場景則要求絕對可用，而且接入及使用資料庫的方式都不受控制。而新加入阿里體系的收購公司，有原來的運維體系，要求他們做改變也不太現實。總之需求的多樣性對資料庫的要求非常高。

2. 基礎設施多樣化，資料中心分佈在全球，有的用公有云、有的有自建機房，有的用物理機，有的用Docker、用彈性計算等，整個集團就是一個超級大的混合雲。

3. 雙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的初衷，先把各種採集到的資料匯聚統一、預處理再加上領域知識和演算法，打通從使用者到DB，從DB到底層硬體這兩個鏈路。在雙11的時候也能實時的診斷訪問鏈路。當然這裡待挖掘的還非常多，現在我們可以說只應用了非常小的一部份。

最後，我把之前講的這些都融進了一個產品HDM，全稱是混合雲資料庫管理平臺。Gartner有一份報告指出，到2020年的時候，有85％的企業會使用混合雲的架構。這和我們的判斷是一致的，之前提到過，阿里巴巴集團就是一個超大的混合雲，所以我們推出了HDM，幫助企業把混合雲資料庫架構打通。主要提供三大功能，一是統一管理，不管是雲上的還是雲下還是其他雲的資料庫，都可以進行統一管理與診斷。二是彈性擴充套件，一鍵把資料庫上雲也不再是夢想。在資料庫層消除本地IDC和雲的區別。

在提出HDM後一段時間裡，我一度認為這基本上就是資料庫服務的未來了。但這些年，不管是資料庫領域，還是運維領域，都在飛速的向前發展，我們似乎又到了一個技術集中爆發的點。一方面是新的軟硬體技術，比如容器、高速網路，機器學習，另外一個是雲端計算的發展，都在不斷的推動我們向前，提供更好的交付及服務。

在資料庫領域，有自治資料庫、智慧資料庫，在運維領域，有AIOPS等等。這對資料庫運維來說到底意味著什麼，我們結合過去和現在的情況，提出了自治資料庫平臺。這個定義是很多人一起討論了很久才定出來的。首先是平臺的能力和目標，我們希望能做到自動駕駛，簡單的說就是不需要人的參與。要做到這個，就要具備自感知、自決策、自恢復、自最佳化四大能力。其次是平臺能為資料庫賦能，今天的現狀是我們用了很多種資料庫，不能對每個資料庫有很高的要求才能自治，我們可以進行能力分級。

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

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

有了這些技術，還需要革新我們的思路，就像今天的電動汽車或自動駕駛，由傳統廠商來製造，都顯得差強人意，這一方面是思維定勢，另一方面則是有它的歷史包袱。我們需要破除這些，比如我們之前的資料、運維、資源都是分割開來的，所謂自動處理都是先接收一個報警，然後根據報警的內容做自動化，這明顯沒辦法形成一個統一的整體。今天我們需要先去構建整個骨架，然後讓資料、演算法去豐富、去潤滑整個系統。

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

最後，重要的一點是要持續提升原有的基礎能力，不是說我們今天智慧化、自治化就是資料和演算法，其他基礎能力同等重要，比如OPS，我們提出了一個ad-hoc執行：假如決策模組作出了一個決策是全網記憶體水位高於95％的資料庫例項做一個action，你要能夠很快執行下去。

我們目前正在向這個方向前進，預計很快我們就會對一部份資料庫例項實施自治，歡迎有興趣的同學加入一起建設，共同迎接自治時代的到來。