DTCC 2020 | 阿里雲王濤：阿里巴巴電商數據庫上雲實踐

簡介： 第十一屆中國數據庫技術大會（DTCC2020），在北京隆重召開。大會以「架構革新 高效可控」爲主題，重點圍繞數據架構、AI與大數據、傳統企業數據庫實踐和國產開源數據庫等內容展開分享和探討。在數據庫智能運維專場上，邀請了阿里雲數據庫高級技術專家王濤爲你們介紹阿里巴巴電商數據庫上雲的選擇、思考與實踐。阿里巴巴電商數據庫原先是在本身獨立的IDC維護的，伴隨着阿里巴巴上雲項目，數據庫輕鬆實現上雲。阿里云云原生管控以及雲原生數據庫技術能夠幫助業務實現平滑上雲目標，進而實現資源最大化成本最優化的目標。阿里巴巴但願利用阿里雲的技術體系，幫助客戶大規模上雲，打造本身的運維管控平臺。

演講嘉賓簡介：

王濤，阿里雲數據庫高級技術專家，來自阿里雲數據庫產品事業部，喜歡並熱愛數據庫。
職業生涯：程序員->DBA->DevOps架構師。2007年開始參與、設計、主導了阿里巴巴數據庫體系演進，主導參與了阿里巴巴數據庫體系演進，經歷了數據庫去IOE，規模化MySQL運維，阿里數據庫異地多活，數據庫上雲等多個核心項目。目前爲阿里雲RDS管控負責人，爲你們提供安全、穩定、經濟、智能的數據庫服務。

本次分享主要圍繞如下四個方面：
1、阿里巴巴電商數據庫應用場景介紹
2、數據庫管控平臺演進
3、數據庫上雲的選擇與思考
4、將來展望

1、阿里巴巴電商數據庫應用場景介紹

1. 阿里業務特性介紹 —— RDS三節點企業版

什麼是阿里巴巴電商數據呢？你們看到的淘寶、天貓、盒馬、餓了麼上的數據都屬於阿里巴巴電商數據，這些業務說使用的數據庫目前都在雲上。阿里巴巴以前的數據庫是RDS高可用版，採用一主多備模式，可是發現實例沒法作到RPO爲零。嘗試使用了MySQL半同步等措施，但依然沒法解決RPO爲零的問題。其次是考慮採起CAP理論或者BASE理論的問題。CAP指的是一致性（Consistency）、可用性（Availability）、分區容忍性（Partition tolerance）。但事實上數據庫是沒法作到同時知足CAP中的三點特性的，只能知足其中一到兩項。對於BASE理論你們或許不太熟悉，其核心在於能夠作到中間不一致，A和B機器可能單獨的時候不一致，可是一旦連上以後就會一致。數據管控系統上一般遵照BASE理論，數據庫更多的時候是選擇CAP原理。解決RPO等於0的問題有幾種實現方式，首先是MySQL半同步、還有MySQL Group Replication，這是MySQL 5.7版本以後推出的新功能，可是要求三份數據同樣，這個成本是沒法接受的。所以阿里逐漸走向了RDS自研的方向。

阿里巴巴在選擇數據庫協議也是在Paxos協議 or Raft協議中徘徊，最終選擇了Paxos協議。

阿里巴巴在選擇數據庫協議也是在Paxos協議 or Raft協議中徘徊，最終選擇了Paxos協議。Why Paxos，No Raft? 從下圖右側能夠看到前面都在提交數據X、後面來了數據Y，在S3中先執行了P3.1，P4.5，A4.5 Y，這意味着Paxos協議不必定要有序，而Raft是有序的。Raft協議會要求S3先執行P3.一、A 3.1 X而後再執行P4.5，A 4.5 Y。這是Paxos協議和 Raft協議最大的不一樣。其次，Paxos協議有三種角色，提交者（Propose），接收者（Accept）以及Learn。阿里巴巴自研的RDS對這三種角色進行了轉化，Propose叫作Leader，指的是可讀可寫的數據庫節點，Accept叫作Follower，多數派，有全量的數據，能夠將本身變成Leader。還有Logger（阿里自研角色），只負責接收日誌，沒有數據。Leader和Follower有全量數據，Logger只是日誌接收節點，如此CPU和內存成本就會下降。Learn叫作Learner，屬於觀察者角色，有全量數據但沒有投票權，即便Learner掛掉，也不會影響Learner多數提交。

2. 阿里業務特性介紹 —— 異地多活

衆所周知，阿里巴巴的業務還有一個特性，就是異地多活。異地多活有兩點好處，都是能夠具有Region級別逃逸能力，用戶能夠在任意單元進行交易。下圖右側是User經過規則分流，在數據中心及其它單元均可以進行交易。異地多活能夠作到水平擴展和異地容災，在每一年的雙11能夠臨時創建站點，在9月份建好，在雙11以後2周撤掉。

3. 阿里業務特性介紹 —— 數據庫異地多寫

那麼RDS如何應對異地多活？異地多活意味着異地多寫。下圖展現了支持異地多活的數據庫分佈狀況，首先要有一箇中心DB，對應多箇中心環境，分別是交易、購物車、商品等。中心數據庫寫的數據會到對應的Store，Store能夠避免調多個線程時影響數據庫性能的問題。Writer負責將數據寫到對應的單元DB。單元DB中的數據經過Store回到中心的Writer，回到中心DB。能夠發現數據的push呈現星狀，而不是網狀，這是出於幾點考慮，首先很難作DTL，你們都在作DTL，很容易被複制；其次，星狀結構能夠至少保證一個節點數據是全局一致的，哪怕單元DB掛掉，在中心DB中也有全量數據。

4. 阿里業務特性介紹 —— 數據庫異地只讀

阿里業務特性使得數據庫須要有支持異地只讀的特性。Learner節點，具有全量數據，不影響Paxos協議，每一個Learner節點都要災備節點。基於數據庫原生複製一致性高。要保證MySQL內部數據的一致性。所以數據庫架構會以下圖右側所示，中心有三種節點：Follower、Logger、Learner，它們之間能夠互相切換。每一個單元有Learner節點和備用的Learner節點，單元應用也在單元Learner中。假設要作一級容災，那麼能夠將單元寫權重路由到中心，經過中心再Put到各個單元中，如此不只能夠作的全局一致性還能夠作到異地多寫。

2、數據庫管控平臺演進

1. 數據庫管控平臺定義

你們每每會誤覺得作數據庫管控就是作數據庫運維，但事實上並非那麼簡單。數據庫管控要作的事情有很是多：
首先，數據庫高可用是獨立的模塊，業界經常使用的有HA策略；數據備份，業界有備份策略，如全量備份、日誌備份、數據軌跡備份等；數據庫運維包括實例建立、實例變動、實例銷燬、備庫重大搭等；建設基礎設施，如IDC、服務器選型、硬件運維、CMDB；數據庫監控鏈路和數據告警鏈路兩個不一樣的模塊；還有數據庫的計量計費；資源調度；控制檯；數據庫底層服務，如網關、服務發現等；數據庫安全；智能數據庫，如數據庫智能診斷、數據庫智能調參、性能調優等，也是目前主要的一個模塊；數據巡檢，如配置、參數、狀態巡檢；網絡管理；故障演練；異地多活等等。

能夠發現，即便粗略的羅列完數據庫管控平臺包含的內容，也會很是多的模塊，這致使平臺的系統性、複雜性都很高，因爲對數據庫的依賴性很高，必然形成對其可用性的要求的提高。那麼這些要求應該如何知足？

2. 阿里巴巴數據庫管控平臺演進

阿里巴巴的數據庫管控平臺也是經歷了若干代前輩的努力：
1) 2003年，當時並無DBA這個職業。阿里從SA（系統管理員）團隊拆出了一位同窗作DBA，屬於純人工運維。
2) 2006年，開始使用業界流行的Nagios、Cacti等開源工具。
3) 2009年，阿里開始自研，自主研發了第一代運維繫統「北斗」，替換了Nagios、Cacti等開源工具。
4) 2010年，阿里巴巴開始進行去IOE工做，加速了管控的規模化運維，阿里第一代MySQL運維繫統誕生，「天機」。主要面向監控、可用性、備份。屬於單體應用。
5) 2013年，隨着業務規模不斷擴大，阿里第二代MySQL運維繫統誕生，「DBFree」。主要面向自動化運維。
6) 2016年，阿里第三代數據庫運維繫統「DBPaaS」誕生，知足異地多活、混合雲等業務需求。
7) 2018年，底層IaaS上雲，使用雲資源。
8) 2020年，阿里電商數據庫全面開始上雲，開始使用雲管控。全部核心數據庫（交易、購物車、商品、優惠等）及核心鏈路都採用雲數據庫專屬集羣（MyBase）模式。基於雲原生數據庫，構建了上萬個節點，實現了RPO=0。

數據庫上雲的選擇與思考

1. 上雲方案選擇 —— 數據上雲方案選擇

數據上雲方案有不少選擇。首先是數據上雲方式的選擇，是使用邏輯遷移仍是物理遷移？下圖這兩種數據上雲方式的對比，絕大多數遷移都是邏輯遷移，使用的是MySQL/DTS的方式。可是阿里巴巴的業務特性致使數據規模的體量巨大，須要使用物理遷移，XtraBackup雲原生物理遷移。上雲以後在2020年12月底，MyBase會推出物理機房push的上雲模式。從下圖能夠發現遷移的效率、數據對象平滑線、數據一致性、權限等相比於邏輯遷移都是較高的。對於小規模數據上雲時邏輯遷移是足夠的，可是大規模體量下，物理遷移更合適。

2. 上雲方案選擇 —— 網絡方案選擇

在網絡方面也有幾種選擇，首先是ALB，它最好的優勢是相對成熟，可是也存在很明顯的缺點，就是全部的包都要通過ALB，這不符合極致性能要求。NGLB，能夠解決ALB的痛點，只有首包通過XGW，後面的包不須要通過。可是在0點場景中，NGLB的確是扛不住的。NGLB也不支持ECS。ENI（彈性網卡），業界主推的彈性網卡方案。可是彈性網卡方案依然有個問題，就是不支持物理機。這使得阿里巴巴又往ENI+RDS走了一步，可是目前尚未計劃推出這個產品，並且因爲網卡都是雙向聯通的，會存在安全風險。阿里目前使用的是ENI+MyBase方案，此方案的優勢是應用和數據庫在同一個網絡平面，中間沒有代理層，效率較高。但對於管控而言，複雜度提高了很多。一個機器上有兩塊網卡，用戶用到的網卡和物理機網卡。機器不得不作兩次操做，分別是數據鏈路和管控鏈路。考慮到數據須要雙向聯動和性能問題，因此使用了ENI，又考慮到安全性問題，使用了ENI+MyBase方式。

3. 上雲方案選擇 —— 網絡拓撲圖

以下圖，最上層是數據庫管控平面，下一層是RDS售賣區VPC，用戶中心VPC與用戶單元VPC之間經過CEN打通，使得全鏈路打通，這裏使用了阿里雲產品支撐整個雲上架構。在雲下，支持用戶自建網絡，經過專線打通用戶自建網絡與用戶中心VPC，用戶單元VPC。用戶自建網絡之間經過專線打通。保證整個數據庫在用戶之間是聯通的。

4. 上雲方案選擇 —— 裸金服務器

阿里巴巴沒有使用普通的金屬服務器，而是使用了裸金服務器。它們之間區別在於裸金服務
器最下層有一個叫作X-Dragon芯片，也叫MOC卡。機器自己是耗費資源的，但使用「神龍」服務器之後能夠徹底剝離掉這部分，就是說若是買了96C，768G的機器，那麼就是這麼多的資源，不會再由於虛擬化的成本帶來額外的開銷。MOC卡還有一個做用是上層的組件，如VPC/SLB、EBS雲盤都會通過MOC卡進行虛擬化，大大減小其它開銷，也就是把一臺機器變成和虛擬機同樣的用戶體驗。

使用X-Dragon架構能夠分鐘級的去建立100％物理機性能和功能的雲服務器，兼容VPC、SLB、RDS，支撐雲盤啓動和掛載雲盤，兼容虛擬機鏡像，保證物理機的性能和隔離性，。免去了人肉自動運維的事情。使用ECS還能夠在宕機後，10分鐘內原地拉起一臺數據庫，遷移恢復。

基於下圖中幾方面的考慮，在對比了物理機，虛擬機KVM，裸金屬服務器ECS以後，阿里巴巴選擇了裸金屬服務器。運維自動化方面裸金屬服務器支撐分鐘級交付。使用MOC卡機器是無損耗的。在存儲方面，裸金屬服務器操做系統使用了雲盤，能夠快速重置系統盤。在網絡方面，物理機部分支持網絡一致性。裸金屬服務器方案和虛擬機都兼容ECS現有管控。

上雲方案選擇 —— 存儲選擇

下面簡單討論一下存儲爲什麼使用雲盤？原來雲盤最大的上限是16T，如今這個值已經變成了32T，基本能夠知足99%以上用戶的數據庫需求，而物理機可能最多隻有6T。雲盤能夠支持分鐘級備份，而以前的方法遷移1T數據就須要3個小時。雲盤分鐘級實例Clone、分鐘級實例跨Region Clone、數據在線擴盤。運維人員在設置數據庫的性能時很是頭疼，沒有可選的辦法，雲盤可支持磁盤IOPS可配置，意味着能夠運維人員強制設置數據庫IO吞吐，目前最高的吞吐是500MB/秒。MySQL有double write的特性，雲盤支撐MySQL原子寫，少了一次write的開銷。可靠性方面物理機老是沒有分佈式存儲高。一個ECS，裏面是POD，拉起一個容器，使用ESSD存儲，最下面是分佈式存儲。

上雲方案選擇 ——異地只讀（GAN）

目前阿里雲尚未開放異地只讀的上雲特性。阿里巴巴但願作到各個Region獨立，主要是基於Global Database Network解決方案。上海的APP經過MaxScale到上海的數據庫，同理，深圳的APP經過MaxScale一部分分流到原生的數據庫Leader中，一部分到深圳的數據庫，從而實現異地多寫。

7. 上雲方案選擇 —— 充分利用MyBase特性

爲何使用MyBase? 以下圖，買了一對雲主機，左側備份幾個Leader，幾個Follower，右側同理。節點之間作到親和、交叉、超賣、彈性。MyBase能夠作到交叉，兩主兩備，性能最好，其次是親和，購物車的數據和其它數據庫在一塊兒，但又互相獨立。由於業務特性須要進行臨時擴容，這種狀況很是常見，而MyBase能夠作到動態的調參。由於底層使用了雲盤，能夠知足彈性需求。

8. 上雲的方案9大特性

總結而言，上雲的方案分別要知足如下9個特性：

• 高可用：數據庫主備架構，高可用性保障，宕機自動切換、修復。
• 高可靠：數據庫多副本保障、數據同步可調一致性保障（RPO優先）、三節點企業版RPO=0保障。
• 高性能：內核性能提高，相比開源版本MySQL（1.5x）Redis（3x）。
• 高安全：SSL鏈路加密、TDE落盤加密、審計日誌體系等。保障事前，事中，過後的數據庫安全。
• 運維能力：備份恢復、監控報警、智能運維診斷等全套數據庫運維解決方案。
• 自主可控：開放OS、數據庫完整權限；開放數據庫管控平臺標準化底層接口；用戶可深度自定義數據庫管理邏輯。
• 混部：混合部署MySQL、Redis等，並提供雲數據庫管理特性。
• 資源調度：用戶專屬一片物理主機資源池，可自定義實例分配、分佈策略，高度適配業務需求。
• 超配能力：用戶物理資源100%隔離，支持CPU、內存（Redis）、空間等資源的超配。

數據庫上雲是出於幾點考慮，首先自建數據庫不支持不少的數據庫管控平臺特性，RDS支持部分特性，如彈性網卡等。而MyBase是在RDS基礎之上衍生出來的產品，目前基本均可以支持這9個特性。

4、總結及將來展望

1.上好雲，用好雲

阿里巴巴數據庫上雲是考慮到業務自己場景，還有云原生技術，以及促進阿里雲內部改造等緣由。目前2020年雙11期間交易額達到了4982億，高峯訂單58.3萬筆/秒，雲原生數據庫能夠很平滑的支持這些業務。阿里巴巴電商數據庫上雲不只僅是把數據庫搬上雲，更多的思考是如何上好雲，用好雲。爲了支持阿里巴巴的業務，阿里雲內部作了不少的改造。經過使用阿里云云原生管控以及雲原生數據庫技術幫助業務實現平滑上雲目標，進而實現資源最大化成本最優化的目標。

2. 將來展望

數據庫上雲會經歷幾個大的階段。最先是物理機階段，以後是存計分離，阿里巴巴在2016年就開始存計分離，以後到如今的MyBase形態。相信以後在多樣性方面會有不少發展，將來不只僅使用MySQL這一種數據庫，還會有不少OLTP的數據庫。最後，數據庫的智能化必定是將來的大趨勢。

做者：stromal
原文連接本文爲阿里雲原創內容，未經容許不得轉載