解密阿里巴巴高可用架構技術——「異地多活」

阿里巴巴技術保障部研究員畢玄是「異地多活」項目的發起人之一，讓他來談談「異地多活」技術的誕生歷程是最爲合適不過的了。

畢玄同窗，跟你們嘮一嘮「異地多活」技術。

如下爲演講實錄：

在去年「雙十一」以後，阿里巴巴就對外宣傳了去年交易的「異地雙活」，而今年則變成了「異地多活」，意味着從「雙」走向了更多。

阿里巴巴高可用架構的演進史

對於阿里的交易以及支付來說，咱們作異地多活最重要的目的除了災備以外，更重要的點是追求持續可用，整個支付交易的體量對於用戶來說是持續可用。

咱們能夠看一下業界比較主流的災備是怎麼作的，以及阿里在這方面整個的演進。業界最重要的不少人都知道，最主流的災備技術是兩地三中心，數據中心A和數據中心B在同城做爲生產級的機房，當用戶訪問的時候隨機訪問到數據中心A或B。之因此隨便訪問，由於A和B會同步作數據複製，因此兩邊的數據是徹底同樣的。可是由於是同步複製的，因此只能在同城去作兩個數據中心，不然太遠的話同步複製的延時會太長。在兩地三中心的概念裏，必定會要求這兩個生產級的數據中心是必須在同一個城市，或者在距離很近的另一個城市也能夠，可是距離是有要求的。

異地備份數據中心經過異步複製去走，可是兩地三中心很明顯的是異地備份的數據中心是不起用的，正常狀況下不對外服務，因此用戶不會訪問到異地的點。緣由是由於數據從生產級數據中心到異地的節點是異步去複製，因此整個有延時。這是整個業界目前用的比較多的業界。

 

兩地三中心對於阿里來說看到的問題，最重要的問題：

一、這個模式不必定Work。你們可能都看到某些新聞裏講過，好比說某些地方用了兩地三中心以後，當一地的數據中心出問題的時候，是不敢流量切往異地的備份數據中心，緣由是異地的備份數據中心是冷的，平時是沒有用戶流量進去的。若是要把流量切到那邊起來以後，其實沒有人有多強的信心可以保障起用之後是能夠正常服務的，畢竟平時都是冷的。由於是冷的，就意味着整個起用的過程須要時間，不可能提及用就起用，必定會有時間週期。這是兩地三中心的最大問題，看起來模式是很安全的，也是可用的，可是事實上不必定是這樣。

二、異地備份中心由於不對外提供服務，因此整個資源會處於浪費狀態，成本比較高。

三、對於阿里的規模來說有一個很大的問題，在兩地三中心中，數據必定是單點去寫。其實數據只在一個地方去寫，這個時候若是整個壓力比較高，好比像「雙十一」的場景中壓力很是高的狀況下，就意味着在兩地三中心的狀況下全部的數據仍是寫上的單個點，對於存儲成本壓力會不斷增長。好比去年8萬、今年14萬意味着每一年壓力都在增長，這時候數據庫整個伸縮和外層業務的伸縮都面臨着更大挑戰。

對於咱們來說這三個問題是比較明顯的。

阿里在整個高可用上也經歷過了一段時間，主要是作了三個步驟。第一個是作了同城的雙活，第二個作了異地只讀及冷備，第三個是作了異地多活，經歷了三代體系的演進才走到了今天。

在異地多活以前，最重要是同城的「雙活」，雙活上打了一個引號。緣由在於同城雙活的狀況下，其實整個模式是應用層是雙活的，兩邊的業務都有，用戶訪問過去都會處理請求。可是存儲層都是主備的，存儲主在A機房，備在B機房，不會同時用，能夠說是僞雙活，不是真正意義上的雙活。阿里作同城雙活作了挺長一段時間才真正作成功，由於雙活其實也是同樣的，若是真正作到就意味着同城任何一個機房出問題均可以切換到另一個機房，若是沒有通過不少次真正切換的話，是沒有人敢說是必定能成功的。因此阿里在那一年也是花了時間演練了很是屢次，才真正能作到。

在完成同城雙活的改造以後開始嘗試異地，同城畢竟仍是有不少因素的風險，因此去嘗試能不能走到異地遠的城市。最先嚐試的是隻讀業務和冷備，把阿里的某些業務部署到另一個城市去，開始只是冷備用，冷備後來徹底沒有辦法接受，由於阿里的規模一年比一年大，冷備的成本愈來愈高，這個錢不值得付出。另外是冷備不Work，出情況下不敢遷到異地去。

後來在這上面作了一點改進，因此決定把只讀業務在異地起用，好比說像搜索等等算只讀。可是發現對於阿里業務來說，只讀業務很難抽象，由於只能服務只讀業務，若是有寫就不能作。若是寫的話，就意味着寫到另一個城市，這個延時接受不了，後來只讀也以爲沒有太大意義。

當阿里完成同城雙活以及異地只讀、冷備嘗試之後，阿里的階段也是兩地三中心，跟兩地三中心是同樣的。能夠認爲是兩地三中心稍微的升級版本，由於只讀業務有部分的開放，有一部分的進步，但不是最理想的狀態。

「異地多活」的目標與挑戰

阿里決定開始作異地多活，對於咱們來說，咱們要去作到異地多活，要的目標是：

一、須要多個跨地域的數據中心。異地多活是跨地域的，並且距離必定要作到1000千米以上的範圍，其實在中國範圍內全國城市均可以去布了。

二、每一個數據中心都要承擔用戶的讀寫流量。若是隻是備或只讀業務來說，做用不是很大。

三、多點寫。由於每一個數據中心去承擔用戶讀寫流量的話，若是讀或寫集中到全國一個點的話，整個延遲是沒有辦法承受的。

四、任意一個數據中心出問題的時候，其餘中心均可以分鐘級去接管用戶的流量。

這個是阿里在作異地多活項目的時候，但願在這四點上都可以作到，而後也只有這樣的狀況下才認爲是一個異地多活的業務。

異地多活對於咱們來說，其實不少人均可以看到異地多活最大的挑戰是什麼？

一、距離。看起來距離沒有什麼，好比說1000千米以上也就是30毫秒的網絡延遲，來回一次是30毫秒左右。30毫秒對於用戶來說，若是隻是給你增長30毫秒，用戶其實沒有感覺。可是當你打開一個淘寶頁面的時候，事實上當你在商品頁面看到一個商品點馬上購買的時候，頁面的背後大概有100屢次以上的後端交互，若是100屢次所有跨地域完成的話，就意味着頁面的響應時間將增長3秒。若是增長3秒，用戶絕對會有明顯感覺。由於對於阿里來說，不少頁面就出不來了，3秒已經超時了。對於咱們來說，這第一點是直接帶來用戶體驗的不可用。

成本，當系統響應時間增高的時候，意味着每一年「雙十一」增長的QPS將付出更大的成本，由於吞吐量在降低，這個時候的成本也是很難接受的。距離帶來的延時問題是最大的問題。

二、既然要解決掉距離的問題，多點寫是解決距離的問題，若是沒有延時問題能夠很少點寫。只要開始多點寫了就會帶來第二個最複雜的問題，其實咱們認爲第一點延時問題必定程度也許能夠強制接受，也就是可以打開，打不開就有問題了。若是一旦出現多點寫帶來的數據正確性問題，這對咱們來說是最致命的。多點寫，好比說出現這一次訪問在A數據中心寫的數據，而後再訪問的時候到B數據中心又寫了一條數據，兩條數據若是合不到一塊兒的話。對於你們最直觀的感覺是有可能買了一個東西付了錢，而後看到多是沒付錢。或者乾脆買了一個東西，壓根就沒有看到購買。對於阿里來說，這是最大的一個問題。

對於咱們來說，在多點寫的狀況下最大的挑戰是怎麼保證用戶寫入的數據必定是在正確的地方，另外看到的必定是一致的，這是整個異地多活中最大的挑戰。

針對這兩個問題，對於延時的問題來說，其實延長時的問題意味着最好的解決方案是什麼呢？若是這一次訪問頁面的整個操做所有在當前機房內完成的，天然就不存在延時問題，由於沒有跨出去。

針對第二個問題，異地。在全國部署的時候，意味着是否是要把整個業務所有全國部署，由於這有成本因素。你們知道阿里的業務很是龐雜，其實沒有必要把全部的業務都在全國部署，由於不是全部的業務都有足夠的量。

由於不是整個業務全國部署，因此決定起另一個名字叫單元化。意味着我是把業務劃成了各類各樣的單元，好比有交易的單元，這個單元是完成交易業務，因此在內部代號是單元化項目。

爲了解決延時問題，能在一個機房內完成就不存在延時問題。另一個核心思想是單元封閉，須要讓單元內的應用訪問和數據的讀寫操做所有處於封閉狀態，這就是最完美的情況。若是能作到這樣，其實在全國任意城市部署都不會有問題。

開始多點寫之後，怎麼去保障整個數據寫入的正確性以及一致性。阿里確實作了很是多的東西，由於一個用戶訪問阿里的時候，其實阿里的背後是龐大的分佈式系統，你訪問了一層可能只訪問了一個系統，事實上背後牽涉進來幾十個系統。我們把整你在訪問每一層的時候路由都是正確的，好比這個用戶訪問數據中心A，可是因爲某個緣由訪問到數據中心B，怎麼在保證後面訪問不一樣系統的時候準確跳轉到正確的地方去，由於每一個數據中心的數據不太同樣。

爲了保證一個用戶真正寫數據的時候不要寫錯，寫入數據庫以前都會作保護動做，確保用戶寫的數據沒有寫錯一個地方。若是寫錯一個地方，可能就沒法恢復了，因此在那個地方有最後的一層保護。同時有實時數據校驗系統檢查是否符合咱們的指望。

對於異地多活來說，還有數據一致性中很大的挑戰會出如今流量切換的動做中，好比說AB兩個數據中心，A開始是承擔20%的流量，8承擔80%的流量。當把流量從一個地方切到另一個地方的時間，有可能出現切換過程當中你還在A數據中心寫，但其實寫完以後到B了，有可能看到出現的數據是不一致的。怎麼保證在整個流量切換過程當中數據是絕對一致的，咱們也作了不少的東西。

在異地整個數據中心還有另一個很是重要的核心技術產品，就是咱們須要一個數據同步的東西。由於你們知道阿里如今除了OceanBase之外，很重要的一塊是MySQL，MySQL本身的主備是沒有辦法知足要求，在異地作到延時是沒有辦法知足的，咱們決定作了自研的數據同步產品。在2015年「雙十一」中，全部數據同步控制在1秒之內，1秒之內是能夠接受的。

阿里爲了作到整個異地多活，其實本身也折騰了不少年。這個項目在阿里內部總共花了三年的時間，本身在最近的一封總結郵件中也寫到，經歷了三年的磨鍊，咱們終於把異地多活變成了阿里電商架構級的能力，意味着在整個架構中具有異地多活的能力，在之前也許不必定具有。

咱們爲了整個過程當中是比較平滑的，由於不能對業務產生太大影響，因此分了三年的時間去完成。在2013年首先採用的是在同城起用了兩個單元雙活，真正意義的雙活，由於那兩個單元都是寫本身的數據庫的，兩個單元都是雙寫。

之因此在2013年選擇同一個城市，是由於咱們擔憂單元化改造沒有完成的狀況下若是走向異地，可能會由於延時問題致使頁面打不開，那個問題是很是嚴重的，因此決定先在同城作。同城的話，及時沒有改造好，跨出去了也沒有關係，由於還在同城，延時是可控的。

在2014年以爲能夠往前更進一步，選擇了距離更近的城市，其實仍是有延時。若是沒有作過單元化改造業務部署到異地的時候，頁面會超時，有些頁面打不開。可是由於單元化在背後就沒有太大問題，在2014年成功在兩個相距有必定距離的城市起用了異地雙活，在去年「雙十一」中兩個城市分別承擔了50%的用戶流量，有些用戶會訪問一個城市，有些用戶訪問另一個城市，當下單的時候會下在同一個城市裏面。

在今年單元化能夠宣告能力基本成熟的階段，因此在今年開始起用了距離在1000千米以上的另一個數據中心，而後今年數據中心是多點部署。從2015年從2個變成3個或4個之後，對於咱們來說的另一點是由於距離增長到了1000千米以上，基本上意味着阿里整個電商以及支付是能夠在全國任意一個城市去部署，而且能夠部署多個，意味着之後的「雙十一」整個擴充能力是會變得很容易。

「異地多活」的價值

對於咱們來說，當阿里整個架構能力進一步提高到了異地多活時代之後，對於咱們來說帶來了兩個好處：

第1、有極強的水平伸縮能力。之前作「雙十一」的時候，都必須去算，好比去年8萬筆，今年14萬筆的時候，必需要算增長的6萬。還有由於每一年業務模式的變化須要算每一個應用加多少機器。可是在單元的狀況下，一組單元就是多大的能力，而後只要按照單元擴充就結束了。假設一個單元能夠作到2萬筆，其實14萬筆對於咱們來說是建設7個單元就結束了，整個伸縮能力會比之前強大很是多。並且每一個單元都是寫本身的數據庫和存儲層，包括cache所有寫本身的，這個時候伸縮規模是可控的，不像之前不斷加，數據庫有可能抗不住。在抗不住的時候可能會作分佈等等，但其實也是比較複雜的，如今咱們改變了伸縮力度的模式。

第2、異地多活怎麼去應對故障。好比在阿里內部會按照這樣的等級去劃分全部業務可以支持故障應對能力，好比說單實例出故障在多久能恢復，或者單機房或單城市或全局的服務，好比DNS等等，咱們會按照這個對每一個業務，而後就知道每一個業務當出現故障時整個應對能力是怎樣的。

這個是今年「雙十一」的圖，背後有一個淘寶的異地多活，在這張圖上能夠看到有4個點的流量。若是你們去翻去年的「雙十一」，發現去年是2個點，而後今年變成了4個點。下面的比例是咱們隨時均可以變化的，因此你們不用太在乎。其實淘寶的異地多活或者整個阿里的交易額支付其實常常切，好比在昨天就切了好幾迴流量。其實咱們整個是能夠不斷去作的。支付寶和淘寶稍微有點不一樣，支付寶今年起用了兩個，分別是華南和華東，分別有不一樣比率的流量。

在阿里作完之後，但願整個異地多活的能力能逐漸演變成業界的，好比說在阿里作了整個多活之後，其實金融行業也再也不但願本身只是一個兩地三中心而已，但願更加往前前進一步，對於他們來說整個投入會更加划算。另外容災能力會更強。阿里把本身異地多活的能力沉澱成不一樣的東西，好比支付寶、螞蟻金服把本身的能力承擔到金融雲裏，就意味着在金融雲上搭建的金融系統會天然具有異地多活的能力。

阿里本身也經歷了三年的磨鍊，阿里雲很大的價值是可讓你在更簡單的狀況下獲取到更強大的能力。好比阿里雲的產品中像前段時間開放的DTS，內部作多個數據中心之間數據同步的產品。像下面的EDAS、DRDS、ONS是內部的中間件產品，在作整個異地多活過程當中全部中間件都須要改造，不然沒有辦法作異地多活。這些開放的產品，天然在內部具有了異地多活的能力。因此當外部用戶去用的時候，當演進到這一步會比阿里巴巴簡單不少，由於阿里逐漸往外開放。