【IT技術】阿里RDS首席產品架構師何雲飛：阿里雲資料庫的架構演進之路

專訪阿里RDS首席產品架構師何雲飛：阿里雲資料庫的架構演進之路

如果說淘寶革了零售的命，那麼DT革了企業IT消費的命。在阿里巴巴看來，DT時代，企業IT消費的模式變成了“雲服務+資料”，阿里雲將打造一個像淘寶電商一樣多方共贏的雲生態。而作為阿里雲龐大帝國的重要成員，阿里雲RDS為社交網站、電子商務網站、手機App提供了可靠的資料儲存服務。好的架構不是設計出來的，而是演化出來的，那麼RDS經歷了怎樣的架構演進？本期名人堂我們邀請到了阿里雲RDS首席產品架構師何雲飛（社群ID：Steven1981），為我們揭秘RDS的今世前生。

皮皮（Q1）：您專注於關係型資料庫領域10年了，精通多種主流資料庫，比如MySQL，SQLSERVER，Oracle等，這些主流資料庫是否有相通之處？能否結合您的經歷和我們分享下學習這些資料庫有木有捷徑可走？

      何雲飛（A1）：學習是一個觸類旁通，舉一反三的過程，對我而言，資料庫也同樣如此。一旦你學會了一種資料庫，其它資料庫就能駕輕就熟了。深入學會了資料庫最核心的三個問題，開發、最佳化、管理維護，你就能所向披靡了。

開發階段，我們一般關注的是：

1）如何快速得到一個可用環境，這裡你可以先不考慮一些引數配置，只要資料庫執行起來能讓你訪問就好；

2）如何用SQL去存取你的第一行資料；這裡你可能會關注：

    SQL用法，特別是查詢JOIN的寫法；

資料型別，常用的有字串型別、數值型別、日期型別、文字型別；

運算子，如算術運算子、比較運算子，這裡要特別注意運算子的最佳化級；

常用函式，常用的字串、數值、日期相關以及轉換函式等；

這些一般在資料庫的使用者手冊裡可以找到，常用的你也許需要記錄在你的筆記本里；

一旦你掌握瞭如何熟練使用SQL語言，你可能無法容忍一些執行特別慢的SQL語句，怎麼擰出這些執行緩慢的SQL語句？有木有秘訣來掃除障礙呢？這裡我想和大家分享幾點：

1）檢視執行計劃並找到SQL慢的原因；

2）如何設計合理的索引並讓大部分SQL能夠用到它；

3）選擇什麼樣的欄位型別儲存會更高效；

4）資料庫記憶體等引數配置會讓你的資料庫跑得更快；

透過這個環節的思考，你會在執行過程中總結出一些應用場景標準結構設計和常用SQL寫法，如果看到SQL語句你就知道哪些欄位需要建索引，那就更好了。如果你是高手，你還會研究資料庫多版本的實現，鎖的模式等高階問題。慢慢的，你的資料庫裡儲存了大量的資料，應用也正式上線，一切都很順利，為企業也帶來了很大的價值。這個時候你會覺得資料庫非常的重要。要是資料庫掛了怎麼辦，多長時間恢復是可以接受的，硬碟壞了我該如何恢復等、這一系列問題會接踵而來，所以下一個環節資料庫維護和管理顯得至關重要，搞定以下五大問題，面對資料庫故障問題你就可以從容應對：

1） 如果保證資料不丟失；

2） 資料庫的高可用環境設計與搭建；

3） 資料庫的備份和日誌的管理 ；冷備還是熱備，全量還是增量，備份需要保留多久，備份有效性檢查；

4） 如何快速恢復誤刪的資料；需要做到基於時間點的恢復；

5） 資料庫許可權的管理等；

與其花許多時間和精力去鑿許多淺井，不如花同樣的時間和精力去鑿一口深井。目前業界最容易上手的資料庫當屬開源的MySQL，除了線上手冊，我們前輩也留給大家不少資料，比如：《深入淺出MySQL》，《MySQL技術內幕Innodb儲存引擎》，《高效能MySQL》等；

皮皮（Q2）：您是RDS系統設計和開發的核心創始人之一，為什麼會在2011年開發這套系統？能不能和我們分享下當時的背景？

何雲飛（A2）：2009年9月10日成立阿里雲端計算有限公司，我們是第一批員工，說實話當時每次聽王博士講雲端計算都不太聽得懂，作為DBA的我們不知道該如何去快速擁抱雲時代，冥冥之中真有些雲深不知處的感慨。到了2010年，隨著基礎建設的推進和業務的發展，雲端計算變得勢不可擋，這股強大的力量也曾讓我們這些DBA們憂心忡忡，雲環境裡到底選擇SQL還是NoSQL？未來是否意味著NoSQL當道，關聯式資料庫會日薄西山？ 再加上阿里推出飛天分散式儲存引擎，我們朦朦朧朧的覺得NoSQL將會吞沒關聯式資料庫的光芒，似乎感覺到了我們這些關係型資料庫的DBA在雲端計算公司裡快要失業了；

但後來仔細琢磨了王堅博士經常說的一個觀點，“雲端計算要像水電煤一樣被使用“。單憑NoSQL資料庫在近10年不太可能實現這種美好的境界。NoSQL並非萬能，具體而言，資料模型的選擇、介面規範以及當前面臨的新業務比如移動業務資料的處理問題，都是NoSQL無法迴避的。NoSQL資料庫也不是唯一的適合儲存大量資料或大型資料，顯然，透過良好的分割槽設計，SQL資料庫也可以獲得極好的擴充套件性。

所以，在雲端計算的大環境裡，我不認為NoSQL能夠取代關係型資料庫。關係型資料庫提供了這麼多的功能，有這麼多知道如何使用的專業人士，它還是如此的可靠和安全，因此不是說沒就能沒的。而且雲發展的越快就越需要，因為不是客戶來適應雲，而是雲去解決客戶的問題。於是在2010年年底我們開始著手啟動專案並完成架構設計，於2011年春節回來寫下第一行程式碼；

皮皮（Q3）：從架構的角度，RDS經歷了哪些演進？它有哪些亮點？

何雲飛（A3）：好的架構不是設計出來的，而是演化出來的，RDS也同樣經歷了這樣的演進。運維是雲端計算需要解決的最基礎的問題之一，比如機器硬體壞了，資源升級等這樣的事情應該儘可能地減少對使用者應用的影響。同時還考慮到安全因素，所以我們在鏈路的架構上採用了三層設計：

客戶端 -> 資料閘道器 -> 資料引擎節點

你可以想像得到，資料閘道器就好比是RDS的大動脈，所有請求流量將會經過這裡並返回給應用程式；

在不同的時期資料閘道器面臨不同的挑戰，經歷了三次最佳化演進。

第一代資料閘道器我們採用的是F5網路裝置，能夠滿足我們當時的需求；但隨著業務的發展，相應的問題也出現了；

1）進出流量都需要經過它，吞吐量成為了瓶頸；

2）IP數量有限制；

3）價格貴；

所以我們快速演進到第二代資料閘道器：LVS 負載均衡1.0。

這是章文嵩博士於1998年5月研發的開源專案，完全可以透過PCSERVER來替換昂貴的網路硬體裝置，我們僅僅使用其1：1轉發功能，並且使用DR三角轉發模式，可以讓LVS只接受“入流量”，而“出流量”直接透過資料節點返回給客戶端。這種模式下LVS的吞吐量一般情況下不是瓶頸，但當時的版本有幾個問題：

1）LVS的高可用設計採用主備模式，這意味著，主備DOWN機後，  所有VIP需要在備機重新生效，並且使用者原有的所有連線全部斷開；

2）VIP MAC地址是透過ARP方式廣播出去，當VIP數量超過一定數量以後，由於交換機的處理能力有限會導致：

VIP MAC地址不被上層交換機學習到，這樣這個VIP的失效時間會大大增加，從而導致使用者連不上資料庫，有時候這個時間長達30分鐘，這是不可以接受的！

3）DR模式只支援組內機器在同一個VLAN裡，不能跨機房轉發；

經過了故障以後，我們下定決心改進核心問題：

1）硬體永遠是會壞的， 硬體壞掉如何讓訪問流量不受影響？

2）VIP MAC地址如何快速傳播到整個網路；比如怎樣控制在5秒內；

3）LVS的高可用是否可以做到無狀態？

只要叢集（共3臺）有一臺活著，流量都不會受影響

於是第三代資料閘道器出現：內部程式碼RGW - 由ALIBABA 核心技術保障-網路-王昕溥團隊一起打造；它很好的解決了這幾個問題；

1）它透過OSPFD協議直接與核心路由通訊；可以配置IP公告策略（16位、24位等），所以不會隨著VIP數量線性增長；

2）它利用了等價路由協議自動實現負載均衡，RGW節點本身沒有狀態，所以維護時給使用者的影響幾乎沒有；

3）DNAT 轉發模式可以讓組內節點分佈在不同的機房；這樣RDS天然可以做到同城容災；

4）多個節點的吞吐量可以累加，這表示單個VIP的吞吐量是所有RGW吞吐量的和；

解決了鏈路層的問題，應用層的問題悄悄浮現出來了：部分遊戲客戶使用連線池連線資料庫，但沒有配置重連，這會導致在RDS的資料節點發生故障切換時，應用程式由於沒有重連機制而無法繼續工作。隨著客戶越來越多，這個問題變成了共性問題。於是，我們給使用者一種選擇： 客戶端 -> 4層資料閘道器-> 7層資料閘道器 -> 資料引擎節點。在這裡，7層資料閘道器

將與使用者打交道並建立連線， 同時使用者的請求將由它來轉發到資料節點並返回結果。這樣一來，客戶端的會話不直接與資料節點保持，最重要的是7層資料閘道器有自動重連機制能夠幫助使用者解決問題。

現在RDS可以做到硬體損壞切換，跨機遷移基本對應用透明；但還是要提醒使用者，如果使用資料庫連線池（長連線），儘量要配置“重連”機制，因為我們不能忽略，從客戶端到RDS我們需要經過多層網路裝置；

皮皮（Q4）：阿里雲RDS為社交網站、電子商務網站、手機App提供可靠的資料儲存服務，在雲端叢集上，RDS是如何確保資料不丟失？相應的備份策略是怎樣的？

何雲飛（A4）： 不管是自建資料庫還是雲端，資料的備份永遠是基礎工作；就像一個人要生存下來，離不開基本的衣食住行，而阿里雲的RDS擁有強大的資料備份機制。首先RDS所有的儲存裝置都採用RAID 陣列，這讓你的資料除了有多餘的冗餘外,還保證了資料存取的高效能；其次，RDS可以讓使用者自己配置備份策略，包括備份週期和開始時間；

RDS的備份工作發生在“備庫”上，所以備份過程不會影響“主庫”的使用；RDS產生的備份集將統一儲存到OSS分散式儲存叢集目前可免費儲存7天。由於OSS本身就是多份儲存設計，所以你的例項備份還享受著多份儲存的保障；再有，不管你使用RDS哪個型號的讀寫例項，RDS都在後端有“備庫”實時同步資料，當“主庫”發生故障時，我們將自動快速地（30秒內）進行切換；最近我們也接到一些使用者的需求，想要讓備份儲存更久，1年，2年，甚至10年；這些都是冷資料，RDS打算與阿里雲最近公測的OAS對接，這樣可以讓使用者享受RDS更廉價的備份服務；

皮皮（Q5）：很多使用者都還是在自建資料庫，自建資料庫雖然解決了資料存放的問題，但是一旦被黑，所有資料就沒有了。阿里雲的RDS對於這方面的安全保障有哪些優勢？

何雲飛（A5）：這個問題非常關鍵，也是RDS產品努力的方向。最近我們從安全部門瞭解到，在浩大的網路世界裡，每天被入侵的資料庫數以千計。當然，如果駭客對你沒有深仇大恨，是不會破壞你的資料，一般只是拉走你的資料，但這已經讓你或者公司產生了足夠大的損失。

RDS會盡量讓您避免這方面的損失，有如下安全功能：

1）每個例項可以配置：信任來源IP白名單（100個），你可以決定哪些主機來訪問你的資料庫；

2）在上個問題中提到的7層閘道器，可以實時檢測並攔截SQL隱碼攻擊行為，這些注入規則是阿里巴巴安全團隊多年積累下來的寶貝；

3）RDS提供SQL審計功能，使用者可以檢視某時間點，哪個來源IP，哪個使用者呼叫什麼SQL語句檢視了多少行資料；

4）最壞的情況，當你的資料被破壞，RDS還免費提供“資料恢復到指定時間點”的功能；該功能將開闢新的空間來恢復資料，你要做的只是確認資料是你想要的；

其中，1和2屬於事前防護，

3和4屬於事後審計和補償。此些功能可以配合使用。

皮皮（Q6）：哪些資料庫可以存放到阿里雲關係型資料庫裡，RDS支援哪些SQL查詢語言？阿里雲關係型資料庫RDS怎麼擴容？

何雲飛（A6）：RDS當前相容MySQL和SQLServer，其中MySQL支援5.1，5.5，5.6版本。SQLServer支援2008R2版本。

  彈性是雲端計算最大的特色之一，使用者可根據業務壓力購買需要的資源，當資源不夠時可隨時線上升級。RDS在業務擴容有如下功能：

1）單例項，記憶體從240M - 48000M等7個規格支援線上擴容，磁碟空間最大支援1T；

2）只讀例項，當我們的應用場景需要滿足大量讀請求時，最近釋出的只讀例項是很好的選擇；他可以支援主例項最大5倍的讀請求，並且支援自由升降配置；

3）分散式例項（DRDS），當我們的整體業務（讀寫）壓力都很大時，我們要考慮用分散式方案來解決。DRDS可以讓使用者自由的將多個RDS組裝成一個大的虛擬庫，並且支援資料自動拆分和合並；當前DRDS最大規模可以支援128個節點；

    相信RDS應該可以支撐99%的業務場景。

皮皮（Q7）：在阿里巴巴看來，資訊時代的企業IT消費已走過兩個階段：第一個階段是IT時代，企業IT消費的模式是“計算機+軟體”。第二個階段是DT時代，企業IT消費的模式則是“雲服務+資料”。雲端計算和大資料到底是怎樣的關係？阿里在DT時代會有哪些創新之舉？

何雲飛（A7）： IT時代，資料是應用的結果；在DT時代，應用是資料的展現形式。雲端計算和大資料是一個硬幣的正反面，雲端計算使大資料變得可行。如果說淘寶革了零售的命，那麼可以說DT革了企業IT消費的命，企業可以透過資料為大家創造更加智慧的生活。“資料、平臺和金融”是阿里的三大核心戰略，阿里在DT時代走的依然是大平臺和開放的策略，發揮阿里在資料積累、資料平臺和資料應用三方面的優勢，來推動整個社會的產業革新。