雲計算帶來了業務彈性上的極大優勢，阿裡雲資料庫進階産品專家時慢從應用架構的變遷，客戶實戰案例，業務分析等方面詳細介紹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通過資料快照可以在秒級實作備份和恢複，更利于我們做資料庫安全運維，帶來更多價值。