【IT名人堂】何雲飛：阿里雲數據庫的架構演進之路

【IT名人堂】何雲飛：阿里雲數據庫的架構演進之路

原文轉載自：IT168 

​

若是說淘寶革了零售的命，那麼DT革了企業IT消費的命。在阿里巴巴看來，DT時代，企業IT消費的模式變成了「雲服務+數據」，阿里雲將打造一個像淘寶電商同樣多方雙贏的雲生態。而做爲阿里雲龐大帝國的重要成員，阿里雲RDS爲社交網站、電子商務網站、手機App提供了可靠的數據存儲服務。好的架構不是設計出來的，而是演化出來的，那麼RDS經歷了怎樣的架構演進？本期名人堂咱們邀請到了阿里雲RDS首席產品架構師何雲飛，爲咱們揭祕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時代走的依然是大平臺和開放的策略，發揮阿里在數據積累、數據平臺和數據應用三方面的優點，來推進整個社會的產業革新。

 

微博互動地址：http://weibo.com/1644971875/BmXiaE4zY?mod=weibotime 

原文地址：http://www.itpub.net/thread-1887486-1-1.html