云計算帶來了業(yè)務(wù)彈性上的極大優(yōu)勢，阿里云數(shù)據(jù)庫高級產(chǎn)品專家時慢從應(yīng)用架構(gòu)的變遷，客戶實戰(zhàn)案例，業(yè)務(wù)分析等方面詳細介紹POLARDB，及如何利用POLARDB設(shè)計互聯(lián)網(wǎng)創(chuàng)新型應(yīng)用的數(shù)據(jù)庫架構(gòu)。

?

應(yīng)用架構(gòu)的變遷——為什么我們需要超級MySQL？

POLARDB跟MySQL是100%兼容的，有超越MySQL很多倍的性能，以及單實例最大100TB的超大存儲空間，可以理解為阿里自研的超級MySQL。那么我們?yōu)槭裁匆蛟爝@樣一款超級MySQL呢？我們理解這是應(yīng)用架構(gòu)進行互聯(lián)網(wǎng)分布式變遷的必然結(jié)果。首先我們需要回顧一下應(yīng)用架構(gòu)的變遷的歷史，從最早的CS架構(gòu)到BS架構(gòu)，從J2EE到Spring/Struts/Hibernate，再到現(xiàn)在的微服務(wù)架構(gòu)，經(jīng)歷了很多代的架構(gòu)轉(zhuǎn)型。從傳統(tǒng)應(yīng)用的業(yè)務(wù)架構(gòu)到互聯(lián)網(wǎng)分布式的應(yīng)用架構(gòu)，在方方面面都發(fā)生了變化。從資源層，到數(shù)據(jù)層，中間件，應(yīng)用的發(fā)布封裝以及應(yīng)用的框架，開發(fā)運維的角度都在發(fā)生了互聯(lián)網(wǎng)分布式變遷。

?

• 資源層：傳統(tǒng)應(yīng)用會使用X86 ，小機以及存儲設(shè)備；互聯(lián)網(wǎng)分布式應(yīng)用在使用公有云，私有云，混合云等。
• 數(shù)據(jù)層：傳統(tǒng)應(yīng)用會使用Oracle，DB2等集中化的商業(yè)數(shù)據(jù)庫，互聯(lián)網(wǎng)應(yīng)用使用的是MySQL，Redis，HBase這樣的分布式數(shù)據(jù)庫，他們不需要集中化的存儲設(shè)備。
• 中間件：傳統(tǒng)應(yīng)用會使用WebLogic，WebSphere等，互聯(lián)網(wǎng)應(yīng)用在向微服務(wù)架構(gòu)轉(zhuǎn)型中通常會使用Swarm，K8S，Mesos。
• 應(yīng)用發(fā)布封裝：傳統(tǒng)應(yīng)用會使用JAVA開發(fā)并發(fā)布成war/ear文件封裝，再發(fā)布到中間件。微服務(wù)架構(gòu)通常會將應(yīng)用發(fā)布成容器的鏡像。
• 應(yīng)用框架：傳統(tǒng)應(yīng)用通常會使用Spring，Struts，hibernate來開發(fā)，而目前互聯(lián)網(wǎng)分布式應(yīng)用更多使用的是SpringCloud, Double, EDAS等微服務(wù)架構(gòu)。
• 開發(fā)運維：傳統(tǒng)應(yīng)用會使用可控的發(fā)布，保守的運維，新功能上線需要數(shù)周，甚至數(shù)月時間；互聯(lián)網(wǎng)分布式架構(gòu)更多使用的是DevOps持續(xù)集成，敏捷快速迭代。

我們理解，互聯(lián)網(wǎng)分布式應(yīng)用發(fā)生這些架構(gòu)的改變，目標都是使業(yè)務(wù)更加敏捷，更加具有彈性，能承載來自互聯(lián)網(wǎng)的高并發(fā)壓力。在創(chuàng)新架構(gòu)下，業(yè)務(wù)應(yīng)用可以通過微服務(wù)的方式隨時進行橫向擴展，但壓力并不會被處理掉，負載會直接透傳到數(shù)據(jù)層面，解決了應(yīng)用彈性的問題，反而對數(shù)據(jù)庫產(chǎn)生了更大的挑戰(zhàn)。互聯(lián)網(wǎng)的分布式架構(gòu)要求數(shù)據(jù)庫更加敏捷，擁有更好的彈性以及更低的成本。（傳統(tǒng)應(yīng)用中，一個應(yīng)用可能只需要一個數(shù)據(jù)庫作承載，但在互聯(lián)網(wǎng)分布式應(yīng)用下，進行了微服務(wù)改造之后，一個業(yè)務(wù)系統(tǒng)可能就需要數(shù)十個甚至上百個數(shù)據(jù)庫去承載，因此對成本也提出了要求。）

實戰(zhàn)——阿里云數(shù)據(jù)庫為業(yè)務(wù)架構(gòu)變遷做好準備

目前，阿里云的數(shù)據(jù)庫形態(tài)已經(jīng)覆蓋了互聯(lián)網(wǎng)中99%的業(yè)務(wù)場景。關(guān)系型數(shù)據(jù)庫包括有MySQL，SQL Server，PG，POLARDB。NoSQL產(chǎn)品家族包括Redis，MongoDB，HBase等。同時具備混合分析型的數(shù)據(jù)倉庫，分布式數(shù)據(jù)庫DRDS，以及數(shù)據(jù)庫服務(wù)于工具（DTS，DBS，CloudDBA，DMS等）。

演進路線

阿里云上提供了這么多的數(shù)據(jù)庫產(chǎn)品，在實際應(yīng)用中該如何進行選擇呢？我們已經(jīng)為業(yè)務(wù)的快速發(fā)展和更新迭代做好了準備。這是我們建議的應(yīng)用架構(gòu)的演進路線：在業(yè)務(wù)的初期，建議選擇MySQL來快速構(gòu)建業(yè)務(wù)應(yīng)用。當成長起來之后，獨立MySQL無法承載更大業(yè)務(wù)壓力的時候，可以基于MySQL做讀寫分離，不需要對應(yīng)用做任何改造。我們進入快速成長期，讀寫分離也無法承載業(yè)務(wù)需求時，可以無縫遷移到POLARDB，遷移中不需要對業(yè)務(wù)系統(tǒng)做任何的更改，而且POLARDB的讀寫分離通過共享存儲消除了復(fù)制延遲，更適合對數(shù)據(jù)一致性有更高要求的場景。當業(yè)務(wù)進一步發(fā)展壯大期間，還可以在POLARDB上做垂直拆分。垂直拆分是指將業(yè)務(wù)模塊垂直拆分到不同數(shù)據(jù)庫實例，分到多個獨立數(shù)據(jù)庫中去，比如分成用戶庫，訂單庫，倉儲庫等，從而用更多的獨立數(shù)據(jù)庫聯(lián)合來應(yīng)對業(yè)務(wù)負載的壓力。當業(yè)務(wù)發(fā)展到象淘寶這么大的規(guī)模和體量，就需要采用DRDS進行分布式改造、跨機房多活，以及根據(jù)業(yè)務(wù)拆分做單元化改造，這正是阿里淘系應(yīng)用已經(jīng)走過并行之有效的演進道路。

應(yīng)用鏈路的優(yōu)化——自動讀寫分離，短連接優(yōu)化

我們使用數(shù)據(jù)庫代理來進行鏈路訪問層的優(yōu)化。訪問數(shù)據(jù)庫的標準模式是直接訪問主實例和只讀實例。在這種模式下需要在業(yè)務(wù)層面做讀寫分離的邏輯拆分。我們提供了代理模式，讓業(yè)務(wù)層和數(shù)據(jù)庫層完全解耦。在訪問數(shù)據(jù)庫時，不需要直接連接數(shù)據(jù)庫實例，而是連接對業(yè)務(wù)完全透明的Proxy，它接收到SQL請求后會自動化做讀寫分離，把所有寫操作路由到主實例，并把讀操作負載均衡的路由到只讀實例上，從而實現(xiàn)對業(yè)務(wù)透明的自動化讀寫分離。代理模式除了實現(xiàn)讀寫分離外，還可以進行故障數(shù)據(jù)庫的透明切換。不論是標準模式還是代理模式，當主實例發(fā)生故障后，都可以自動切換到備份的實例上，保證數(shù)據(jù)庫的可用性。但在標準模式中，切換后業(yè)務(wù)需要進行數(shù)據(jù)庫重連，但通過Proxy，業(yè)務(wù)應(yīng)用不需要重連，感受不到高可用切換。同時，代理模式還提供了短連接優(yōu)化。舉例來說，如果業(yè)務(wù)是使用PHP開發(fā)，它連接數(shù)據(jù)庫就是采用短鏈接的方式，在訪問數(shù)據(jù)庫時每次連接都會產(chǎn)生connection，使得數(shù)據(jù)庫在處理連接池上不堪重負。Proxy可以將短鏈接轉(zhuǎn)化成長鏈接，并自主維護連接池。同時，代理模式還提供了防暴力破解的功能。比如Proxy可以檢測到某個IP不停的嘗試重輸密碼，并主動進行屏蔽。

實時分析數(shù)據(jù)倉庫——POLARMPP，POLARDB最佳搭檔

數(shù)據(jù)的處理可以分成數(shù)據(jù)庫生態(tài)和大數(shù)據(jù)生態(tài)。數(shù)據(jù)庫生態(tài)適合于處理交易訂單等數(shù)據(jù)一致性要求強的場景，但在處理能力和處理量級上不會特別大。比如訂單量在1TB、2TB級別時，還可以使用，但數(shù)量一旦增長到3TB~5TB時，單庫的性能就會出現(xiàn)非常大的瓶頸，此時復(fù)雜的分析查詢就會使得數(shù)據(jù)庫不堪重負。通常的做法是采用大數(shù)據(jù)生態(tài)，通過ETL或數(shù)據(jù)復(fù)制的方式把在線事務(wù)處理產(chǎn)生的數(shù)據(jù)復(fù)制到Hadoop生態(tài)中進行數(shù)據(jù)實時分析。在Hadoop 生態(tài)中，標準方式是利用MapReduce或Spark來做數(shù)據(jù)分析，但開發(fā)人員并不習(xí)慣MR或Spark，也不喜歡使用Scala語言，他們還是習(xí)慣于使用SQL。所以在這種模式下，經(jīng)常還要給開發(fā)人員準備Hive、Impla等類SQL組件，讓研發(fā)人員仍然可以使用SQL來處理數(shù)據(jù)。這種方式存在的問題，在于在線事務(wù)處理和離線數(shù)據(jù)倉庫之間有延遲，少則幾秒，多則幾分鐘甚至幾小時。并且數(shù)據(jù)實際上存了兩份，并不經(jīng)濟。

針對這種情況，我們提供了POLAR MPP和HybridDB來解決，它可以很好的處理數(shù)據(jù)的寫入，提供百萬級的TPS，非常適合用于存儲用戶的行為、標簽、Log日志等。這種模式可以對百億級的大表做出毫秒級的響應(yīng)，對多表關(guān)聯(lián)做復(fù)雜的聚合，做多值的子列，全文檢索。最重要的是，它可以和POLARDB共用一份數(shù)據(jù)，極大的緩解了數(shù)據(jù)庫生態(tài)和大數(shù)據(jù)生態(tài)中需要存儲兩份數(shù)據(jù)，并且讀寫存在延遲的問題。

業(yè)務(wù)場景分析——互聯(lián)網(wǎng)創(chuàng)新型應(yīng)用場景實踐

有了云原生數(shù)據(jù)庫作為武器，互聯(lián)網(wǎng)創(chuàng)新型的業(yè)務(wù)場景應(yīng)該如何設(shè)計呢？在講到創(chuàng)新型業(yè)務(wù)前，先看一下傳統(tǒng)的采用MySQL一主N從的架構(gòu)，如何構(gòu)建數(shù)據(jù)倉庫驅(qū)動BI報表實現(xiàn)商務(wù)智能。這種架構(gòu)的問題是需要存儲N份數(shù)據(jù)，做數(shù)據(jù)的同步復(fù)制。MySQL 的主從之間要進行數(shù)據(jù)復(fù)制，從業(yè)務(wù)庫到分析庫也要進行數(shù)據(jù)復(fù)制。

那么采用云原生POLARDB的系統(tǒng)架構(gòu)應(yīng)該如何設(shè)計呢？這之間，POLARDB和只讀分析庫構(gòu)成了云原生的數(shù)據(jù)集群，由POLAR Store統(tǒng)一進行數(shù)據(jù)的共享存儲。業(yè)務(wù)應(yīng)用會把在線的業(yè)務(wù)寫到POLARDB中，當POLARDB一主一從的模式不足以應(yīng)對時，可以快速進行擴展，擴展成一主兩從甚至N從。這種擴展區(qū)別于MySQL，他提供了敏捷性和業(yè)務(wù)彈性。如果數(shù)據(jù)量比較大，MySQL只讀庫的生成可能就需要數(shù)個小時的時間。而不管數(shù)據(jù)量多大，在POLARDB生態(tài)下創(chuàng)建一個只讀庫只需要分鐘級的時間。并且只需要一份數(shù)據(jù)就可以通過POLARMPP來驅(qū)動業(yè)務(wù)報表。

云原生架構(gòu)帶來如下的業(yè)務(wù)收益：
1. 業(yè)務(wù)兼容，不改應(yīng)用：只要是利用MySQL開發(fā)的業(yè)務(wù)系統(tǒng)，可以1. 無縫遷移到POLARDB上。
2. 讀寫分離：通過POLARDB，一份數(shù)據(jù)即可實現(xiàn)多個節(jié)點的讀寫分離，并且支持分鐘級的擴展。如果用MySQL 實現(xiàn)讀寫分離，需要通過數(shù)據(jù)復(fù)制生成多個只讀庫，浪費時間，浪費空間。
3. 實時分析，數(shù)據(jù)共享：在數(shù)據(jù)倉庫和BI分析業(yè)務(wù)中，也只需要一份數(shù)據(jù)，不需要進行數(shù)據(jù)復(fù)制。
4. 只讀實例共享一份數(shù)據(jù)：由于存儲只需要一份，帶來了更好的性價比，以一主五從的架構(gòu)為例，POLARDB的價格要比MySQL低44%。它在提供更強大的性能的基礎(chǔ)上，提供了更高的性價比。
5. 毫秒級的延遲：由于主庫和從庫共享一份數(shù)據(jù)，因此中間只存在毫秒級的延遲。當主節(jié)點發(fā)生故障時，可以保證切換中的零數(shù)據(jù)丟失。
6. Session級讀寫分離的數(shù)據(jù)一致性：在金融等一致性要求高的業(yè)務(wù)場景下，對讀一致性的要求非常高，很難容忍秒級甚至毫秒級的數(shù)據(jù)延遲。利用POLARDB可以實現(xiàn)session內(nèi)的數(shù)據(jù)一致性讀。
7. 按需付費，秒級備份：在使用MySQL的時候，如果預(yù)計要使用500GB的容量，我們需要買500G的存儲空間，但實際上數(shù)據(jù)可能只占了不到100GB，但還是需要為500GB的預(yù)留容量買單。但POLARDB不需要做空間預(yù)留，存儲按需付費。同時，POLARDB通過數(shù)據(jù)快照可以在秒級實現(xiàn)備份和恢復(fù)，更利于我們做數(shù)據(jù)庫安全運維，帶來更多價值。

原文鏈接
本文為云棲社區(qū)原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。

總結(jié)

以上是生活随笔為你收集整理的云原生数据库如何打造业务弹性的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。