導語

阿里巴巴集團擁有超大的數(shù)據(jù)庫實例規(guī)模，在快速發(fā)展的過程中我們在運維管理方面也在不斷的面臨變化，從物理器到容器、從獨占到混布、從本地盤到存儲計算分離、從集團內(nèi)到大促云資源，從開源的MySQL到自研分布式數(shù)據(jù)庫，運維管控進行了自我革新與進化。

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

本文梳理了阿里巴巴數(shù)據(jù)庫運維發(fā)展歷程以及對未來數(shù)據(jù)庫自治時代的看法，期待與諸位一起討論。

正文

我在阿里快十年了，前五年做一些分布式系統(tǒng)開發(fā)相關的工作，參與的系統(tǒng)包括TFS/Tair/OceanBase，后五年聚焦在數(shù)據(jù)庫運維平臺及服務的建設，從搭建數(shù)據(jù)庫集群、數(shù)據(jù)采集等底層運維到外部客戶服務、POC支持等都有所經(jīng)歷，好的想法歷來***，外加個人天資愚鈍，不敢說有什么***的想法，都是實踐過程中的一些感悟，且與大家分享，也是對過去一段時間的總結(jié)。

關于阿里的數(shù)據(jù)庫，大家可能已經(jīng)聽說過很多，阿里巴巴數(shù)據(jù)庫技術的發(fā)展與整個集團的技術發(fā)展類似，從商業(yè)到開源再到自主研發(fā)。早在09年以前，阿里巴巴數(shù)據(jù)庫或DBA團隊已經(jīng)在業(yè)界非常知名，擁有多名Oracle ACE / ACE Director，外加自發(fā)性的與業(yè)界的交流、分享以及著作，構(gòu)建了非常強的影響力，很多人因此吸引而加入，這是一段榮耀時光，當時很多知名人物現(xiàn)在有的在創(chuàng)業(yè)、有的仍在集團不同的領域奮斗，江湖中仍然可以搜索到他們的傳說。

后來就是轟轟烈烈的去IOE運動了，剛?cè)肼殨r經(jīng)常在內(nèi)部BBS上看到各種成功去除Oracle的帖子，基本套路就是DBA和業(yè)務開發(fā)一起配合，通過各種腳本把數(shù)據(jù)遷移到MySQL上。在這個過程中，遇到過很多問題，也在積極尋求各種新的技術，比如為了突破磁盤性能問題，在當時主流的還是機械硬盤的時候，使用了Fusion-IO等，也在MySQL內(nèi)核上開始各種改進，形成了AliSQL。

關于去IOE、各自數(shù)據(jù)庫內(nèi)核技術、支撐的業(yè)務這些方面，講的很多，大家可以搜到各自技術相關的文章，但很少有人講過這背后有一個什么樣的平臺來支持這些業(yè)務變化以及技術迭代。過去的5年里，我和我的團隊一直在做數(shù)據(jù)庫運維或者是服務方面的事情，很難，我相信各位如果有做過這方面經(jīng)驗會感同身受。

一方面，這是運維類或服務類系統(tǒng)的“原罪”，這類系統(tǒng)形成初期，它只是一個工具或一個平臺，使命是支撐好業(yè)務，自己并不實際產(chǎn)生價值。所有的技術要在這里落地，等落完地好像和你又沒什么關系，價值感比較弱。今天K8S等系統(tǒng)的出現(xiàn)說明這個也可以做得很好，但相對來說這是一個更難做好的領域。

另一方面，業(yè)務的復雜性、技術棧的多樣性以及所依賴的組件決定了這個系統(tǒng)在實現(xiàn)層面很難，你需要把各個組件一層一層的串聯(lián)起來。從業(yè)務訪問到數(shù)據(jù)庫內(nèi)核再到底層的網(wǎng)絡、存儲、OS、硬件等，任何一個層面出了問題都會集中反應到你的系統(tǒng)中，實現(xiàn)人員面臨著從上到下各個層面問題的理解、異常的處理，對團隊及個人能力要求極高。

一個很具體的例子，我們的運維系統(tǒng)涉及了前端、大數(shù)據(jù)處理、算法、數(shù)據(jù)庫、底層軟硬件等各個技術領域。在最初期團隊不可能有各個領域的專家，需要每個同學了解并解決不同的領域的問題。

我想就這些方面，系統(tǒng)性地跟大家介紹一下我們所做的一些工作。主要包括三個方面：***，我們整個系統(tǒng)的發(fā)展歷程，所謂從歷史看未來，不知道過去，無法推斷出未來我們的樣子。第二，現(xiàn)階段的技術和產(chǎn)品，比如我們?nèi)绾沃挝覀儸F(xiàn)有的工作，雙11大促等。第三，從過去和現(xiàn)在出發(fā)，我們未來一段時間要到達的樣子。

1. 從歷史看未來

阿里巴巴數(shù)據(jù)庫運維發(fā)展的歷程，主要有這幾個階段。09年以前，以商業(yè)數(shù)據(jù)庫為主，去IOE也才開始。之前沒有整體運維規(guī)劃、運維平臺。使用了各類腳本、工具。

在09年以后，由于規(guī)模迅速膨脹，這個時候自然產(chǎn)生了一些工具團隊，把各類腳本拼在一起，弄個界面，形成了最初的產(chǎn)品。

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

近年來，隨著大數(shù)據(jù)、機器學習等技術的發(fā)展，AIOPS催生智能化。在智能化的基礎之上，對各類服務平臺的服務質(zhì)量的進一步要求，也就是自治。

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

***次是從產(chǎn)品化到服務化。最初，我們的產(chǎn)品形成非常簡單。沒有什么平臺，沒有什么系統(tǒng)，大家一邊干活一邊沉淀一些腳本，到處分發(fā)。隨著規(guī)模的增長，原來的那套腳本需要管理起來了，我相信很多團隊最開始都會設立一個工具組，專門來干這個事情。這就會演變成一個團隊做工具，另一個團隊來使用，慢慢的兩者之間的GAP就出現(xiàn)了。工具團隊有工具團隊的KPI，業(yè)務團隊有業(yè)務團隊的KPI，分歧會逐漸增大。

另外一個問題則是大家都在攢工具，攢平臺。結(jié)果這些平臺之間是相互不能通信的。比如一個應用開發(fā)，需要數(shù)據(jù)庫、搜索、分布式存儲等各個系統(tǒng)，開發(fā)人員需要去逐個申請，效率不高。

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

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

對SLA或者服務質(zhì)量的追求是沒有止境的?，F(xiàn)在很火的Cloud Native、Serverless本質(zhì)上都是對更高服務質(zhì)量的一種追求。要提升服務水平，關鍵點有兩個，一是規(guī)模，規(guī)模大了才能做更多事情，比如混合部署、智能調(diào)度、機器學習，都要求一定的規(guī)模和大量的數(shù)據(jù)。這也符合當前提供基礎服務的云計算趨于集中的趨勢。

規(guī)模也是問題的根源，管理一千個實例和十萬個實例所需的技術完全不一樣，所以另一個關鍵點是技術水平，有了規(guī)模還必須有相應的技術，比如容器化、機器學習、存儲計算分離、RDMA網(wǎng)絡等技術的提升。

2. 理想照進現(xiàn)實

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

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

另外，阿里巴巴大促場景非常復雜，包括線上線下以及海內(nèi)外多種場景。基礎設施分布在全球多地，數(shù)十個機房同時支撐，系統(tǒng)復雜性非常高。

總結(jié)來看，我們的業(yè)務場景大致有以下幾個特點：

1. 業(yè)務多樣性。作為數(shù)據(jù)庫中臺，數(shù)據(jù)庫團隊要支撐集團所有業(yè)務。包括核心電商、線下新零售場景以及各個獨立子公司。各種場景對數(shù)據(jù)庫的要求也不一樣，比如線上場景就要求高并發(fā)低延時，故障快速恢復。線下場景則要求絕對可用，而且接入及使用數(shù)據(jù)庫的方式都不受控制。而新加入阿里體系的收購公司，有原來的運維體系，要求他們做改變也不太現(xiàn)實?？傊枨蟮亩鄻有詫?shù)據(jù)庫的要求非常高。
2. 基礎設施多樣化，數(shù)據(jù)中心分布在全球，有的用公有云、有的有自建機房，有的用物理機，有的用Docker、用彈性計算等，整個集團就是一個超級大的混合云。
3. 雙11超級大熱點，除了成本和性能方面，雙11在彈性方面有很高的要求。我們也不可能為雙11買這么多機器，那太浪費了。早期，會在不同的業(yè)務線之間進行拆借，比如借云的機器或者借離線的機器，大促后歸還，全靠人肉搬機器。整個大促周期非常長，人力成本和機器成本都很高。

針對以上情況，我們形成了如下架構(gòu)。主要思路是向下層屏蔽差異，向上層提供多樣化服務能力，中間圍繞著彈性、穩(wěn)定性、智能化進行建設。

早期的運維系統(tǒng)因為各種原因，沒有設計好的架構(gòu)導致難以擴展，***越來越臃腫，推翻重構(gòu)的事情并不少見?，F(xiàn)今，我們設計了服務化的運維系統(tǒng)整體架構(gòu)：

1. 一來可以清晰地理順系統(tǒng)各個模塊之間的交互方式并標準化，徹底解決原來工具時代遺留下來的各自為政，各個功能散落在不同地方的問題，整個系統(tǒng)的發(fā)展不再背負歷史包袱；
2. 二來可以解決技術棧太多的問題，從前端到底層采集、算法分析，我們不可能統(tǒng)一成一個框架、一種語言。讓這些模塊能互不影響、互相交互，是整個系統(tǒng)能做強的基礎；
3. 三來可以將整個系統(tǒng)的數(shù)據(jù)集中起來，為后續(xù)智能化所需要的統(tǒng)一數(shù)據(jù)、統(tǒng)一算法提供基本要素；四來可以向外提供統(tǒng)一形式、功能多樣化的服務。要想做好做強一個服務類的系統(tǒng)，服務化是***步。

在底層，我們做了統(tǒng)一的資源調(diào)度層，用來屏蔽底層計算、存儲、網(wǎng)絡資源的差異，向上交付標準的容器。

中間是數(shù)據(jù)庫層。因為業(yè)務的多樣性，數(shù)據(jù)庫類型多種多樣，運行在不同的環(huán)境，我們通過統(tǒng)一的命令通道和采集通道的抽象來屏蔽這些差異。

再往上是傳統(tǒng)的數(shù)據(jù)庫運維層，包括常見的數(shù)據(jù)庫的生命周期管理，我們稱之為Lego，希望OPS這樣的基礎功能能像樂高一樣百變組合，迅速搭建我們想要的功能。還包括數(shù)據(jù)采集、處理存儲的模塊Kepler，我們希望把所有的運行數(shù)據(jù)實時采集到，然后通過大數(shù)據(jù)處理、機器學習等手段發(fā)掘出深層價值，采集的數(shù)據(jù)包括OS、網(wǎng)絡、存儲，數(shù)據(jù)庫的SQL流水、性能指標等等，整個處理的數(shù)據(jù)量非常大，并且所有指標都要求是秒級的。每秒都要處理超過100G的原始報文。

再往上是智能決策層，這一層完成自動修復與優(yōu)化的工作，比如預期內(nèi)的故障，異常處理。也通過采集到的數(shù)據(jù)，做一些分析和決策。

我們把整個系統(tǒng)的功能以服務的形式提供出來，大家可以在這個基礎之上定制想要的功能。過去幾年，我們在架構(gòu)實現(xiàn)方面一直堅持“一個平臺、一套架構(gòu)，集團孵化、云上輸出”的策略，集團內(nèi)部數(shù)據(jù)庫管控平臺提供服務，所有模塊在一套架構(gòu)下實現(xiàn)，產(chǎn)品在集團檢驗后開始在云上輸出。不同的時期有不同的堅持，在智能化時代，我們對這個架構(gòu)及策略也有所調(diào)整，這個在后面會提及。

解決架構(gòu)問題后，我們過去兩年主要圍繞幾個能力進行建設，一是容器化與存儲計算分離，二是快速彈性與混部的能力，三是規(guī)模化交付與智能運維，這幾項工作都是今天能夠發(fā)展成為集團數(shù)據(jù)庫中臺以及支撐雙十一的關鍵能力。

***，容器化是技術的量變到質(zhì)變，容器并沒有很多開創(chuàng)性的技術，各種技術合在一起開辟了新的思路。所以在把數(shù)據(jù)庫放到容器里首先要突破我們的運維思路，堅定可以把數(shù)據(jù)庫放到容器里的這個想法。當然這個過程中也遇到過穩(wěn)定性和性能問題，比如網(wǎng)絡在使用bridge模式的時候，會有些CPU的增加。

最終在網(wǎng)絡團隊不斷優(yōu)化后，基本可以做到與物理機持平。容器化一方面解決了很多環(huán)境問題，另一方面也為數(shù)據(jù)庫的調(diào)度提供了可能，我們從16年開始做數(shù)據(jù)庫容器化，到今年，絕大部份的數(shù)據(jù)庫都跑在了容器里。

第二，存儲計算分離。其實數(shù)據(jù)庫最開始就是存儲計算分離架構(gòu)的。在互聯(lián)網(wǎng)時代，這個架構(gòu)在最初遇到了瓶頸，因為互聯(lián)網(wǎng)時代的容量擴張非常快。然后出現(xiàn)了分布式系統(tǒng)，把計算搬到數(shù)據(jù)所在的地方。但是隨著技術的發(fā)展，特別是云的交付方式，存儲計算分離的交付則更為便捷。交付多少計算能力，交付多少存儲，一目了然。

另外，存儲和計算的發(fā)展也不太均衡，比如雙11的時候，我要求的是計算能力，其實存儲并沒有增加多少。所以隨著技術的發(fā)展，我們這一圈基本上又轉(zhuǎn)了回來。當然存儲計算分離要不要上，我們也是經(jīng)過了很長時間的討論，今天來看，上存儲計算分離這個決定是對的。在這個過程中也遇到很多問題，主要是延遲的問題，畢竟經(jīng)過一層網(wǎng)絡，IO時間是有增加的。

我們最開始上了左邊這個架構(gòu)，將遠程存儲掛載到本地，這個延遲要較本地盤大很多，核心業(yè)務難以接受，在這個基礎之上，我們大規(guī)模引入RDMA網(wǎng)絡，通過DBFS　bypass掉kernel，延時基本能和本地盤相當，所以今年所有的核心業(yè)務就跑在了這個架構(gòu)上。

有了容器化和存儲計算分離的基礎，就可以比較好的解決彈性問題了。之前我們的彈性主要靠搬數(shù)據(jù)加搬機器，現(xiàn)在數(shù)據(jù)可以不用搬了。我們大促所用的機器主要來自兩個地方，一個是離線資源，另外一個是云資源，我們用完之后云可以繼續(xù)對外售賣。

大家知道，雙11的高峰期主要在零點時段。所以我們在高峰期來的時候彈性擴容，高峰期結(jié)束立即縮容，還機器給別人用。我們結(jié)合集團的調(diào)度，做了一套混部調(diào)度系統(tǒng)，可以做到數(shù)據(jù)庫快上快下，今年我們的核心集群10分鐘就可以完成彈性擴縮，而我們最終的目標是在1分鐘內(nèi)完成。

第三，交付和診斷。我們說云計算是IT資源交付能力的進步。我們基本完成了向用戶交付數(shù)據(jù)庫資源，開發(fā)人員可以通過系統(tǒng)自助完成數(shù)據(jù)庫資源的申請與使用。如果只是把交付理解為用戶自助獲取數(shù)據(jù)庫資源的話，我們已經(jīng)完成得很好了。

但集團有更嚴苛和復雜的交付任務。比如下面兩個例子：大促時需要在上十萬個數(shù)據(jù)庫實例里擴容數(shù)千甚至上萬個實例，大促完成后還需要縮容回來。每年有固定的或臨時的建站、遷站等操作，例如今年的一路向北和上海、張北多次建站，可能會涉及到數(shù)萬數(shù)據(jù)庫實例及數(shù)十PB數(shù)據(jù)，這些都非?？简炍覀兘桓兜哪芰Α?/p>

之前的常規(guī)做法是讓人來評估，確定好操作的數(shù)據(jù)庫范圍，算好需要多少機器資源，如何擺放等，再通過我們提供的遷移操作來完成。人需要來控制其中的每一個步驟，這是一個相當繁瑣的工作。每年都要做那么幾次，在我們今天要求快上快下的時候就顯得特別力不從心。

所以我們提出軟件定義部署的概念，類似常說的編排。主要做兩個事情，一是把我們的這些操作都精確定義和記載下來，線上的運行環(huán)境也能用代碼精確定義出來。二是把中間的騰挪步驟交給系統(tǒng)，人只需要描述最終的狀態(tài)，在我們預測準確到一定程度后，這個最終描述狀態(tài)也可以由系統(tǒng)來完成，真正的完成大促自動化交付。

可以看到，我們的鏈路其實很長，中間的各個組件出了問題診斷是一件很難的事情。Gartner有一個名詞叫AIOPS，相信大家都聽說過，其實Gartner提出AIOPS很早，最開始指的是基于算法的OPS，隨著AI技術的發(fā)展呢，他順勢把這個詞的寫法給改了，但本質(zhì)上沒有變，仍然是依托大數(shù)據(jù)、算法來改變OPS。

應該說這也是個樸素的概念，我們在差不多時刻也提出了這個想法，最開始叫做數(shù)據(jù)驅(qū)動，后來改名為運行數(shù)據(jù)與數(shù)據(jù)運營，也是通過各種算法，比如基線、異常檢測、關聯(lián)分析、趨勢預測等等來自動決策或輔助我們決策。

這便是CloudDBA的初衷，先把各種采集到的數(shù)據(jù)匯聚統(tǒng)一、預處理再加上領域知識和算法，打通從用戶到DB，從DB到底層硬件這兩個鏈路。在雙11的時候也能實時的診斷訪問鏈路。當然這里待挖掘的還非常多，現(xiàn)在我們可以說只應用了非常小的一部份。

***，我把之前講的這些都融進了一個產(chǎn)品HDM，全稱是混合云數(shù)據(jù)庫管理平臺。Gartner有一份報告指出，到2020年的時候，有85％的企業(yè)會使用混合云的架構(gòu)。這和我們的判斷是一致的。之前提到過，阿里巴巴集團就是一個超大的混合云，所以我們推出了HDM，幫助企業(yè)把混合云數(shù)據(jù)庫架構(gòu)打通。

HDM主要提供兩大功能，一是統(tǒng)一管理，不管是云上的還是云下還是其他云的數(shù)據(jù)庫，都可以進行統(tǒng)一管理與診斷。二是彈性擴展，一鍵把數(shù)據(jù)庫上云也不再是夢想。在數(shù)據(jù)庫層消除本地IDC和云的區(qū)別。

在提出HDM后一段時間里，我一度認為這基本上就是數(shù)據(jù)庫服務的未來了。但這些年，不管是數(shù)據(jù)庫領域，還是運維領域，都在飛速的向前發(fā)展，我們似乎又到了一個技術集中爆發(fā)的時間點。一方面是新的軟硬件技術，比如容器、高速網(wǎng)絡，機器學習，另外一個是云計算的發(fā)展，都在不斷的推動我們向前，提供更好的交付及服務。

3. 通往智能之路:自治數(shù)據(jù)庫平臺

在數(shù)據(jù)庫領域，有自治數(shù)據(jù)庫、智能數(shù)據(jù)庫，在運維領域，有AIOPS等等。這對數(shù)據(jù)庫運維來說到底意味著什么，我們結(jié)合過去和現(xiàn)在的情況，提出了自治數(shù)據(jù)庫平臺。這個定義是很多人一起討論了很久才定出來的。

首先是平臺的能力和目標，我們希望能做到自動駕駛，簡單的說就是不需要人的參與。要做到這個，就要具備自感知、自決策、自恢復、自優(yōu)化四大能力。其次是平臺能為數(shù)據(jù)庫賦能，今天的現(xiàn)狀是我們用了很多種數(shù)據(jù)庫，不能對每個數(shù)據(jù)庫有很高的要求才能自治，我們可以進行能力分級。

我們也有非常明確的業(yè)務目標，這是阿里數(shù)據(jù)庫事業(yè)部掌門人公開的目標：在2020財年結(jié)束的時候，阿里集團85％的數(shù)據(jù)庫實例要能做到自動駕駛。我為此定了兩個評估指標，一是沒有人接收這些數(shù)據(jù)庫的報警，另一個是穩(wěn)定性要達到99.995%。

目標有了，具體怎么實現(xiàn)？首先，自治是一個技術的量變到質(zhì)變的過程。在過去的一段時間里，我們應用了大量的新技術，包括存儲計算分離，大數(shù)據(jù)處理與機器學習等等，掌握好這些技術是自治的基礎。

有了這些技術，還需要革新我們的思路，就像今天的電動汽車或自動駕駛，由傳統(tǒng)廠商來制造，都顯得差強人意，這一方面是思維定勢，另一方面則是有它的歷史包袱。

我們需要破除這些，比如我們之前的數(shù)據(jù)、運維、資源都是分割開來的，所謂自動處理都是先接收一個報警，然后根據(jù)報警的內(nèi)容做自動化，這明顯沒辦法形成一個統(tǒng)一的整體。今天我們需要先去構(gòu)建整個骨架，然后讓數(shù)據(jù)、算法去豐富、去潤滑整個系統(tǒng)。

另外還需要專業(yè)知識。數(shù)據(jù)庫是高度專業(yè)的系統(tǒng)，之前可能由DBA、內(nèi)核開發(fā)人員去調(diào)校，靠數(shù)據(jù)，靠試錯，靠經(jīng)驗。這些知識如何精確化、數(shù)字化下來，讓系統(tǒng)也具備這些能力，是我們要去努力的事情。

***，重要的一點是要持續(xù)提升原有的基礎能力，不是說我們今天智能化、自治化就是數(shù)據(jù)和算法，其他基礎能力同等重要，比如OPS，我們提出了一個ad-hoc執(zhí)行：假如決策模塊作出了一個決策是全網(wǎng)內(nèi)存水位高于95％的數(shù)據(jù)庫實例做一個action，你要能夠很快執(zhí)行下去。

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