[[421274]]

一、前言

回顧過去二十年的技術發(fā)展，整個應用形態(tài)和技術架構(gòu)發(fā)生了很大的升級換代，而任何技術的發(fā)展都與幾個重要的變量相關。

1.應用形態(tài)的變遷，產(chǎn)生更多的場景和需求。整個應用形態(tài)從企業(yè)應用、互聯(lián)網(wǎng)服務再到移動應用，歷經(jīng)了幾個不同階段的發(fā)展。從最早企業(yè)內(nèi)應用系統(tǒng)，到通過移動互聯(lián)網(wǎng)技術覆蓋到每個人生活的方方面面，這個過程中產(chǎn)生了大量的場景和需求。而新的場景和需求，是推動產(chǎn)品和技術發(fā)展的主要因素。

2.更復雜的場景，更大規(guī)模的挑戰(zhàn)，推動技術的快速發(fā)展。新一代應用面臨更復雜的場景和更大的規(guī)模挑戰(zhàn)，老一代技術架構(gòu)無法支撐業(yè)務的快速發(fā)展，所以急需推動新的技術的研究和發(fā)展。這是一個綜合的 ROI 的考慮，流量和數(shù)據(jù)到一定規(guī)模才能讓技術架構(gòu)升級帶來更大的效率和成本的收益。

3.技術基礎設施的完善，提供了技術和產(chǎn)品發(fā)展的基礎。互聯(lián)網(wǎng)、4G/5G 等基礎設施的建立和完善，是新一代應用誕生和發(fā)展的基礎。分布式技術、云計算、新一代硬件等技術的成熟，是技術架構(gòu)變革的基礎。

本篇文章會給大家分享應用系統(tǒng)數(shù)據(jù)架構(gòu)的演進以及云上的架構(gòu)最佳實踐，這里先對數(shù)據(jù)系統(tǒng)的分類做一個定義，數(shù)據(jù)系統(tǒng)如果按照主體來區(qū)分的話分為以下兩類：

• 應用為主體：常見的數(shù)據(jù)架構(gòu)都是以『應用』為主體，數(shù)據(jù)主要產(chǎn)生自應用。數(shù)據(jù)架構(gòu)圍繞業(yè)務來設計，通常是先定義業(yè)務模型后設計業(yè)務流程。由于業(yè)務之間區(qū)分度很大，每個業(yè)務都有截然不同的業(yè)務模型，所以數(shù)據(jù)系統(tǒng)需要具備高度『抽象』的能力，所以通常會選擇關系型數(shù)據(jù)庫這類抽象能力強的組件作為核心存儲。
• 數(shù)據(jù)為主體：這類數(shù)據(jù)系統(tǒng)通常圍繞『特定類型數(shù)據(jù)』進行構(gòu)建，比如說圍繞云原生監(jiān)控數(shù)據(jù)設計的以 Prometheus 為核心的監(jiān)控數(shù)據(jù)系統(tǒng)，再比如圍繞日志數(shù)據(jù)分析設計的 ELK 數(shù)據(jù)系統(tǒng)。這類數(shù)據(jù)系統(tǒng)的設計過程通常是圍繞數(shù)據(jù)的收集、存儲、處理、查詢和分析等環(huán)節(jié)來設計整套數(shù)據(jù)系統(tǒng)，數(shù)據(jù)具備統(tǒng)一的『具象』的模型。不同的場景有不同的數(shù)據(jù)系統(tǒng)，當某個場景具備通用性以及得到一定規(guī)模的應用，通常在開源界會誕生一套成熟的、完整的解決方案，比如說云原生 Prometheus、ELK、Hadoop 等。

本篇文章介紹的數(shù)據(jù)架構(gòu)主要是第一類，即以『應用為主體』的數(shù)據(jù)架構(gòu)。

二、應用系統(tǒng)數(shù)據(jù)架構(gòu)

應用系統(tǒng)數(shù)據(jù)架構(gòu)歷經(jīng)了多次迭代，從傳統(tǒng)的單一系統(tǒng)數(shù)據(jù)架構(gòu)，到由多組件構(gòu)成的現(xiàn)代數(shù)據(jù)架構(gòu)?，F(xiàn)代數(shù)據(jù)架構(gòu)下包含不同的計算和存儲組件，這些組件在處理不同類型數(shù)據(jù)以及負載下各有優(yōu)劣?，F(xiàn)代數(shù)據(jù)架構(gòu)通過合理選擇和組合這些組件，讓各個組件能發(fā)揮最大的能力，從而讓整個數(shù)據(jù)系統(tǒng)能滿足更多樣化的場景需求以及能支撐更大的數(shù)據(jù)規(guī)模。

1.傳統(tǒng)數(shù)據(jù)架構(gòu)(單一系統(tǒng))

LAMP 架構(gòu)

一個應用系統(tǒng)的基本構(gòu)成包括：API(提供服務接口)、應用(業(yè)務處理邏輯)、數(shù)據(jù)存儲(應用數(shù)據(jù)存儲)以及運行環(huán)境(應用和數(shù)據(jù)庫的運行環(huán)境)?；ヂ?lián)網(wǎng)早期最流行的 LAMP 架構(gòu)就是典型的單一系統(tǒng)數(shù)據(jù)架構(gòu)，其中使用 Apache Server 作為 API 層、使用 PHP 開發(fā)應用，使用 MySQL 作為應用數(shù)據(jù)存儲，所有組件均運行在 Linux 系統(tǒng)上。

整套架構(gòu)采用開源軟件構(gòu)建，相比商業(yè)軟件能提供更低的成本，所以能快速在互聯(lián)網(wǎng)早期的各大中小站點流行起來，成為最流行的建站技術架構(gòu)。但隨著互聯(lián)網(wǎng)的流量越來越大，LAMP 架構(gòu)面臨的最大的問題是可擴展性，需要解決應用和存儲的擴展問題。

如何進行擴展

關于擴展技術的幾個基本概念：

• Scale-up vs Scale-out
  • Scale-up 即直接提升機器的配置規(guī)格，是最直接的擴展手段，計算和存儲均可通過 Scale-up 的方式來進行擴展，但擴展空間有限，相對成本較高。Scale-out 即增加更多的機器進來，是相對成本更低、更靈活的手段，但需要相關組件具備能 Scale-out 的能力。
• 存儲和計算分離
  • 存儲和計算是兩個不同維度的資源，如果強綁定會極大限制擴展性。對數(shù)據(jù)系統(tǒng)來說，應用節(jié)點和存儲節(jié)點分離就是應用了存儲計算分離的設計思想，讓應用和存儲都能獨立擴展。

Scale-out 具備更好的靈活性和經(jīng)濟性，計算和存儲進行 Scale-out 的常見技術手段包括：

• 存儲 Scale-out
  • 通常采用數(shù)據(jù)分片技術，將數(shù)據(jù)分散到多臺機器上。
• 計算 Scale-out
  • 基于狀態(tài)路由計算：通常用于狀態(tài)遷移代價大的數(shù)據(jù)架構(gòu)，比如數(shù)據(jù)庫的分庫分表。分庫分表的擴展需要進行數(shù)據(jù)復制，所以通常需要提前規(guī)劃，根據(jù)數(shù)據(jù)所在分片來路由計算。
  • 基于計算復制狀態(tài)：如果狀態(tài)能非常靈活的復制或者是共享，那可基于計算來復制狀態(tài)，是一種更靈活的計算擴展架構(gòu)。比如說基于共享存儲的大數(shù)據(jù)計算架構(gòu)，可靈活調(diào)度任意計算節(jié)點對數(shù)據(jù)進行處理。
  • 無狀態(tài)計算：計算不依賴任何狀態(tài)，可以發(fā)生在任意節(jié)點上，所以計算節(jié)點可非常容易實現(xiàn) Scale-out，但需要解決計算調(diào)度問題。常見 Web 應用中的 LoadBalancer 后置一堆 Web Server 就是一個簡單的無狀態(tài)計算擴展架構(gòu)。
  • 有狀態(tài)計算：計算依賴狀態(tài)，計算的擴展依賴狀態(tài)的遷移。如果狀態(tài)不可遷移，那計算的擴展只能采取 Scale-up 的方式。如果狀態(tài)可遷移，那計算就可實現(xiàn) Scale-out，此時計算的可擴展性依賴于狀態(tài)遷移的靈活性。對于可 Scale-out 的計算我們分為兩類實現(xiàn)方式，分別是：

可擴展的傳統(tǒng)數(shù)據(jù)架構(gòu)

LAMP 架構(gòu)應用上面提到的擴展技術，演變成了上圖的可擴展的數(shù)據(jù)架構(gòu)。應用側(cè)通常是無狀態(tài)計算，所以可以簡單采取 Scale-out 的擴展方式，前置 Load Balancer 來進行流量調(diào)度。存儲側(cè)采取分庫分表的方式來進行存儲和計算的擴展，以及只讀庫的方式來對查詢計算進行擴展。雖然各層具備了擴展能力，但該系統(tǒng)還存在一些問題：

• 存儲側(cè)擴展靈活性差，擴展成本較高：計算側(cè)通常是無狀態(tài)計算節(jié)點，擴展相對靈活。但存儲側(cè)的擴展需要進行數(shù)據(jù)復制遷移，擴展周期長且靈活性差。同時 MySQL 的分庫分表每次擴展需要雙倍資源，成本也較高。
• 單一存儲系統(tǒng)，提供的能力有限：MySQL 作為關系模型數(shù)據(jù)庫，在業(yè)務模型抽象上提供極強的抽象能力，所以可以說是一個萬能存儲。在互聯(lián)網(wǎng)早期應用負載不高的情況下，MySQL 是最優(yōu)選擇，且已經(jīng)擁有了成熟的擴展方案。但是隨著應用場景和負載不斷變化，MySQL 還是難以承載。
• 存儲成本高：簡單來說，關系數(shù)據(jù)庫是結(jié)構(gòu)化數(shù)據(jù)存儲單位成本最高的存儲系統(tǒng)。

如何解決存儲側(cè)擴展問題

MySQL 不是萬能的，但 MySQL 對應用系統(tǒng)來說是不可替換的，到目前為止都是這樣。雖然現(xiàn)在有更多新的云原生關系數(shù)據(jù)庫出現(xiàn)來取代傳統(tǒng) MySQL 的位置，但本質(zhì)上都脫不了 MySQL 這個殼，只是更強大的 MySQL 而已。所以很多解決方案都是圍繞 MySQL 作為輔助方案而不是替換方案出現(xiàn)，比如說 Memcached/Redis 這類緩存系統(tǒng)，幫助 MySQL 抵御大部分查詢流量，來解決 MySQL 容易被查詢打崩的問題。

這個設計思想是『分而治之』，將原本 MySQL 所承擔的職責進行細分，能分離解決的就分離解決。現(xiàn)代數(shù)據(jù)架構(gòu)就是基于此思路，仍然以 MySQL 作為應用交互和業(yè)務數(shù)據(jù)存儲的核心，但是使用一些輔助方案解決 MySQL 的問題。

2.現(xiàn)代數(shù)據(jù)架構(gòu)(多樣化系統(tǒng))

定義問題，分而治之

前面提到 MySQL 是應用系統(tǒng)數(shù)據(jù)架構(gòu)的核心存儲，且是不可替換的組件。MySQL 直接承載業(yè)務數(shù)據(jù)和大部分業(yè)務交互，現(xiàn)代數(shù)據(jù)架構(gòu)的演進思路是圍繞 MySQL 提供輔助解決方案，采用『分而治之』的設計思路。所以我們首先得羅列清楚在單一系統(tǒng)架構(gòu)中 MySQL 所承擔的職責，以及明確哪些點是可以分而治之的。分而治之的具體手段包括：

• 流量卸載：承載和抵御 MySQL 的部分讀寫流量，讓 MySQL 有更多資源進行事務處理。由于讀和寫依賴 MySQL 內(nèi)數(shù)據(jù)，所以在卸載流量的同時還會復制全部或者部分數(shù)據(jù)。
• 數(shù)據(jù)卸載：MySQL 內(nèi)部分數(shù)據(jù)會用于事務處理，而部分數(shù)據(jù)僅存儲和查詢。不參與事務處理的數(shù)據(jù)可卸載，來降低表的存儲量，對降成本和減負載都是有極大好處的。

為方便理解對 MySQL 承載的職責的具體含義，我們對應到一個實際場景來解釋對應的職責，我們以『電商訂單』系統(tǒng)來進行舉例。

事務處理一般是需要根據(jù)數(shù)據(jù)庫內(nèi)的一致的狀態(tài)決定操作的執(zhí)行，必須要有 ACID 的保證，這部分只能由 MySQL 來承載。MySQL 的大部分查詢流量都是可被卸載的，最簡單的是創(chuàng)建只讀庫來卸載查詢流量，但某些復雜查詢操作只讀庫無法很高效的執(zhí)行，必須依賴外部存儲來加速，比如說數(shù)據(jù)搜索和數(shù)據(jù)分析。所以這部分流量需要卸載，并且需要復制部分或者全部數(shù)據(jù)。另外 MySQL 內(nèi)存儲的數(shù)據(jù)并不會都用于事務處理，很大一部分數(shù)據(jù)在生成后僅提供查詢或非事務型操作，這部分數(shù)據(jù)的查詢流量和存儲都是可被卸載的。

我們把職責給定義清楚后，也明確了哪些職責是 MySQL 主要承擔的，哪些職責是可以被卸載從而得以有效的『分而治之』的。

在理清了整個解決問題的思路后，接下來才是對架構(gòu)師最大的挑戰(zhàn)：如何選擇合適的組件來卸載流量或者存儲?

選擇合適的存儲組件

1)根據(jù)場景定義需求

準確的定義需求是選對組件的前置條件，切勿僅根據(jù)功能性需求來進行匹配，還需考慮一些基礎性需求，例如存儲組件可提供的 SLA、數(shù)據(jù)可靠性、擴展性、可運維性等等。從上面的表中，我們能夠非常清晰的看到對各組件的功能性需求，那接下來我們再看看基礎性需求如何區(qū)分和選擇。

在做數(shù)據(jù)系統(tǒng)設計時可以把應用數(shù)據(jù)嘗試落在上圖的不同周期內(nèi)，看下如何對存儲組件定義合適的基礎性需求。通常應用系統(tǒng)最先產(chǎn)生的是事務數(shù)據(jù)，事務數(shù)據(jù)會逐步向在線數(shù)據(jù)、離線數(shù)據(jù)轉(zhuǎn)換和流動，在線性逐步降低，從面向前臺逐步轉(zhuǎn)向后臺。再看從事務數(shù)據(jù)到離線數(shù)據(jù)，基礎性要求的具體變化：

• SLA 要求逐步從高到底，在線系統(tǒng)對穩(wěn)定性要求極高，而后臺系統(tǒng)相對來說要求可放低。
• 從 TP 逐步轉(zhuǎn)向 AP，TP 對訪問延遲要求更高，而 AP 對分析能力要求更高。
• 數(shù)據(jù)的更新頻率逐步降低，逐步歸檔為不可變數(shù)據(jù)，所以很多離線系統(tǒng)都是基于數(shù)據(jù)的不可變性來做存儲和計算優(yōu)化。
• 存儲成本逐步降低，數(shù)據(jù)規(guī)模逐步增大。

2)存儲組件的種類和差異

先從宏觀層面比較下數(shù)據(jù)庫類存儲組件的差異：

• 數(shù)據(jù)模型和查詢語言：這兩個點仍然是不同數(shù)據(jù)庫最顯著的區(qū)別。關系模型、文檔模型和寬表模型是相對抽象的模型，而類似時序模型和圖模型等其他非關系模型是相對具象的模型。抽象模型表達力更強，而具象模型更貼近具體場景。
• SQL vs NoSQL：SQL 類更適合事務處理，包含開源或商業(yè)關系數(shù)據(jù)庫;NoSQL 類更適合非事務數(shù)據(jù)處理，基本是以開源為主;場景使用上可以與 SQL 類配合使用，提供流量卸載和存儲卸載;另外 NoSQL 類更多是具象模型，貼近場景而生。
• 數(shù)據(jù)庫 vs 數(shù)據(jù)倉庫：數(shù)據(jù)倉庫更偏離線數(shù)據(jù)分析，提供更大規(guī)模存儲，但是在 SLA 和穩(wěn)定性方面相比數(shù)據(jù)庫略差。
• 云托管 vs 云原生：云原生的本質(zhì)是利用云上池化資源來實現(xiàn)更強的彈性，所以簡單把一個開源軟件托管在云上，并不能稱之為云原生。云原生帶來的優(yōu)勢是更低使用成本、更低運維成本、更靈活的數(shù)據(jù)流轉(zhuǎn)以及更彈性的架構(gòu)。

我們看下當前主流開源數(shù)據(jù)庫以及對應的云原生數(shù)據(jù)庫產(chǎn)品的對比：

在做存儲組件選型時，要考慮功能性需求和基礎性需求，選擇合適的存儲組件。以上表格只是列舉了部分場景和其中推薦的產(chǎn)品，這些產(chǎn)品不是唯一選擇也不一定是最適合的選擇，因業(yè)務不同發(fā)展階段和需求而異。選擇對存儲組件是一件很難的事，所以架構(gòu)師在設計數(shù)據(jù)架構(gòu)時，要提前考慮到存儲組件的新增或替換，數(shù)據(jù)架構(gòu)必須具備這樣的靈活性，因為『構(gòu)建快速迭代能力比應對未知需求的擴展性更重要』。

在一個復雜的應用系統(tǒng)中，必然會存在多套存儲組件的組合，而不是單一的存儲組件來支撐所有的場景和流量，所以架構(gòu)師還得面臨下一個難題：如何合理的組合這些存儲組件?

合理的進行組合

1)派生數(shù)據(jù)架構(gòu)

在數(shù)據(jù)系統(tǒng)架構(gòu)中，我們可以看到會存在多套存儲組件。對于這些存儲組件中的數(shù)據(jù)，有些是來自應用的直寫，有些是來自其他存儲組件的數(shù)據(jù)復制。例如業(yè)務關系數(shù)據(jù)庫的數(shù)據(jù)通常是來自業(yè)務，而高速緩存和搜索引擎的數(shù)據(jù)，通常是來自業(yè)務數(shù)據(jù)庫的數(shù)據(jù)同步與復制。不同用途的存儲組件有不同類型的上下游數(shù)據(jù)鏈路，我們可以大概將其歸類為主存儲和輔存儲兩類，這兩類存儲有不同的設計目標，主要特征為：

• 主存儲：數(shù)據(jù)產(chǎn)生自業(yè)務或者是計算，通常為數(shù)據(jù)首先落地的存儲。在應用系統(tǒng)數(shù)據(jù)架構(gòu)中，MySQL 就是主存儲。
• 輔存儲：數(shù)據(jù)主要來自主存儲的數(shù)據(jù)同步與復制，輔存儲是主存儲的某個視圖，通常面向數(shù)據(jù)查詢、檢索和分析做優(yōu)化。在應用系統(tǒng)數(shù)據(jù)架構(gòu)中，承擔流量卸載或存儲卸載的存儲組件，就是輔存儲。

這種主與輔的存儲組件相輔相成的架構(gòu)設計，我們稱之為『派生數(shù)據(jù)體系』。在這個體系下，最大的技術挑戰(zhàn)是數(shù)據(jù)如何在主與輔之間進行同步與復制。

上圖我們可以看到幾個常見的數(shù)據(jù)復制方式：

• 應用層多寫：這是實現(xiàn)最簡單、依賴最少的一種實現(xiàn)方式，通常采取的方式是在應用代碼中先向主存儲寫數(shù)據(jù)，后向輔存儲寫數(shù)據(jù)。這種方式不是很嚴謹，通常用在對數(shù)據(jù)可靠性要求不是很高的場景。因為存在的問題有很多，一是很難保證主與輔之間的數(shù)據(jù)一致性，無法處理數(shù)據(jù)寫入失效問題;二是數(shù)據(jù)寫入的消耗堆積在應用層，加重應用層的代碼復雜度和計算負擔，不是一種解耦很好的架構(gòu);三是擴展性較差，數(shù)據(jù)同步邏輯固化在代碼中，比較難靈活添加輔存儲。
• 異步隊列復制：這是目前被應用比較廣的架構(gòu)，應用層將派生數(shù)據(jù)的寫入通過隊列來異步化和解耦。這種架構(gòu)下可將主存儲和輔存儲的數(shù)據(jù)寫入都異步化，也可僅將輔存儲的數(shù)據(jù)寫入異步化。第一種方式必須接受主存儲可異步寫入，否則只能采取第二種方式。而如果采用第二種方式的話，也會遇到和上一種『應用層多寫』方案類似的問題，應用層也是多寫，只不過是寫主存儲與隊列，隊列來解決多個輔存儲的寫入和擴展性問題。
• CDC(Change Data Capture)技術：這種架構(gòu)下數(shù)據(jù)寫入主存儲后會由主存儲再向輔存儲進行同步，對應用層是最友好的，只需要與主存儲打交道。主存儲到輔存儲的數(shù)據(jù)同步，則可以再利用異步隊列復制技術來做。不過這種方案對主存儲的能力有很高的要求，必須要求主存儲能支持 CDC 技術。

『派生數(shù)據(jù)體系』是一個比較重要的技術架構(gòu)設計理念，其中 CDC 技術是更好的驅(qū)動數(shù)據(jù)流動的關鍵手段。具備 CDC 技術的存儲組件，才能更好的支撐數(shù)據(jù)派生體系，從而能讓整個數(shù)據(jù)系統(tǒng)架構(gòu)更加靈活，降低了數(shù)據(jù)一致性設計的復雜度，從而來面向高速迭代設計。MySQL 的 CDC 技術是比較成熟的，也演化出來一些中間件和云產(chǎn)品，比如 Canal 以及阿里云的 DTS。所以在我們的現(xiàn)代應用系統(tǒng)數(shù)據(jù)架構(gòu)中，也主要是基于 MySQL 的 CDC 技術來進行數(shù)據(jù)派生。

現(xiàn)代應用系統(tǒng)數(shù)據(jù)架構(gòu)

上圖就是一個典型的現(xiàn)代應用系統(tǒng)數(shù)據(jù)架構(gòu)，我們來系統(tǒng)的看下：

1.由多存儲組件構(gòu)成，每個存儲組件各司其職：

• MySQL：承載事務處理，為整個數(shù)據(jù)架構(gòu)的主存儲，其余組件承擔流量卸載和存儲卸載的職責。
• Redis：作為 MySQL 的查詢結(jié)果集緩存，幫助 MySQL 來抵御大部分的查詢流量，但 Redis 如果失效，則會有擊穿 MySQL的風險。
• Elasticsearch：倒排索引和搜索引擎技術能提供 MySQL 索引所無法支持的高效模糊查詢、全文檢索和多字段組合條件過濾的能力，所以主要是承擔復雜查詢的流量卸載。
• HBase：分布式 KV 存儲，提供寬表模型?？捎糜谛遁d MySQL 內(nèi)非事務性數(shù)據(jù)，可存儲 MySQL 內(nèi)所有表的全量數(shù)據(jù)，提供低成本的存儲卸載。HBase 也是一個在線系統(tǒng)，所以也能提供簡單查詢的流量卸載。
• ClickHouse：MPP 架構(gòu)的開源數(shù)倉，具備非常優(yōu)異的分析性能，主要職責是分析流量卸載。

2.基于 MySQL CDC 的派生數(shù)據(jù)架構(gòu)，由開源產(chǎn)品 Canal 來做實時數(shù)據(jù)同步。但這里 ClickHouse 的數(shù)據(jù)同步并不一定需要是實時增量的，也可采用 T+1 的全量同步方式。

3.應用系統(tǒng)需要與這些不同組件分別進行交互，且交互接口各不相同。

這個架構(gòu)具備一定的靈活性，通過 Canal 來解決異構(gòu)存儲間的數(shù)據(jù)同步問題，通過插件機制可靈活增加新的存儲組件來應對未來的新的需求。每個組件都是開源界打磨多年的成熟產(chǎn)品，也有一些中間件來降低應用與這些組件的交互成本。但也存在一些明顯的問題：

• 運維成本極大：運維是一門技術活，需要對組件的原理有比較清楚的了解才能更好的運維，以及進行線上問題的排查和優(yōu)化。這些開源產(chǎn)品已經(jīng)將使用成本降的足夠低，但是運維成本還是很高，比如 HBase 組件的運維還需要額外運維 Zookeeper、HDFS 等。云托管產(chǎn)品降低了一定的運維成本，但仍無法做到免運維，業(yè)務 OPS 仍需要花大量精力在性能調(diào)優(yōu)、容量規(guī)劃等工作上。另外多組件會比單組件運維成本更高，因為還需要管理組件間的數(shù)據(jù)流。
• 多 API 交互復雜：每個組件都提供了不盡相同的 API，應用與不同組件的交互很難抽象和解耦。
• 成本高：每一個新的組件的引入都需要額外的存儲和計算成本，但各組件的偏向不一樣，有的更重計算有的更重存儲。如果多組件間能共享計算或存儲，那能極大的降低成本。而在當前的架構(gòu)中，每個組件都是相互獨立的，需要獨享存儲和計算資源。

三、云上數(shù)據(jù)架構(gòu)實踐

把現(xiàn)代數(shù)據(jù)架構(gòu)搬到云上，可利用云的優(yōu)勢來優(yōu)化整套架構(gòu)：一是找到合適的云原生產(chǎn)品替換開源產(chǎn)品，最大好處是降低運維成本，其次能獲得更強的穩(wěn)定性和性能;二是用更少的組件做更多的事，來降低管理和使用成本，也能降低應用交互開發(fā)復雜度。

以上就是完整的云上數(shù)據(jù)架構(gòu)，重點講下替換開源組件的幾個云產(chǎn)品：

• DTS(數(shù)據(jù)傳輸服務)：原理與 Canal 類似，能對接更多數(shù)據(jù)庫上游和下游，全托管的 MySQL 實時數(shù)據(jù)同步中間件。
• Tair(Redis 企業(yè)版)：阿里自研企業(yè)級緩存，兼容 Redis 協(xié)議，具備更強的性能。
• Tablestore(表格存儲)：阿里自研 Bigtable，提供兼容 HBase 的寬表引擎，以及能力和性能都優(yōu)于 Elasticsearch 的索引引擎。純 Serverless 免運維能最大程度降低運維成本，同時提供 API 和 SQL 的接口降低應用開發(fā)成本。
• ADB(分析型數(shù)據(jù)庫)：阿里自研實時數(shù)倉，具備強大的分析性能，完全兼容 MySQL 協(xié)議。

接下來我們再重點提下 Tablestore，因為在應用系統(tǒng)在線場景，Tablestore 承載了流量卸載和存儲卸載的重要職責。Tair 的使用和定位與 Redis 完全一致，而 Tablestore 相比 HBase 和 Elasticsearch 有更大的差異性。

1.表格存儲 Tablestore

表格存儲 Tablestore 是阿里云自研的面向海量結(jié)構(gòu)化和半結(jié)構(gòu)化數(shù)據(jù)存儲的 Serverless 多模型結(jié)構(gòu)化數(shù)據(jù)存儲，被廣泛用于社交、物聯(lián)網(wǎng)、人工智能、元數(shù)據(jù)和大數(shù)據(jù)等業(yè)務場景。采用與 Google Bigtable 類似的寬表模型，天然的分布式架構(gòu)，能支撐高吞吐的數(shù)據(jù)寫入以及 PB 級數(shù)據(jù)存儲，具體產(chǎn)品介紹可以參考官網(wǎng)以及權(quán)威指南。

Tablestore 提供兼容 HBase 的寬表引擎，以及能力和性能都優(yōu)于 Elasticsearch 的索引引擎，它的核心能力包括：

• 多模型：提供抽象模型 WideColumn 寬表模型，以及具象模型 Timeline 消息模型以及 Timestream 時序模型。具象模型更適合應用與應用系統(tǒng)，而具象模型是圍繞具體場景的數(shù)據(jù)架構(gòu)而設計和深度優(yōu)化。
• 多元化索引：提供二級索引和多元索引，不同查詢加速場景提供不同的索引實現(xiàn)，其中多元索引能提供全文檢索、地理位置檢索以及靈活的多條件組合查詢，功能和性能都優(yōu)于 Elasticsearch。
• 存儲計算分離架構(gòu)：提供計算和存儲側(cè)的靈活擴展能力，不僅體現(xiàn)在架構(gòu)上，也體現(xiàn)在產(chǎn)品形態(tài)上。用戶可以單獨為存儲付費或為計算付費，提供更靈活的資源組合，獲得最低的成本。
• Serverless 服務：純 Serverless 服務，提供完全免運維的服務，全球部署、即開即用。零成本即可接入，最大可擴展至千萬 TPS 服務能力以及 PB 級存儲。
• 計算生態(tài)：能夠與開源計算引擎對接，融合流批一體計算能力。同時自身提供 CDC 能力，讓數(shù)據(jù)能夠更靈活的進行流轉(zhuǎn)。
• CDC 技術：Tablestore 的 CDC 技術名為 Tunnel Service，支持全量和增量的實時數(shù)據(jù)訂閱，并且能無縫對接 Flink 流計算引擎來實現(xiàn)表內(nèi)數(shù)據(jù)的實時流計算。
• SQL 支持：提供 SQL 支持，大大降低使用和應用開發(fā)門檻。

四、總結(jié) 

技術架構(gòu)的選擇沒有統(tǒng)一標準答案，是一個綜合的權(quán)衡考慮。本文主要介紹了應用系統(tǒng)數(shù)據(jù)架構(gòu)的變遷，相信隨著應用場景越來越復雜、更多需求的提出，隨著底層基礎設施的完善，會有更多新技術和產(chǎn)品出現(xiàn)，而數(shù)據(jù)架構(gòu)也會繼續(xù)演進。但是一些經(jīng)典的設計思想會保留，例如分而治之、派生數(shù)據(jù)架構(gòu)、如何靈活的選擇和組合存儲和計算組件等。以通過以下二維碼關注。轉(zhuǎn)載本文請聯(lián)系C you again公眾號。

【本文為專欄作者“阿里巴巴官方技術”原創(chuàng)稿件，轉(zhuǎn)載請聯(lián)系原作者】

網(wǎng)頁名稱：云上應用系統(tǒng)的數(shù)據(jù)存儲架構(gòu)演進
鏈接URL：http://uogjgqi.cn/article/dhipoee.html