雲原生數據庫如何打造業務彈性

摘要： 雲計算帶來了業務彈性上的極大優點，阿里雲數據庫高級產品專家時慢從應用架構的變遷，客戶實戰案例，業務分析等方面詳細介紹POLARDB，及如何利用POLARDB設計互聯網創新型應用的數據庫架構。

雲計算帶來了業務彈性上的極大優點，阿里雲數據庫高級產品專家時慢從應用架構的變遷，客戶實戰案例，業務分析等方面詳細介紹POLARDB，及如何利用POLARDB設計互聯網創新型應用的數據庫架構。

應用架構的變遷——爲何咱們須要超級MySQL？
POLARDB跟MySQL是100%兼容的，有超越MySQL不少倍的性能，以及單實例最大100TB的超大存儲空間，能夠理解爲阿里自研的超級MySQL。那麼咱們爲何要打造這樣一款超級MySQL呢？咱們理解這是應用架構進行互聯網分佈式變遷的必然結果。首先咱們須要回顧一下應用架構的變遷的歷史，從最先的CS架構到BS架構，從J2EE到Spring/Struts/Hibernate，再到如今的微服務架構，經歷了不少代的架構轉型。從傳統應用的業務架構到互聯網分佈式的應用架構，在方方面面都發生了變化。從資源層，到數據層，中間件，應用的發佈封裝以及應用的框架，開發運維的角度都在發生了互聯網分佈式變遷。

資源層：傳統應用會使用X86 ，小機以及存儲設備；互聯網分佈式應用在使用公有云，私有云，混合雲等。
數據層：傳統應用會使用Oracle，DB2等集中化的商業數據庫，互聯網應用使用的是MySQL，Redis，HBase這樣的分佈式數據庫，他們不須要集中化的存儲設備。
中間件：傳統應用會使用WebLogic，WebSphere等，互聯網應用在向微服務架構轉型中一般會使用Swarm，K8S，Mesos。
應用發佈封裝：傳統應用會使用JAVA開發併發布成war/ear文件封裝，再發布到中間件。微服務架構一般會將應用發佈成容器的鏡像。
應用框架：傳統應用一般會使用Spring，Struts，hibernate來開發，而目前互聯網分佈式應用更多使用的是SpringCloud, Double, EDAS等微服務架構。
開發運維：傳統應用會使用可控的發佈，保守的運維，新功能上線須要數週，甚至數月時間；互聯網分佈式架構更多使用的是DevOps持續集成，敏捷快速迭代。
咱們理解，互聯網分佈式應用發生這些架構的改變，目標都是使業務更加敏捷，更加具備彈性，能承載來自互聯網的高併發壓力。在創新架構下，業務應用能夠經過微服務的方式隨時進行橫向擴展，但壓力並不會被處理掉，負載會直接透傳到數據層面，解決了應用彈性的問題，反而對數據庫產生了更大的挑戰。互聯網的分佈式架構要求數據庫更加敏捷，擁有更好的彈性以及更低的成本。（傳統應用中，一個應用可能只須要一個數據庫做承載，但在互聯網分佈式應用下，進行了微服務改造以後，一個業務系統可能就須要數十個甚至上百個數據庫去承載，所以對成本也提出了要求。）

實戰——阿里雲數據庫爲業務架構變遷作好準備
目前，阿里雲的數據庫形態已經覆蓋了互聯網中99%的業務場景。關係型數據庫包括有MySQL，SQL Server，PG，POLARDB。NoSQL產品家族包括Redis，MongoDB，HBase等。同時具有混合分析型的數據倉庫，分佈式數據庫DRDS，以及數據庫服務於工具（DTS，DBS，CloudDBA，DMS等）。

演進路線
阿里雲上提供了這麼多的數據庫產品，在實際應用中該如何進行選擇呢？咱們已經爲業務的快速發展和更新迭代作好了準備。這是咱們建議的應用架構的演進路線：在業務的初期，建議選擇MySQL來快速構建業務應用。當成長起來以後，獨立MySQL沒法承載更大業務壓力的時候，能夠基於MySQL作讀寫分離，不須要對應用作任何改造。咱們進入快速成長期，讀寫分離也沒法承載業務需求時，能夠無縫遷移到POLARDB，遷移中不須要對業務系統作任何的更改，並且POLARDB的讀寫分離經過共享存儲消除了複製延遲，更適合對數據一致性有更高要求的場景。當業務進一步發展壯大期間，還能夠在POLARDB上作垂直拆分。垂直拆分是指將業務模塊垂直拆分到不一樣數據庫實例，分到多個獨立數據庫中去，好比分紅用戶庫，訂單庫，倉儲庫等，從而用更多的獨立數據庫聯合來應對業務負載的壓力。當業務發展到象淘寶這麼大的規模和體量，就須要採用DRDS進行分佈式改造、跨機房多活，以及根據業務拆分作單元化改造，這正是阿里淘系應用已經走過並行之有效的演進道路。

應用鏈路的優化——自動讀寫分離，短鏈接優化
咱們使用數據庫代理來進行鏈路訪問層的優化。訪問數據庫的標準模式是直接訪問主實例和只讀實例。在這種模式下須要在業務層面作讀寫分離的邏輯拆分。咱們提供了代理模式，讓業務層和數據庫層徹底解耦。在訪問數據庫時，不須要直接鏈接數據庫實例，而是鏈接對業務徹底透明的Proxy，它接收到SQL請求後會自動化作讀寫分離，把全部寫操做路由到主實例，並把讀操做負載均衡的路由到只讀實例上，從而實現對業務透明的自動化讀寫分離。代理模式除了實現讀寫分離外，還能夠進行故障數據庫的透明切換。不管是標準模式仍是代理模式，當主實例發生故障後，均可以自動切換到備份的實例上，保證數據庫的可用性。但在標準模式中，切換後業務須要進行數據庫重連，但經過Proxy，業務應用不須要重連，感覺不到高可用切換。同時，代理模式還提供了短鏈接優化。舉例來講，若是業務是使用PHP開發，它鏈接數據庫就是採用短連接的方式，在訪問數據庫時每次鏈接都會產生connection，使得數據庫在處理鏈接池上不堪重負。Proxy能夠將短連接轉化成長連接，並自主維護鏈接池。同時，代理模式還提供了防暴力破解的功能。好比Proxy能夠檢測到某個IP不停的嘗試重輸密碼，並主動進行屏蔽。

實時分析數據倉庫——POLARMPP，POLARDB最佳搭檔
數據的處理能夠分紅數據庫生態和大數據生態。數據庫生態適合於處理交易訂單等數據一致性要求強的場景，但在處理能力和處理量級上不會特別大。好比訂單量在1TB、2TB級別時，還可使用，但數量一旦增加到3TB~5TB時，單庫的性能就會出現很是大的瓶頸，此時複雜的分析查詢就會使得數據庫不堪重負。一般的作法是採用大數據生態，經過ETL或數據複製的方式把在線事務處理產生的數據複製到Hadoop生態中進行數據實時分析。在Hadoop 生態中，標準方式是利用MapReduce或Spark來作數據分析，但開發人員並不習慣MR或Spark，也不喜歡使用Scala語言，他們仍是習慣於使用SQL。因此在這種模式下，常常還要給開發人員準備Hive、Impla等類SQL組件，讓研發人員仍然可使用SQL來處理數據。這種方式存在的問題，在於在線事務處理和離線數據倉庫之間有延遲，少則幾秒，多則幾分鐘甚至幾小時。而且數據實際上存了兩份，並不經濟。

針對這種狀況，咱們提供了POLAR MPP和HybridDB來解決，它能夠很好的處理數據的寫入，提供百萬級的TPS，很是適合用於存儲用戶的行爲、標籤、Log日誌等。這種模式能夠對百億級的大表作出毫秒級的響應，對多表關聯作複雜的聚合，作多值的子列，全文檢索。最重要的是，它能夠和POLARDB共用一份數據，極大的緩解了數據庫生態和大數據生態中須要存儲兩份數據，而且讀寫存在延遲的問題。

業務場景分析——互聯網創新型應用場景實踐
有了雲原生數據庫做爲武器，互聯網創新型的業務場景應該如何設計呢？在講到創新型業務前，先看一下傳統的採用MySQL一主N從的架構，如何構建數據倉庫驅動BI報表實現商務智能。這種架構的問題是須要存儲N份數據，作數據的同步複製。MySQL 的主從之間要進行數據複製，從業務庫到分析庫也要進行數據複製。

那麼採用雲原生POLARDB的系統架構應該如何設計呢？這之間，POLARDB和只讀分析庫構成了雲原生的數據集羣，由POLAR Store統一進行數據的共享存儲。業務應用會把在線的業務寫到POLARDB中，當POLARDB一主一從的模式不足以應對時，能夠快速進行擴展，擴展成一主兩從甚至N從。這種擴展區別於MySQL，他提供了敏捷性和業務彈性。若是數據量比較大，MySQL只讀庫的生成可能就須要數個小時的時間。而無論數據量多大，在POLARDB生態下建立一個只讀庫只須要分鐘級的時間。而且只須要一份數據就能夠經過POLARMPP來驅動業務報表。

雲原生架構帶來以下的業務收益：

1. 業務兼容，不改應用：只要是利用MySQL開發的業務系統，能夠1. 無縫遷移到POLARDB上。
2. 讀寫分離：經過POLARDB，一份數據便可實現多個節點的讀寫分離，而且支持分鐘級的擴展。若是用MySQL 實現讀寫分離，須要經過數據複製生成多個只讀庫，浪費時間，浪費空間。
3. 實時分析，數據共享：在數據倉庫和BI分析業務中，也只須要一份數據，不須要進行數據複製。
4. 只讀實例共享一份數據：因爲存儲只須要一份，帶來了更好的性價比，以一主五從的架構爲例，POLARDB的價格要比MySQL低44%。它在提供更強大的性能的基礎上，提供了更高的性價比。
5. 毫秒級的延遲：因爲主庫和從庫共享一份數據，所以中間只存在毫秒級的延遲。當主節點發生故障時，能夠保證切換中的零數據丟失。
6. Session級讀寫分離的數據一致性：在金融等一致性要求高的業務場景下，對讀一致性的要求很是高，很難容忍秒級甚至毫秒級的數據延遲。利用POLARDB能夠實現session內的數據一致性讀。
7. 按需付費，秒級備份：在使用MySQL的時候，若是預計要使用500GB的容量，咱們須要買500G的存儲空間，但實際上數據可能只佔了不到100GB，但仍是須要爲500GB的預留容量買單。但POLARDB不須要作空間預留，存儲按需付費。同時，POLARDB經過數據快照能夠在秒級實現備份和恢復，更利於咱們作數據庫安全運維，帶來更多價值。