本次分享將主要介紹阿里云是如何設計云數據庫產品的架構的，以及在云數據庫產品的架構設計背后的故事。本次的分享將不會非常深入技術底層細節，而是希望通過分享使得大家了解在使用云數據庫時應該如何去規劃，以及阿里云在設計云數據庫產品的時候存在什么樣的思考。
一、云數據庫的市場背景
多產品類型混合
在市場上面，大家可以看到類型非常多樣的數據庫產品。如果大家今天還是在使用像SQL Server或者MySQL這樣單獨的關系型數據庫，那么可能業務所覆蓋的場景還是比較有限的。而往往在一家中型或者比較大型的公司里面，已經開始用到很多不同的數據庫產品了。
系統架構越發復雜
如上圖所示，通常情況下，在業務剛開始的時候使用的是一個SQL數據庫或者NoSQL數據庫，但是隨著業務慢慢的發展就會用到Key-Value的緩存數據庫，再之后可能就會發展到數據倉庫，同時也可能發展到大數據的系統。
接下來為大家介紹一家公司從小型企業逐步成長為大型企業的過程中的數據庫架構設計的發展步驟以及在運作過程中每個階段的數據庫演化情況。如下圖所示，在初始階段，整個數據庫架構的結構是比較簡單的，圖中僅有3臺服務器，這意味著公司在剛剛開始的時候可能只有幾臺數據庫服務器，它們可能是SQL的系統，也可能是NoSQL的系統。此時DBA以及管理人員不需要去做過多的結構使用分析。然而，在進行管理的過程中，DBA往往會身兼多職，在這個時候的DBA可能在管理數據庫的同時也在做開發以及對于操作系統的運維工作。
更進一步，當企業發展到初具規模的時候，數據庫往往就不能夠以單節點的方式去運行了，此時往往需要配合一些集群以及一些其他的數據庫。例如在剛剛開始的時候，只用到了單獨的SQL數據庫以及NoSQL數據庫，但是在系統初具規模的時候，可能兩方面的數據庫都會用到，同時還可能會用到像Key-Value緩存數據庫等進行混合來實現整體的數據庫業務效果。在這個過程之中，DBA扮演著非常神奇的角色，此時的DBA不只需要去做普通的SQL系統管理，而且還需要管理NoSQL以及Key-Value數據庫，而且很多時候整體系統監控以及系統維護都需要由DBA進行完整地支撐，此時的DBA可以稱之為“神奇的DBA”，因為他什么都需要管。
當業務進一步發展到下一個階段時又會是什么情況呢？其實很多公司在剛剛起步時往往只有一個項目，當公司的業務發展到一定規模的時候，項目也會逐步地增加。因此，每一個項目都將會使用一整套數據庫結構，而在這個時候項目也會不斷地提升和增長，每個項目會使用單獨整體數據庫結構，這時候的數據庫管理員DBA就不再是單個人了，往往會有2到3個DBA，而且他們每個人應該都能夠獨當一面，并且應該具有完整的架構經驗。正是在這個時候才是對于企業的比較大的挑戰，大家都知道在技術人員的職業發展生涯當中，技術人員都是希望能夠承載更多的工作或者讓自己的職業生涯獲得更大的發展，所以在這個過程之中往往能夠形成企業與技術人員本身之間認知差異的博弈。很多時候如果企業發展的速度跟不上技術人員的技術成長速度，技術人員就很可能嘗試跳槽或者尋找其他的工作，當技術專家離開企業的時候，就會使得企業的進一步發展受到阻礙。
數據庫容災：兩地N中心
在系統架構越發復雜的情況下，企業所遇到的不僅是人員的問題，在進行數據庫架構發展演變的過程當中，企業還會遇到另外的一個問題：在業務發展到一定階段之后，往往需要產生更多的數據架構的邏輯，包括在業務要求之下以及在監管部門的要求之下，可能需要實現像兩地三中心等等一系列復雜的架構，這也會使得業務的運行成本成倍地提高。因為在單獨的機房之下進行數據庫集群的搭建會是比較方便的，而在實現像兩地三中心這樣的架構的時候，還需要去購買同城光纖以及異地光纖等等基礎設施，這部分大量的費用也往往使得很多的企業在這樣的位置上處于停步狀態。
如果企業希望能夠進一步地突破發展瓶頸往往還需要使用更多的數據庫架構，例如需要使用到OLAP的數據庫倉庫以及大數據的海量分析等。在這樣的情況下，DBA團隊以及整體系統的構建成本都將會更大地提升。
阿里云 云數據庫：產品理念
前面為大家介紹了一個企業從小型到中型或者說是到達爆發期以及更進一步的上升期的過程之中，對于數據庫可能會出現什么樣的要求。接下來為大家分享在阿里云的云數據庫中希望為大家提供什么樣的產品理念。
首先，大家可以看到在業務各個不同的發展過程當中需要使用到不同的數據庫、數據庫的組合以及不同的數據庫產品的層級，因此阿里云會設計自己的數據庫產品讓不同的層級都可以適用。
第二點，阿里云會盡可能地去幫助企業提高自身的發展效率，也就是讓企業非常方便地擴展自己的資源，讓這些資源為用戶直接提升生產效率。
第三點，阿里云會直接降低整個架構的構建門檻，在傳統企業架構之下，從單個機房變到多個機房或者從單個服務器變為多個服務器的時候，會存在很多技術以及生產成本的門檻限制，阿里云希望能夠通過云數據庫整體的底層架構，包括飛天架構將這些門檻降到最低。
最后要提到的也是本次中最希望分享的一點就是：在云數據庫之上，阿里云所希望達到的終極目標是解放DBA。其實通常情況下在一家公司里面，DBA很多時候往往不會受到很大的重視，因為在企業中DBA日常所做的工作往往是像部署、備份等等一系列運維工作，而這些工作將會占據DBA 50%到60%的時間，而這些工作卻沒有辦法去為企業帶來直接的生產效率。而在云數據庫上面，通過云架構的自動化管理來完成所有的運維工作，DBA可以將自己更多的時間投入到業務架構的優化之中。什么是業務架構的優化呢？比如表結構設計的不合理需要進行優化，一些SQL存在性能問題需要優化，以及某些設計在業務發展的過程中已經不合時宜需要優化，所有的這些優化都是DBA應該去做的。而DBA也是最容易發展成為企業核心架構師的一群人，他們的工作應該更多地為企業真正地產能以及技術能力的輸出發揮貢獻，而不是去過多地關注每一天的部署、備份這樣繁瑣的運維工作。
以上就是在設計云數據庫過程中，大家所看到的市場需求情況以及阿里云的云數據庫產品設計理念。
二、永恒不變的話題：需求
其實前面所講的長篇故事都是需求，每一個需求都需要得到滿足。那么面對這些需求，阿里云的云數據庫是如何一步一步解決的呢？
分層：擴展邊界覆蓋不同層級的用戶
第一步就是進行分層。之前使用過阿里云數據庫的朋友可能會有印象，阿里云最初推出的數據庫版本叫做高可用版本，這應該也是當前阿里云數據庫里面使用量最多的版本。在這個版本里面會有兩個數據庫服務器，一主一備，他們提供了非常好的性能并且能夠快速地進行切換，然而在這樣的架構之下，成本實際上翻了一倍。很多的用戶，特別是入門級別的剛開始使用云數據庫的用戶，往往不需要主備的數據庫系統，而是希望投入更低的成本，這個時候阿里云就推出了云數據庫的基礎版。基礎版的架構只有單個節點，基礎版的推出使得用戶的成本得以降低。同時需要注意的一點就是：在單節點或者說是基礎版之下，高可用到底是如何保障的。其實大家可以放心，在基礎版之下，阿里云同樣提供了高可用的保障，只不過沒有兩個節點的保障而是將整個數據庫運行在飛天架構之上，如果數據庫出現問題或者數據庫所在的主機出現了問題，飛天系統會自動尋找新的主機、新的節點將整個系統運行起來，只不過切換時間會稍微長一些，但是不會出現像系統長期斷開的情況。
再進一步，很多高級用戶，特別是在金融界中的用戶所要求的數據穩定性以及對于數據故障時的RPO都會有更高的要求，這時候阿里云就提供了金融版數據庫。在兩節點的基礎之上可能會擴展到三節點甚至更多節點的集群的應用。在做了這樣的工作之后，阿里云實際上是拓展了云數據庫產品的邊界，從剛開始阿里云數據庫只有高可用雙節點版本，擴展到單節點的基礎版以及多節點的金融版，使得不同需求的用戶可以獲取到他們所需要的各種不同規格的云數據庫服務。
效率：化繁為簡，釋放工作量
在有了數據庫的運行環境之后，其實大家可以看到各個用戶往往都會有自己不同時段的類似于促銷、活動等的一些業務，在這些業務之中，用戶的查詢要求往往是非常高的，會出現非常高的查詢峰值，這時可以通過只讀節點來進行解決。在阿里云中就直接提供了只讀請求的實例，而不需要用戶自己再去搭建只讀實例了。如果大家自己搭建過數據庫，就可能對于這個過程有所體會，當搭建一個只讀實例時往往需要去構建或者配置3到4個配置文件，而且各個主機之間，包括用戶權限以及密碼的同步等都需要進行規劃，這個過程對于初級的DBA而言是比較困難和麻煩的事情，而且與此同時還需要保障整個系統在業務發展的過程中的穩定運行。
在阿里云上面，實際上會將構建只讀實例的過程更加簡化，因為阿里云數據庫本身的底層系統架構會自動化地進行所有的配置以及業務確認，用戶只需要在界面上面點擊按鈕并添加一個只讀實例就能夠將只讀實例建立完成，而且允許用戶建立5個甚至10個只讀實例。在這個過程中，大家會發現雖然阿里云提供了直接添加只讀實例的功能，而且完成了其中的同步，但是業務方也就是如上圖所示的云服務器ECS上面的應用還是需要通過把讀寫請求和只讀請求進行業務分離，這對于數據庫的開發是存在入侵性的，也就是說原來開發的程序只需要一個數據庫進行操作就可以了，而由于當前使用了只讀實例，則需要將所有的只讀查詢都單獨地拎出來讓其去訪問其他節點，這一點對于程序的入侵性可能會是非常大的，這就可能會使得很多的開發者無法直接使用到阿里云的只讀實例了，或者有很多的工作需要重新進行開發。
效率： 化繁為簡，釋放工作量， 直接支持讀寫分離
針對上述的問題，阿里云的數據庫在發展的過程中也會收到用戶的需求和報告，因此阿里云數據庫就進行了進一步的優化。在只讀實例的運行條件之下，阿里云數據庫還進一步地提供了讀寫分離的IP訪問，其主要會在Proxy業務層底下實現所有SQL的收集，并且對于所有的收集到的SQL進行分類，如果發現SQL操作既有讀操作也有寫操作的時候，也就是讀寫操作在同一個事務里面的時候，會將這些操作自動地提交到主節點。而如果當發現事務中所有的操作都是讀操作的時候，Proxy層就會將這些只讀的查詢平均地分配到各個只讀節點。這意味著應用程序不需要改變本身的代碼，阿里云就能夠自動地為用戶實現讀寫分離的工作，而業務方不需要去修改自己的業務代碼。通過這樣查詢的讀寫分離的功能，可以非常好地簡化本身開發以及維護的工作量。
效率：新一代關系型數據庫演進
其實除了上面所說的這些，阿里云數據庫所做的工作還遠沒有結束。如果大家留意了阿里云最近的新聞或者最新的產品動向就會知道，在阿里云數據庫最新的版本中提供了關系型數據庫PolarDB的集群，這款產品預計將在十月份推出，在這款產品上面不單單解決了讀寫分離的問題，也會使用到最新的硬件技術去達到比較好的讀寫資源比。在讀寫分離的業務之下，當主節點有數據寫入的時候，所有的數據需要同步到每一個只讀節點，而在主節點和只讀節點之間或許會存在網絡延遲，這些網絡延遲可能會導致從主節點讀出的數據和從只讀節點讀出的數據出現不一致的情況，而這是需要業務方或者開發人員知曉并通過業務進行保障的。
而在PolarDB中，阿里云嘗試使用了一種新型的架構，通過RDMA網絡會將下層的各個存儲節點進行整合管理，通過分布式Raft協議實現完整的底層集群。這樣所能達到的效果就是當主節點進行數據寫入的過程中，底層的Raft協議的數據集群會把數據自動打散到三個或者以上的存儲節點上面，同時這些數據一旦寫入，在其他的只讀節點上就可以讀到。因此可以看到在這樣的架構之下，減少了多節點之間的數據復制，網絡帶寬的消耗會更低，同時主節點和只讀節點之間網絡數據延遲基本為零，也就是說只要數據寫入了，只讀節點就能夠讀取到，符合ACID的完整原則。所有的數據在存放的時候都不會少于三節點，任何一個節點或者數據模塊出現故障的時候，都不會造成數據丟失。在這樣的架構之下，可以進一步使得數據庫的使用者獲取更高的性價比。
門檻： 綜合系統管理門檻高
以上分享的是在數據庫關系的演進中阿里云提供的一些思考和產品，而下面會分享另外一個問題。如下圖所示，當一個業務發展到比較龐大的數據規模時，存下來的業務數據還需要進行產品的分析，比如當數據量已經存放到兩三年的時候，企業主肯定希望能夠通過這兩三年沉淀的數據來進行業務分析。這個時候，在傳統的架構之下，往往會向如圖中所看到的把數據通過ETL，也就是數據導入到數據倉庫，并在數據倉庫之上再去做OLAP的業務分析。同時由于數據量越來越大，因此也需要通過分布式的數據庫中間件實現一個動作，也就是將整個的數據庫進行分庫分表式的管理。當然，這樣的功能在互聯網圈已經使用的非常多了，但是大家會發現下圖中存在四個藍色的管理標記，這是因為在每個層級當中都需要對于數據庫進行一些單獨的人為操作和人為干預。
簡化分庫分表管理，一份數據實現OLTP+OLAP=HTAP
可以看到在上圖的整個運作流程中，每一個節點上面都需要進行配置和規劃，而這些所有的配置和規劃都需要消耗時間。還有一點就是業務系統是OLTP的系統，所有的在線的業務都在上圖中左側的OLTP系統里面，當需要進行分析的時候并不能直接在業務系統進行分析，因為這會影響業務系統本身的性能，因此需要再進行一次數據的抽取，將數據抽取到OLAP的數據倉庫中，然后再去做查詢。這樣動作使得數據多了冗余，而且所有的數據無法實現所謂的“T+0”的實時分析，在這種情況下，所有的操作以及運維管理會消耗更多的使用資源。因此，在阿里云中也提供了HybridDB for MySQL的架構。通過HybridDB for MySQL架構的數據庫，可以實現將上圖中所看到的整個數據鏈路，包括分布式數據庫中間件以及數據倉庫都整合到一個數據庫中，這個數據庫可以直接實現OLTP的事務操作，同時也接受OLAP的數據分析處理，而且整個系統也是分布式系統。
在這個系統之上最大的好處就是用戶不再需要去分別地管理兩個業務系統：OLTP系統和OLAP系統。與此同時還可以實現計算和存儲的分離操作，如果計算資源不足還可以單獨地增加計算資源使得查詢速度更快。而且整個系統將會直接兼容MySQL的生態，因此用戶不需要過多地修改自己數據庫查詢的業務邏輯，可以直接使用MySQL的客戶端以及各種工具來連接到數據庫上面去進行操作。因此，在HybridDB for MySQL數據庫中實現了一種新的形態叫做HTAP，實際上就是在同一個數據庫里面不僅可以進行OLTP操作，還可以進行OLAP操作，而且其空間可以擴展到超過PB的級別。
釋放：安心原于透明，主動的提醒
阿里云的數據庫產品除了提供了以上的功能以外，為了使得DBA更加省心和安心，絕對離不開的就是對于各種資源的監控以及對于引擎的監控。在這里不做過多的解析，因為在產品上大家可以看到，阿里云已經把自己原來在天貓、淘寶等的各方面的經驗進行了整體的輸出，會提供非常深度的包括TPS、QPS以及緩存命中率等等一系列的監控，而且可以產生直接的圖表。在報警方面，可以通過云監控設置所需要的報警，當水位超過了一定的范圍之后可以直接發送短信、郵件甚至通過電話的告警來提醒DBA進行擴容或者及時地發現問題。更進一步，阿里云還將會提供云DBA的協助工具，甚至還會為用戶提供Index推薦以及像告警錯誤業務分析等服務。
釋放用戶成本：中小企業也可以獲得高端服務
在企業發展的過程中，隨著業務不斷地發展，需要更好地保障業務的連續穩定性。對于很多企業而言，數據庫中心里面往往只有一個IDC的機房，然而如果這個IDC機房出現斷電或者故障的時候，就沒有辦法進行更進一步的業務操作。阿里云在數據庫體系之下已經完成如下圖所示的整體架構。當大家看到阿里云數據庫產品購買頁的時候會發現阿里云不僅提供了單中心的雙節點模型，還在很多地域中提供了多可用區的模型。多可用區模型就是把主節點和備用節點放在一個城市的兩個不同的可用區上，也就是說用戶的實例只購買了一個，但是在部署的時候卻部署在了一個城市的兩個中心，一旦主中心出現整體故障的時候，用戶的業務依然可以通過切換到備用中心繼續提供服務。大家可以想象，如果沒有云架構的支撐，依靠自己搭建多可用區模型的時候，可能會需要非常高的業務成本，這是因為同城之間光纖搭建的費用是非常昂貴的。
除此之外，阿里云還會為企業提供跨數據中心的訪問。很多用戶可能會說現在自己的企業還不大，還不需要到這樣的業務保護，但是在這里想告訴大家的是這樣的觀點往往是不正確的。如上圖所示，當前在同城雙中心災備里面不需要增加用戶的成本，那么就完全可以在企業發展之初就使用這樣的架構，因為在企業發展的過程中，任何一個技術上的故障或者服務的宕機往往會造成后續更大的損失。所以如果能夠提前在不增加過多成本的情況下實現企業同城容災以及跨地域業務，往往能夠對于企業業務的發展提供更大的幫助。在阿里云上，其實基于阿里云本身的技術架構就可以為用戶更好地釋放這部分成本，而用戶不需要自己搭建光纖就可以復用所有現有的網絡，這使得企業在初始階段就可以像大企業一樣使用到所有的數據庫的高端服務。
大家可以看到，在阿里云數據庫業務中比較注重的就是如下圖所示的五點：如何幫助用戶節省成本，如何使數據庫的性能達到更高，如何維護業務的連續性，以及業務擴展能力和數據容災等。而這一切的能力都是通過云托管平臺進行規劃和賦能的。
三、生態的力量
在以上的內容中為大家分享了云數據庫上的產品驅動、阿里云數據庫提供了什么樣的保護以及阿里云數據庫是如何承載用戶需求的。接下來為大家分享數據庫生態的力量。
阿里云MySQL生態體系
當阿里云最初去規劃數據庫產品的時候，首先做的產品就是MySQL，因為在當時MySQL也是使用最為廣泛的數據庫，特別是在互聯網業界。但是在不斷的發展過程中也發現不斷有更多的互聯網業務以及企業客戶會進入到阿里云體系上來，所以阿里云需要有更多的數據庫類型來對這些用戶進行支撐。很多的用戶不僅僅需要使用SQL的數據庫，還會需要做緩存并且需要進行數據分析。在下圖中，大家可以看到阿里云逐步地增加更多的引擎，按照DB-Engines的統計，目前阿里云數據庫已經能夠覆蓋70%的數據庫產品，這也是由市場所決定的。而這些產品中的部分產品已經開始走上了阿里云自研的道路，像之前提到的HybridDB for MySQL以及PolarBD等。當然，除了自研產品之外，阿里云也會兼顧到市場上面其他用戶的需求，也會提供像SQL Server、HBase、MongoDB以及Redis等一系列的數據庫產品，這就是阿里云目前的數據庫產品整體大生態。
當然我們也可以看到另外一個生態模型，舉個例子就是目前很多的用戶都在使用MySQL的數據庫，在MySQL數據庫之下，阿里云會提供多種不同的數據庫形態和模式，讓用戶可以完全沉浸在MySQL整體生態鏈路之中。如下圖左側所示，RDS for MySQL提供了基礎版、高可用版以及金融版，使得用戶可以快速地進行業務的使用，進一步在未來阿里云數據庫將會發布的PolarDB也會率先地支持MySQL的引擎，讓具有幾十TB數據或者上百TB數據的并且想要使用更加穩定的數據庫系統的大型客戶能夠非常好地解決遇到的問題。同時，很多人會認為MySQL上面并不適合去做OLAP業務分析工作，但是如果所有的開發人員都是熟悉MySQL的并且不希望跳出MySQL的框架而且希望去基于MySQL實現業務分析操作，這樣通過HybridDB for MySQL就能夠繼續去承載這樣的業務，而且在這個系統上面還可以同時整合OLTP和OLAP。因此，在數據庫產品的規劃過程之中，阿里云會充分地考慮用戶本身的感情因素，當用戶特別傾向于某一數據庫的時候，阿里云就會針對于這個數據庫做出一系列的產品，使得用戶可以通過統一的技術去完成所有的技術工作，而沒必要將所有的工作分散到不同的數據庫并使用不同的SQL模型進行重新開發。
阿里云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進行整體數據的打通。云上的數據可以通過比較方便的方式加上業務架構的模型開發就可以實現對于所有數據在各個數據產品之間的無縫打通，并實現了整體的數據交換。交換完數據之后就可以讓各個數據系統更大地發揮自己的業務價值。
如今，數據庫其實已經是達到了百花齊放的狀態，目前有非常多的引擎以及不同的業務規劃。而阿里云的云數據庫依舊秉持著這樣的幾點產品理念：阿里云會為用戶提供不同層級的數據庫產品，讓用戶可以實現不同的需求，不同的用戶可以購買到不同價格、可靠性以及性能的數據庫產品。阿里云希望通過云平臺的打通實現用戶數據庫構建的最快速的發展效率，而不希望因為架構的改變或者演變，而去等待幾周甚至一個月的規劃，而希望通過點幾下按鈕就能夠得到新的數據庫或者搭建出新的集群，并與原有的集群進行無縫連接。同時，在成本上面，因為得到了云基礎架構的保證，用戶沒有必要自己去再搭建昂貴的光纖或者機柜等硬件設備，而可以直接去生產實例。用戶所購買的云數據庫其實代表了很多東西，包括軟件、機器、機架以及網絡等，而這一系列的東西阿里云已經搭建好了，用戶可以根據自己的需求直接去購買一個月、兩個月或者一年的使用量級，而沒有必要去一次性地進行成本的支付。最后，阿里云希望通過自動化的部署、管理和監控，釋放DBA的工作量，讓DBA免于去被部署、管理等運維工作所纏繞，讓他們把更多的時間和經歷去投入到為企業進行業務優化，用技術為企業創造更多的核心生產力上面去。
核心關注：拓步ERP系統平臺是覆蓋了眾多的業務領域、行業應用，蘊涵了豐富的ERP管理思想，集成了ERP軟件業務管理理念，功能涉及供應鏈、成本、制造、CRM、HR等眾多業務領域的管理，全面涵蓋了企業關注ERP管理系統的核心領域，是眾多中小企業信息化建設首選的ERP管理軟件信賴品牌。
轉載請注明出處：拓步ERP資訊網http://www.guhuozai8.cn/
本文標題：云數據庫產品及架構設計背后的考量
本文網址：http://www.guhuozai8.cn/html/consultation/10839721028.html
相關文章
