125
雲數據庫產品及架構設計背後的考量
摘要：8月24日，阿裏雲數據庫技術峰會到來，本次技術峰會邀請到了阿裏集團和阿裏雲數據庫老司機們，為大家分享了一線數據庫實踐經驗和技術幹貨。在本次峰會上，阿裏雲數據庫高級產品專家蕭少聰（鐵庵）介紹了全體係阿裏雲數據庫產品並對於阿裏雲數據庫產品的實現架構進行了分享，幫助大家了解了阿裏雲全數據庫產品體係能解決哪些實用場景的問題，同時幫助大家了解其解決的原理。以下內容根據演講嘉賓現場視頻以及PPT整理而成。
本次分享將主要介紹阿裏雲是如何設計雲數據庫產品的架構的，以及在雲數據庫產品的架構設計背後的故事。本次的分享將不會非常深入技術底層細節，而是希望通過分享使得大家了解在使用雲數據庫時應該如何去規劃，以及阿裏雲在設計雲數據庫產品的時候存在什麼樣的思考。
一、雲數據庫的市場背景
多產品類型混合
在市場上麵，大家可以看到類型非常多樣的數據庫產品。如果大家今天還是在使用像SQL Server或者MySQL這樣單獨的關係型數據庫，那麼可能業務所覆蓋的場景還是比較有限的。而往往在一家中型或者比較大型的公司裏麵，已經開始用到很多不同的數據庫產品了。
係統架構越發複雜
如上圖所示，通常情況下，在業務剛開始的時候使用的是一個SQL數據庫或者NoSQL數據庫，但是隨著業務慢慢的發展就會用到Key-Value的緩存數據庫，再之後可能就會發展到數據倉庫，同時也可能發展到大數據的係統。
接下來為大家介紹一家公司從小型企業逐步成長為大型企業的過程中的數據庫架構設計的發展步驟以及在運作過程中每個階段的數據庫演化情況。如下圖所示，在初始階段，整個數據庫架構的結構是比較簡單的，圖中僅有3台服務器，這意味著公司在剛剛開始的時候可能隻有幾台數據庫服務器，它們可能是SQL的係統，也可能是NoSQL的係統。此時DBA以及管理人員不需要去做過多的結構使用分析。然而，在進行管理的過程中，DBA往往會身兼多職，在這個時候的DBA可能在管理數據庫的同時也在做開發以及對於操作係統的運維工作。
數據庫容災：兩地N中心
在係統架構越發複雜的情況下，企業所遇到的不僅是人員的問題，在進行數據庫架構發展演變的過程當中，企業還會遇到另外的一個問題：在業務發展到一定階段之後，往往需要產生更多的數據架構的邏輯，包括在業務要求之下以及在監管部門的要求之下，可能需要實現像兩地三中心等等一係列複雜的架構，這也會使得業務的運行成本成倍地提高。因為在單獨的機房之下進行數據庫集群的搭建會是比較方便的，而在實現像兩地三中心這樣的架構的時候，還需要去購買同城光纖以及異地光纖等等基礎設施，這部分大量的費用也往往使得很多的企業在這樣的位置上處於停步狀態。
阿裏雲 雲數據庫：產品理念
前麵為大家介紹了一個企業從小型到中型或者說是到達爆發期以及更進一步的上升期的過程之中，對於數據庫可能會出現什麼樣的要求。接下來為大家分享在阿裏雲的雲數據庫中希望為大家提供什麼樣的產品理念。
- 首先，大家可以看到在業務各個不同的發展過程當中需要使用到不同的數據庫、數據庫的組合以及不同的數據庫產品的層級，因此阿裏雲會設計自己的數據庫產品讓不同的層級都可以適用。
- 第二點，阿裏雲會盡可能地去幫助企業提高自身的發展效率，也就是讓企業非常方便地擴展自己的資源，讓這些資源為用戶直接提升生產效率。
- 第三點，阿裏雲會直接降低整個架構的構建門檻，在傳統企業架構之下，從單個機房變到多個機房或者從單個服務器變為多個服務器的時候，會存在很多技術以及生產成本的門檻限製，阿裏雲希望能夠通過雲數據庫整體的底層架構，包括飛天架構將這些門檻降到最低。
- 最後要提到的也是本次中最希望分享的一點就是：在雲數據庫之上，阿裏雲所希望達到的終極目標是解放DBA。其實通常情況下在一家公司裏麵，DBA很多時候往往不會受到很大的重視，因為在企業中DBA日常所做的工作往往是像部署、備份等等一係列運維工作，而這些工作將會占據DBA 50%到60%的時間，而這些工作卻沒有辦法去為企業帶來直接的生產效率。而在雲數據庫上麵，通過雲架構的自動化管理來完成所有的運維工作，DBA可以將自己更多的時間投入到業務架構的優化之中。什麼是業務架構的優化呢？比如表結構設計的不合理需要進行優化，一些SQL存在性能問題需要優化，以及某些設計在業務發展的過程中已經不合時宜需要優化，所有的這些優化都是DBA應該去做的。而DBA也是最容易發展成為企業核心架構師的一群人，他們的工作應該更多地為企業真正地產能以及技術能力的輸出發揮貢獻，而不是去過多地關注每一天的部署、備份這樣繁瑣的運維工作。
二、永恒不變的話題：需求
其實前麵所講的長篇故事都是需求，每一個需求都需要得到滿足。那麼麵對這些需求，阿裏雲的雲數據庫是如何一步一步解決的呢？
分層：擴展邊界覆蓋不同層級的用戶
第一步就是進行分層。之前使用過阿裏雲數據庫的朋友可能會有印象，阿裏雲最初推出的數據庫版本叫做高可用版本，這應該也是當前阿裏雲數據庫裏麵使用量最多的版本。在這個版本裏麵會有兩個數據庫服務器，一主一備，他們提供了非常好的性能並且能夠快速地進行切換，然而在這樣的架構之下，成本實際上翻了一倍。很多的用戶，特別是入門級別的剛開始使用雲數據庫的用戶，往往不需要主備的數據庫係統，而是希望投入更低的成本，這個時候阿裏雲就推出了雲數據庫的基礎版。基礎版的架構隻有單個節點，基礎版的推出使得用戶的成本得以降低。同時需要注意的一點就是：在單節點或者說是基礎版之下，高可用到底是如何保障的。其實大家可以放心，在基礎版之下，阿裏雲同樣提供了高可用的保障，隻不過沒有兩個節點的保障而是將整個數據庫運行在飛天架構之上，如果數據庫出現問題或者數據庫所在的主機出現了問題，飛天係統會自動尋找新的主機、新的節點將整個係統運行起來，隻不過切換時間會稍微長一些，但是不會出現像係統長期斷開的情況。
效率：化繁為簡，釋放工作量
在有了數據庫的運行環境之後，其實大家可以看到各個用戶往往都會有自己不同時段的類似於促銷、活動等的一些業務，在這些業務之中，用戶的查詢要求往往是非常高的，會出現非常高的查詢峰值，這時可以通過隻讀節點來進行解決。在阿裏雲中就直接提供了隻讀請求的實例，而不需要用戶自己再去搭建隻讀實例了。如果大家自己搭建過數據庫，就可能對於這個過程有所體會，當搭建一個隻讀實例時往往需要去構建或者配置3到4個配置文件，而且各個主機之間，包括用戶權限以及密碼的同步等都需要進行規劃，這個過程對於初級的DBA而言是比較困難和麻煩的事情，而且與此同時還需要保障整個係統在業務發展的過程中的穩定運行。
效率： 化繁為簡，釋放工作量， 直接支持讀寫分離
針對上述的問題，阿裏雲的數據庫在發展的過程中也會收到用戶的需求和報告，因此阿裏雲數據庫就進行了進一步的優化。在隻讀實例的運行條件之下，阿裏雲數據庫還進一步地提供了讀寫分離的IP訪問，其主要會在Proxy業務層底下實現所有SQL的收集，並且對於所有的收集到的SQL進行分類，如果發現SQL操作既有讀操作也有寫操作的時候，也就是讀寫操作在同一個事務裏麵的時候，會將這些操作自動地提交到主節點。而如果當發現事務中所有的操作都是讀操作的時候，Proxy層就會將這些隻讀的查詢平均地分配到各個隻讀節點。這意味著應用程序不需要改變本身的代碼，阿裏雲就能夠自動地為用戶實現讀寫分離的工作，而業務方不需要去修改自己的業務代碼。通過這樣查詢的讀寫分離的功能，可以非常好地簡化本身開發以及維護的工作量。
其實除了上麵所說的這些，阿裏雲數據庫所做的工作還遠沒有結束。如果大家留意了阿裏雲最近的新聞或者最新的產品動向就會知道，在阿裏雲數據庫最新的版本中提供了關係型數據庫PolarDB的集群，這款產品預計將在十月份推出，在這款產品上麵不單單解決了讀寫分離的問題，也會使用到最新的硬件技術去達到比較好的讀寫資源比。在讀寫分離的業務之下，當主節點有數據寫入的時候，所有的數據需要同步到每一個隻讀節點，而在主節點和隻讀節點之間或許會存在網絡延遲，這些網絡延遲可能會導致從主節點讀出的數據和從隻讀節點讀出的數據出現不一致的情況，而這是需要業務方或者開發人員知曉並通過業務進行保障的。
門檻： 綜合係統管理門檻高
以上分享的是在數據庫關係的演進中阿裏雲提供的一些思考和產品，而下麵會分享另外一個問題。如下圖所示，當一個業務發展到比較龐大的數據規模時，存下來的業務數據還需要進行產品的分析，比如當數據量已經存放到兩三年的時候，企業主肯定希望能夠通過這兩三年沉澱的數據來進行業務分析。這個時候，在傳統的架構之下，往往會向如圖中所看到的把數據通過ETL，也就是數據導入到數據倉庫，並在數據倉庫之上再去做OLAP的業務分析。同時由於數據量越來越大，因此也需要通過分布式的數據庫中間件實現一個動作，也就是將整個的數據庫進行分庫分表式的管理。當然，這樣的功能在互聯網圈已經使用的非常多了，但是大家會發現下圖中存在四個藍色的管理標記，這是因為在每個層級當中都需要對於數據庫進行一些單獨的人為操作和人為幹預。
簡化分庫分表管理，一份數據實現OLTP+OLAP=HTAP
可以看到在上圖的整個運作流程中，每一個節點上麵都需要進行配置和規劃，而這些所有的配置和規劃都需要消耗時間。還有一點就是業務係統是OLTP的係統，所有的在線的業務都在上圖中左側的OLTP係統裏麵，當需要進行分析的時候並不能直接在業務係統進行分析，因為這會影響業務係統本身的性能，因此需要再進行一次數據的抽取，將數據抽取到OLAP的數據倉庫中，然後再去做查詢。這樣動作使得數據多了冗餘，而且所有的數據無法實現所謂的“T+0”的實時分析，在這種情況下，所有的操作以及運維管理會消耗更多的使用資源。因此，在阿裏雲中也提供了HybridDB for MySQL的架構。通過HybridDB for MySQL架構的數據庫，可以實現將上圖中所看到的整個數據鏈路，包括分布式數據庫中間件以及數據倉庫都整合到一個數據庫中，這個數據庫可以直接實現OLTP的事務操作，同時也接受OLAP的數據分析處理，而且整個係統也是分布式係統。
釋放：安心原於透明，主動的提醒
阿裏雲的數據庫產品除了提供了以上的功能以外，為了使得DBA更加省心和安心，絕對離不開的就是對於各種資源的監控以及對於引擎的監控。在這裏不做過多的解析，因為在產品上大家可以看到，阿裏雲已經把自己原來在天貓、淘寶等的各方麵的經驗進行了整體的輸出，會提供非常深度的包括TPS、QPS以及緩存命中率等等一係列的監控，而且可以產生直接的圖表。在報警方麵，可以通過雲監控設置所需要的報警，當水位超過了一定的範圍之後可以直接發送短信、郵件甚至通過電話的告警來提醒DBA進行擴容或者及時地發現問題。更進一步，阿裏雲還將會提供雲DBA的協助工具，甚至還會為用戶提供Index推薦以及像告警錯誤業務分析等服務。
釋放用戶成本：中小企業也可以獲得高端服務
在企業發展的過程中，隨著業務不斷地發展，需要更好地保障業務的連續穩定性。對於很多企業而言，數據庫中心裏麵往往隻有一個IDC的機房，然而如果這個IDC機房出現斷電或者故障的時候，就沒有辦法進行更進一步的業務操作。阿裏雲在數據庫體係之下已經完成如下圖所示的整體架構。當大家看到阿裏雲數據庫產品購買頁的時候會發現阿裏雲不僅提供了單中心的雙節點模型，還在很多地域中提供了多可用區的模型。多可用區模型就是把主節點和備用節點放在一個城市的兩個不同的可用區上，也就是說用戶的實例隻購買了一個，但是在部署的時候卻部署在了一個城市的兩個中心，一旦主中心出現整體故障的時候，用戶的業務依然可以通過切換到備用中心繼續提供服務。大家可以想象，如果沒有雲架構的支撐，依靠自己搭建多可用區模型的時候，可能會需要非常高的業務成本，這是因為同城之間光纖搭建的費用是非常昂貴的。
大家可以看到，在阿裏雲數據庫業務中比較注重的就是如下圖所示的五點：如何幫助用戶節省成本，如何使數據庫的性能達到更高，如何維護業務的連續性，以及業務擴展能力和數據容災等。而這一切的能力都是通過雲托管平台進行規劃和賦能的。
三、生態的力量
在以上的內容中為大家分享了雲數據庫上的產品驅動、阿裏雲數據庫提供了什麼樣的保護以及阿裏雲數據庫是如何承載用戶需求的。接下來為大家分享數據庫生態的力量。
阿裏雲MySQL生態體係
當阿裏雲最初去規劃數據庫產品的時候，首先做的產品就是MySQL，因為在當時MySQL也是使用最為廣泛的數據庫，特別是在互聯網業界。但是在不斷的發展過程中也發現不斷有更多的互聯網業務以及企業客戶會進入到阿裏雲體係上來，所以阿裏雲需要有更多的數據庫類型來對這些用戶進行支撐。很多的用戶不僅僅需要使用SQL的數據庫，還會需要做緩存並且需要進行數據分析。在下圖中，大家可以看到阿裏雲逐步地增加更多的引擎，按照DB-Engines的統計，目前阿裏雲數據庫已經能夠覆蓋70%的數據庫產品，這也是由市場所決定的。而這些產品中的部分產品已經開始走上了阿裏雲自研的道路，像之前提到的HybridDB for MySQL以及PolarBD等。當然，除了自研產品之外，阿裏雲也會兼顧到市場上麵其他用戶的需求，也會提供像SQL Server、HBase、MongoDB以及Redis等一係列的數據庫產品，這就是阿裏雲目前的數據庫產品整體大生態。
阿裏雲PostgreSQL生態係統
除了MySQL生態之外，近年PostgreSQL生態係統也是非常火熱的，阿裏雲數據庫團隊在PostgreSQL生態上也沿用了和MySQL生態中相同的思路。阿裏雲不隻是為用戶提供一個單獨的RDS for PostgreSQL的係統，因為PostgreSQL和Oracle比較相似，所以還會針對基於PostgreSQL的增強版本——RDS for PPS來協助Oracle用戶來進行數據遷移。同時阿裏雲也會推出針對於數據倉庫的HybridDB for PostgreSQL來實現數據分析。而且所有的這些體係都可以通過外部表的形式去操作OSS，甚至在OSS上麵放一份數據，各個不同的OLTP、OLAP數據庫產品都可以對於OSS上的數據進行讀寫操作和分析應用來實現整體生態鏈的運行過程。
四、SQL+NoSQL+Big Data一站式解決數據打通
除了上述提到的阿裏雲為拆分的MySQL和PostgreSQL生態鏈打造的獨特的方案之外，阿裏雲數據庫還會與阿裏雲的各種數據鏈路的軟件進行整合規劃。在下麵這張圖中，大家可以看到，通過阿裏雲的DTS以及CDP這樣數據工具，可以將前端的Key-Value的緩存層、OLTP、NoSQL、分析以及Big Data進行整體數據的打通。雲上的數據可以通過比較方便的方式加上業務架構的模型開發就可以實現對於所有數據在各個數據產品之間的無縫打通，並實現了整體的數據交換。交換完數據之後就可以讓各個數據係統更大地發揮自己的業務價值。
最後更新：2017-09-02 01:33:31