云原生數(shù)據(jù)庫(kù)如何打造業(yè)務(wù)彈性

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

cdn.com/fbbf0025947aef2ac0443c289a77f68255345722.jpeg">

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

POLARDB跟MySQL是100%兼容的，有超越MySQL很多倍的性能，以及單實(shí)例最大100TB的超大存儲(chǔ)空間，可以理解為阿里自研的超級(jí)MySQL。那么我們?yōu)槭裁匆蛟爝@樣一款超級(jí)MySQL呢？我們理解這是應(yīng)用架構(gòu)進(jìn)行互聯(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)用的框架，開(kāi)發(fā)運(yùn)維的角度都在發(fā)生了互聯(lián)網(wǎng)分布式變遷。

• 資源層：傳統(tǒng)應(yīng)用會(huì)使用X86 ，小機(jī)以及存儲(chǔ)設(shè)備；互聯(lián)網(wǎng)分布式應(yīng)用在使用公有云，私有云，混合云等。

• 數(shù)據(jù)層：傳統(tǒng)應(yīng)用會(huì)使用Oracle，DB2等集中化的商業(yè)數(shù)據(jù)庫(kù)，互聯(lián)網(wǎng)應(yīng)用使用的是MySQL，Redis，HBase這樣的分布式數(shù)據(jù)庫(kù)，他們不需要集中化的存儲(chǔ)設(shè)備。

• 中間件：傳統(tǒng)應(yīng)用會(huì)使用WebLogic，WebSphere等，互聯(lián)網(wǎng)應(yīng)用在向微服務(wù)架構(gòu)轉(zhuǎn)型中通常會(huì)使用Swarm，K8S，Mesos。

• 應(yīng)用發(fā)布封裝：傳統(tǒng)應(yīng)用會(huì)使用JAVA開(kāi)發(fā)并發(fā)布成war/ear文件封裝，再發(fā)布到中間件。微服務(wù)架構(gòu)通常會(huì)將應(yīng)用發(fā)布成容器的鏡像。

• 應(yīng)用框架：傳統(tǒng)應(yīng)用通常會(huì)使用Spring，Struts，hibernate來(lái)開(kāi)發(fā)，而目前互聯(lián)網(wǎng)分布式應(yīng)用更多使用的是SpringCloud, Double, EDAS等微服務(wù)架構(gòu)。

• 開(kāi)發(fā)運(yùn)維：傳統(tǒng)應(yīng)用會(huì)使用可控的發(fā)布，保守的運(yùn)維，新功能上線需要數(shù)周，甚至數(shù)月時(shí)間；互聯(lián)網(wǎng)分布式架構(gòu)更多使用的是DevOps持續(xù)集成，敏捷快速迭代。

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

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

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

演進(jìn)路線

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

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

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

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

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

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

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

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

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

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