close
編者按：11月16日，阿裡 雙十一 技術分享會上，阿裡巴巴技術保障部研究員林昊詳細解析瞭 異地多活 技術。相較於目前主流的 兩地三中心 ，該技術實現瞭質的飛躍。筆者對此的理解是， 提供 絲般柔順 的用戶體驗 ，即用戶在天貓、淘寶等阿裡平臺上的任何操作都流暢自如。而更為深入的技術剖析，請參閱以下演講實錄。
在去年 雙十一 之後，阿裡巴巴就對外宣傳瞭去年交易的 異地雙活 ，而今年則變成瞭 異地多活 ，意味著從雙走向瞭更多。
對於阿裡的交易以及支付來講，我們做異地多活最重要的目的除瞭災備之外，更重要的點是追求持續可用，整個支付交易的體量對於用戶來講是持續可用。
我們可以看一下業界比較主流的災備是怎麼做的，以及阿裡在這方面整個的演進。業界最重要的很多人都知道，最主流的災備技術是兩地三中心，數據中心A和數據中心B在同城作為生產級的機房，當用戶訪問的時候隨機訪問到數據中心A或B。之所以隨便訪問，因為A和B會同步做數據復制，所以兩邊的數據是完全一樣的。但是因為是同步復制的，所以隻能在同城去做兩個數據中心，否則太遠的話同步復制的延時會太長。在兩地三中心的概念裡，一定會要求這兩個生產級的數據中心是必須在同一個城市，或者在距離很近的另外一個城市也可以，但是距離是有要求的。
異地備份數據中心通過異步復制去走，但是兩地三中心很明顯的是異地備份的數據中心是不起用的，正常情況下不對外服務，所以用戶不會訪問到異地的點。原因是因為數據從生產級數據中心到異地的節點是異步去復制，所以整個有延時。這是整個業界目前用的比較多的業界。
兩地三中心對於阿裡來講看到的問題，最重要的問題：
1、這個模式不一定Work。大傢可能都看到某些新聞裡講過，比如說某些地方用瞭兩地三中心之後，當一地的數據中心出問題的時候，是不敢流量切往異地的備份數據中心，原因是異地的備份數據中心是冷的，平時是沒有用戶流量進去的。如果要把流量切到那邊起來之後，其實沒有人有多強的信心能夠保障起用以後是可以正常服務的，畢竟平時都是冷的。因為是冷的，就意味著整個起用的過程需要時間，不可能說起用就起用，一定會有時間周期。這是兩地三中心的最大問題，看起來模式是很安全的，也是可用的，但是事實上不一定是這樣。
2、異地備份中心因為不對外提供服務，所以整個資源會處於浪費狀態，成本比較高及
3、對於阿裡的規模來講有一個很大的問題，在兩地三中心中，數據一定是單點去寫。其實數據隻在一個地方去寫，這個時候如果整個壓力比較高，比如像 雙十一 的場景中壓力非常高的情況下，就意味著在兩地三中心的情況下所有的數據還是寫上的單個點，對於存儲成本壓力會不斷增加。比如去年8萬、今年14萬意味著每年壓力都在增加，這時候數據庫整個伸縮和外層業務的伸縮都面臨著更大挑戰。
對於我們來講這三個問題是比較明顯的。
阿裡在整個高可用上也經歷過瞭一段時間，主要是做瞭三個步驟。第一個是做瞭同城的雙活，第二個做瞭異地隻讀及冷備，第三個是做瞭異地多活，經歷瞭三代體系的演進才走到瞭今天。
異地多活前我簡單講一下，在異地多活之前，最重要是同城的 雙活 ，雙活上打瞭一個引號。原因在於同城雙活的情況下，其實整個模式是應用層是雙活的，兩邊的業務都有，用戶訪問過去都會處理請求。但是存儲層都是主備的，存儲主在A機房，備在B機房，不會同時用，可以說是偽雙活，不是真正意義上的雙活。阿裡做同城雙活做瞭挺長一段時間才真正做成功，因為雙活其實也是一樣的，如果真正做到就意味著同城任何一個機房出問題都可以切換到另外一個機房，如果沒有經過很多次真正切換的話，是沒有人敢說是一定能成功的。所以阿裡在那一年也是花瞭時間演練瞭非常多次，才真正能做到。
在完成同城雙活的改造之後開始嘗試異地，同城畢竟還是有很多因素的風險，所以去嘗試能不能走到異地遠的城市。最早嘗試的是隻讀業務和冷備，把阿裡的某些業務部署到另外一個城市去，開始隻是冷備用，冷備後來完全沒有辦法接受，因為阿裡的規模一年比一年大，冷備的成本越來越高，這個錢不值得付出。另外是冷備不Work，出狀況下不敢遷到異地去。
後來在這上面做瞭一點改進，所以決定把隻讀業務在異地起用，比如說像搜索等等算隻讀。但是發現對於阿裡業務來講，隻讀業務很難抽象，因為隻能服務隻讀業務，如果有寫就不能做。如果寫的話，就意味著寫到另外一個城市，這個延時接受不瞭，後來隻讀也覺得沒有太大意義。
當阿裡完成同城雙活以及異地隻讀、冷備嘗試以後，阿裡的階段也是兩地三中心，跟兩地三中心是一樣的。可以認為是兩地三中心稍微的升級版本，因為隻讀業務有部分的開放，有一部分的進步，但不是最理想的狀態。
阿裡決定開始做異地多活，對於我們來講，我們要去做到異地多活，要的目標是：
1、需要多個跨地域的數據中心。異地多活是跨地域的，而且距離一定要做貨車gps定位到1000公裡以上的范圍，其實在中國范圍內全國城市都可以去佈瞭。
2、每個數據中心都要承擔用戶的讀寫流量。如果隻是備或隻讀業務來講，作用不是很大。
3、多點寫。因為每個數據中心去承擔用戶讀寫流量的話，如果讀或寫集中到全國一個點的話，整個延遲是沒有辦法承受的。
4、任意一個數據中心出問題的時候，其他中心都可以分鐘級去接管用戶的流量。
這個是阿裡在做異地多活項目的時候，希望在這四點上都能夠做到，然後也隻有這樣的情況下才認為是一個異地多活的業務。
異地多活對於我們來講，其實很多人都可以看到異地多活最大的挑戰是什麼？
1、距離。看起來距離沒有什麼，比如說1000公裡以上也就是30毫秒的網絡延遲，來回一次是30毫秒左右。30毫秒對於用戶來講，如果隻是給你增加30毫秒，用戶其實沒有感受。但是當你打開一個淘寶頁面的時候，事實上當你在商品頁面看到一個商品點立刻購買的時候，頁面的背後大概有100多次以上的後端交互，如果100多次全部跨地域完成的話，就意味著頁面的響應時間將增加3秒。如果增加3秒，用戶絕對會有明顯感受。因為對於阿裡來講，很多頁面就出不來瞭，3秒已經超時瞭。對於我們來講，這第一點是直接帶來用戶體驗的不可用。
成本，當系統響應時間增高的時候，意味著每年 雙十一 增加的QPS將付出更大的成本，因為吞吐量在下降，這個時候的成本也是很難接受的。距離帶來的延時問題是最大的問題。
2、既然要解決掉距離的問題，多點寫是解決距離的問題，如果沒有延時問題可以不多點寫。隻要開始多點寫瞭就會帶來第二個最復雜的問題，其實我們認為第一點延時問題一定程度也許可以強制接受，也就是能夠打開，打不開就有問題瞭。如果一旦出現多點寫帶來的數據正確性問題，這對我們來講是最致命的。多點寫，比如說出現這一次訪問在A數據中心寫的數據，然後再訪問的時候到B數據中心又寫瞭一條數據，兩條數據如果合不到一起的話。對於大傢最直觀的感受是有可能買瞭一個東西付瞭錢，然後看到可能是沒付錢。或者幹脆買瞭一個東西，壓根就沒有看到購買。對於阿裡來講，這是最大的一個問題。
對於我們來講，在多點寫的情況下最大的挑戰是怎麼保證用戶寫入的數據一定是在正確的地方，另外看到的一定是一致的，這是整個異地多活中最大的挑戰。
針對這兩個個問題，對於延時的問題來講，其實延長時的問題意味著最好的解決方案是什麼呢？如果這一次訪問頁面的整個操作全部在當前機房內完成的，自然就不存在延時問題，因為沒有跨出去。
針對第二個問題，異地。在全國部署的時候，意味著是不是要把整個業務全部全國部署，因為這有成本因素。大傢知道阿裡的業務非常龐雜，其實沒有必要把所有的業務都在全國部署，因為不是所有的業務都有足夠的量。
因為不是整個業務全國部署，所以決定起另外一個名字叫單元化。意味著我是把業務劃成瞭各種各樣的單元，比如有交易的單元，這個單元是完成交易業務，所以在內部代號是單元化項目。
為瞭解決延時問題，能在一個機房內完成就不存在延時問題。另外一個核心思想是單元封閉，需要讓單元內的應用訪問和數據的讀寫操作全部處於封閉狀態，這就是最完美的狀況。如果能做到這樣，其實在全國任意城市部署都不會有問題。
開始多點寫以後，怎麼去保障整個數據寫入的正確性以及一致性。阿裡確實做瞭非常多的東西，因為一個用戶訪問阿裡的時候，其實阿裡的背後是龐大的分佈式系統，你訪問瞭一層可能隻訪問瞭一個系統，事實上背後物流路徑規劃牽涉進來幾十個系統。咱們把整你在訪問每一層的時候路由都是正確的，比如這個用戶訪問數據中心A，但是由於某個原因訪問到數據中心B，怎麼在保證後面訪問不同系統的時候準確跳轉到正確的地方去，因為每個數據中心的數據不太一樣。
為瞭保證一個用戶真正寫數據的時候不要寫錯，寫入數據庫之前都會做保護動作，確保用戶寫的數據沒有寫錯一個地方。如果寫錯一個地方，可能就無法恢復瞭，所以在那個地方有最後的一層保護。同時有實時數據校驗系統檢查是否符合我們的期望。
對於異地多活來講，還有數據一致性中很大的挑戰會出現在流量切換的動作中，比如說AB兩個數據中心，A開始貨車管理系統是承擔20%的流量，8承擔80%的流量。當把流量從一個地方切到另外一個地方的時間，有可能出現切換過程中你還在A數據中心寫，但其實寫完之後到B瞭，有可能看到出現的數據是不一致的。怎麼保證在整個流量切換過程中數據是絕對一致的，我們也做瞭很多的東西。
在異地整個數據中心還有另外一個非常重要的核心技術產品，就是我們需要一個數據同步的東西。因為大傢知道阿裡現在除瞭OB以外，很重要的一塊是MySQL，MySQL自己的主備是沒有辦法滿足要求，在異地做到延時是沒有辦法滿足的，我們決定做瞭自研的數據同步產品。在2015年 雙十一 中，所有數據同步控制在1秒以內，1秒以內是可以接受的。
阿裡為瞭做到整個異地多活，其實自己也折騰瞭很多年。這個項目在阿裡內部總共花瞭三年的時間，自己在最近的一封總結郵件中也寫到，經歷瞭三年的磨煉，我們終於把異地多活變成瞭阿裡電商架構級的能力，意味著在整個架構中具備異地多活的能力，在以前也許不一定具備。
我們為瞭整個過程中是比較平滑的，因為不能對業務產生太大影響，所以分瞭三年的時間去完成。在2013年首先采用的是在同城起用瞭兩個單元雙活，真正意義的雙活，因為那兩個單元都是寫自己的數據庫的，兩個單元都是雙寫。
之所以在2013年選擇同一個城市，是因為我們擔心單元化改造沒有完成的情況下如果走向異地，可能會因為延時問題導致頁面打不開，那個問題是非常嚴重的，所以決定先在同城做。同城的話，及時沒有改造好，跨出去瞭也沒有關系，因為還在同城，延時是可控的。
在2014年覺得可以往前更進一步，選擇瞭距離更近的城市，其實還是有延時。如果沒有做過單元化改造業務部署到異地的時候，頁面會超時，有些頁面打不開。但是因為單元化在背後就沒有太大問題，在2014年成功在兩個相距有一定距離的城市起用瞭異地雙活，在去年 雙十一 中兩個城市分別承擔瞭50%的用戶流量，有些用戶會訪問一個城市，有些用戶訪問另外一個城市，當下單的時候會下在同一個城市裡面。
在今年單元化可以宣告能力基本成熟的階段，所以在今年開始起用瞭距離在1000公裡以上的另外一個數據中心，然後今年數據中心是多點部署。從2015年從2個變成3個或4個以後，對於我們來講的另外一點是因為距離增加到瞭1000公裡以上，基本上意味著阿裡整個電商以及支付是可以在全國任意一個城市去部署，並且可以部署多個，意味著以後的 雙十一 整個擴充能力是會變得很容易。
對於我們來講，當阿裡整個架構能力進一步提升到瞭異地多活時代以後，對於我們來講帶來瞭兩個好處：
第一、有極強的水平伸縮能力。以前做 雙十一 的時候，都必須去算，比如去年8萬筆，今年14萬筆的時候，必須要算增加的6萬。還有因為每年業務模式的變化需要算每個應用加多少機器。但是在單元的情況下，一組單元就是多大的能力，然後隻要按照單元擴充就結束瞭。假設一個單元可以做到2萬筆，其實14萬筆對於我們來講是建設7個單元就結束瞭，整個伸縮能力會比以前強大非常多。而且每個單元都是寫自己的數據庫和存儲層，包括cache全部寫自己的，這個時候伸縮規模是可控的，不像以前不斷加，數據庫有可能抗不住。在抗不住的時候可能會做分佈等等，但其實也是比較復雜的，現在我們改變瞭伸縮力度的模式。
第二、異地多活怎麼去應對故障。比如在阿裡內部會按照這樣的等級去劃分所有業務能夠支持故障應對能力，比如說單實例出故障在多久能恢復，或者單機房或單城市或全局的服務，比如DNS等等，我們會按照這個對每個業務，然後就知道每個業務當出現故障時整個應對能力是怎樣的。
這個是今年 雙十一 的圖，背後有一個淘寶的異地多活，在這張圖上可以看到有4個點的流量。如果大傢去翻去年的 雙十一 ，發現去年是2個點，然後今年變成瞭4個點。下面的比例是我們隨時都可以變化的，所以大傢不用太在意。其實淘寶的異地多活或者整個阿裡的交易額支付其實經常切，比如在昨天就切瞭好幾次流量。其實我們整個是可以不斷去做的。支付寶和淘寶稍微有點不同，支付寶今年起用瞭兩個，分別是華南和華東，分別有不同比率的流量。
在阿裡做完以後，希望整個異地多活的能力能逐漸演變成業界的，比如說在阿裡做瞭整個多活以後，其實金融行業也不再希望自己隻是一個兩地三中心而已，希望更加往前前進一步，對於他們來講整個投入會更加劃算。另外容災能力會更強。阿裡把自己異地多活的能力沉淀成不同的東西，比如支付寶、螞蟻金服把自己的能力承擔到金融雲裡，就意味著在金融雲上搭建的金融系統會自然具備異地多活的能力。
阿裡自己也經歷瞭三年的磨煉，阿裡雲很大的價值是可以讓你在更簡單的情況下獲取到更強大的能力。比如阿裡雲的產品中像前段時間開放的DTS，內部做多個數據中心之間數據同步的產品。像下面的EDAS、DRDS、ONS是內部的中間件產品，在做整個異地多活過程中所有中間件都需要改造，否則沒有辦法做異地多活。這些開放的產品，自然在內部具備瞭異地多活的能力。所以當外部用戶去用的時候，當演進到這一步會比阿裡巴巴簡單很多，因為阿裡逐漸往外開放。
AUGI SPORTS｜重機車靴｜重機車靴推薦｜重機專用車靴｜重機防摔鞋｜重機防摔鞋推薦｜重機防摔鞋
AUGI SPORTS｜augisports｜racing boots｜urban boots｜motorcycle boots
文章標籤
全站熱搜
留言列表
