​簡介：回顧過去二十年的技術發展，整個應用形態和技術架構發生了很大的升級換代，而任何技術的發展都與幾個重要的變數相關。本文將會給大家分享應用系統資料架構的演進以及雲上的架構最佳實踐。

​

來源 | 阿里技術公眾號

一 前言

回顧過去二十年的技術發展，整個應用形態和技術架構發生了很大的升級換代，而任何技術的發展都與幾個重要的變數相關。

一，應用形態的變遷，產生更多的場景和需求。整個應用形態從企業應用、網際網路服務再到移動應用，歷經了幾個不同階段的發展。從最早企業內應用系統，到通過移動網際網路技術覆蓋到每個人生活的方方面面，這個過程中產生了大量的場景和需求。而新的場景和需求，是推動產品和技術發展的主要因素。

二，更復雜的場景，更大規模的挑戰，推動技術的快速發展。新一代應用面臨更復雜的場景和更大的規模挑戰，老一代技術架構無法支撐業務的快速發展，所以急需推動新的技術的研究和發展。這是一個綜合的 ROI 的考慮，流量和資料到一定規模才能讓技術架構升級帶來更大的效率和成本的收益。

三，技術基礎設施的完善，提供了技術和產品發展的基礎。網際網路、4G/5G 等基礎設施的建立和完善，是新一代應用誕生和發展的基礎。分散式技術、雲端計算、新一代硬體等技術的成熟，是技術架構變革的基礎。

本篇文章會給大家分享應用系統資料架構的演進以及雲上的架構最佳實踐，這裡先對資料系統的分類做一個定義，資料系統如果按照主體來區分的話分為以下兩類：

1. 應用為主體：常見的資料架構都是以『應用』為主體，資料主要產生自應用。資料架構圍繞業務來設計，通常是先定義業務模型後設計業務流程。由於業務之間區分度很大，每個業務都有截然不同的業務模型，所以資料系統需要具備高度『抽象』的能力，所以通常會選擇關係型資料庫這類抽象能力強的元件作為核心儲存。
2. 資料為主體：這類資料系統通常圍繞『特定型別資料』進行構建，比如說圍繞雲原生監控資料設計的以 Prometheus 為核心的監控資料系統，再比如圍繞日誌資料分析設計的 ELK 資料系統。這類資料系統的設計過程通常是圍繞資料的收集、儲存、處理、查詢和分析等環節來設計整套資料系統，資料具備統一的『具象』的模型。不同的場景有不同的資料系統，當某個場景具備通用性以及得到一定規模的應用，通常在開源界會誕生一套成熟的、完整的解決方案，比如說雲原生 Prometheus、ELK、Hadoop 等。

本篇文章介紹的資料架構主要是第一類，即以『應用為主體』的資料架構。

二 應用系統資料架構

應用系統資料架構歷經了多次迭代，從傳統的單一系統資料架構，到由多元件構成的現代資料架構。現代資料架構下包含不同的計算和儲存元件，這些元件在處理不同型別資料以及負載下各有優劣。現代資料架構通過合理選擇和組合這些元件，讓各個元件能發揮最大的能力，從而讓整個資料系統能滿足更多樣化的場景需求以及能支撐更大的資料規模。

1 傳統資料架構（單一系統）

LAMP 架構

​

整套架構採用開源軟體構建，相比商業軟體能提供更低的成本，所以能快速在網際網路早期的各大中小站點流行起來，成為最流行的建站技術架構。但隨著網際網路的流量越來越大，LAMP 架構面臨的最大的問題是可擴充套件性，需要解決應用和儲存的擴充套件問題。

如何進行擴充套件

關於擴充套件技術的幾個基本概念：

• Scale-up vs Scale-out

  • Scale-up 即直接提升機器的配置規格，是最直接的擴充套件手段，計算和儲存均可通過 Scale-up 的方式來進行擴充套件，但擴充套件空間有限，相對成本較高。Scale-out 即增加更多的機器進來，是相對成本更低、更靈活的手段，但需要相關元件具備能 Scale-out 的能力。

• 儲存和計算分離

  • 儲存和計算是兩個不同維度的資源，如果強繫結會極大限制擴充套件性。對資料系統來說，應用節點和儲存節點分離就是應用了儲存計算分離的設計思想，讓應用和儲存都能獨立擴充套件。

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

• 儲存 Scale-out

  • 通常採用資料分片技術，將資料分散到多臺機器上。

• 計算 Scale-out

  • 基於狀態路由計算：通常用於狀態遷移代價大的資料架構，比如資料庫的分庫分表。分庫分表的擴充套件需要進行資料複製，所以通常需要提前規劃，根據資料所在分片來路由計算。
  • 基於計算複製狀態：如果狀態能非常靈活的複製或者是共享，那可基於計算來複制狀態，是一種更靈活的計算擴充套件架構。比如說基於共享儲存的大資料計算架構，可靈活排程任意計算節點對資料進行處理。
  • 無狀態計算：計算不依賴任何狀態，可以發生在任意節點上，所以計算節點可非常容易實現 Scale-out，但需要解決計算排程問題。常見 Web 應用中的 LoadBalancer 後置一堆 Web Server 就是一個簡單的無狀態計算擴充套件架構。
  • 有狀態計算：計算依賴狀態，計算的擴充套件依賴狀態的遷移。如果狀態不可遷移，那計算的擴充套件只能採取 Scale-up 的方式。如果狀態可遷移，那計算就可實現 Scale-out，此時計算的可擴充套件性依賴於狀態遷移的靈活性。對於可 Scale-out 的計算我們分為兩類實現方式，分別是：

可擴充套件的傳統資料架構

​

• 儲存側擴充套件靈活性差，擴充套件成本較高：計算側通常是無狀態計算節點，擴充套件相對靈活。但儲存側的擴充套件需要進行資料複製遷移，擴充套件週期長且靈活性差。同時 MySQL 的分庫分表每次擴充套件需要雙倍資源，成本也較高。
• 單一儲存系統，提供的能力有限：MySQL 作為關係模型資料庫，在業務模型抽象上提供極強的抽象能力，所以可以說是一個萬能儲存。在網際網路早期應用負載不高的情況下，MySQL 是最優選擇，且已經擁有了成熟的擴充套件方案。但是隨著應用場景和負載不斷變化，MySQL 還是難以承載。
• 儲存成本高：簡單來說，關係資料庫是結構化資料儲存單位成本最高的儲存系統。

如何解決儲存側擴充套件問題

MySQL 不是萬能的，但 MySQL 對應用系統來說是不可替換的，到目前為止都是這樣。雖然現在有更多新的雲原生關係資料庫出現來取代傳統 MySQL 的位置，但本質上都脫不了 MySQL 這個殼，只是更強大的 MySQL 而已。所以很多解決方案都是圍繞 MySQL 作為輔助方案而不是替換方案出現，比如說 Memcached/Redis 這類快取系統，幫助 MySQL 抵禦大部分查詢流量，來解決 MySQL 容易被查詢打崩的問題。

這個設計思想是『分而治之』，將原本 MySQL 所承擔的職責進行細分，能分離解決的就分離解決。現代資料架構就是基於此思路，仍然以 MySQL 作為應用互動和業務資料儲存的核心，但是使用一些輔助方案解決 MySQL 的問題。

2 現代資料架構（多樣化系統）

定義問題，分而治之

前面提到 MySQL 是應用系統資料架構的核心儲存，且是不可替換的元件。MySQL 直接承載業務資料和大部分業務互動，現代資料架構的演進思路是圍繞 MySQL 提供輔助解決方案，採用『分而治之』的設計思路。所以我們首先得羅列清楚在單一系統架構中 MySQL 所承擔的職責，以及明確哪些點是可以分而治之的。分而治之的具體手段包括：

1. 流量解除安裝：承載和抵禦 MySQL 的部分讀寫流量，讓 MySQL 有更多資源進行事務處理。由於讀和寫依賴 MySQL 內資料，所以在解除安裝流量的同時還會複製全部或者部分資料。
2. 資料解除安裝：MySQL 內部分資料會用於事務處理，而部分資料僅儲存和查詢。不參與事務處理的資料可解除安裝，來降低表的儲存量，對降成本和減負載都是有極大好處的。

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

​

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

​

選擇合適的儲存元件

1）根據場景定義需求

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

​

1. SLA 要求逐步從高到底，線上系統對穩定性要求極高，而後臺系統相對來說要求可放低。
2. 從 TP 逐步轉向 AP，TP 對訪問延遲要求更高，而 AP 對分析能力要求更高。
3. 資料的更新頻率逐步降低，逐步歸檔為不可變資料，所以很多離線系統都是基於資料的不可變性來做儲存和計算優化。
4. 儲存成本逐步降低，資料規模逐步增大。

2）儲存元件的種類和差異

先從巨集觀層面比較下資料庫類儲存元件的差異：

• 資料模型和查詢語言：這兩個點仍然是不同資料庫最顯著的區別。關係模型、文件模型和寬表模型是相對抽象的模型，而類似時序模型和圖模型等其他非關係模型是相對具象的模型。抽象模型表達力更強，而具象模型更貼近具體場景。
• SQL vs NoSQL：SQL 類更適合事務處理，包含開源或商業關係資料庫；NoSQL 類更適合非事務資料處理，基本是以開源為主；場景使用上可以與 SQL 類配合使用，提供流量解除安裝和儲存解除安裝；另外 NoSQL 類更多是具象模型，貼近場景而生。
• 資料庫 vs 資料倉庫：資料倉庫更偏離線資料分析，提供更大規模儲存，但是在 SLA 和穩定性方面相比資料庫略差。
• 雲託管 vs 雲原生：雲原生的本質是利用雲上池化資源來實現更強的彈性，所以簡單把一個開源軟體託管在雲上，並不能稱之為雲原生。雲原生帶來的優勢是更低使用成本、更低運維成本、更靈活的資料流轉以及更彈性的架構。

我們看下當前主流開源資料庫以及對應的雲原生資料庫產品的對比：

​

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

合理的進行組合

1）派生資料架構

在資料系統架構中，我們可以看到會存在多套儲存元件。對於這些儲存元件中的資料，有些是來自應用的直寫，有些是來自其他儲存元件的資料複製。例如業務關係資料庫的資料通常是來自業務，而快取記憶體和搜尋引擎的資料，通常是來自業務資料庫的資料同步與複製。不同用途的儲存元件有不同型別的上下游資料鏈路，我們可以大概將其歸類為主儲存和輔儲存兩類，這兩類儲存有不同的設計目標，主要特徵為：

• 主儲存：資料產生自業務或者是計算，通常為資料首先落地的儲存。在應用系統資料架構中，MySQL 就是主儲存。
• 輔儲存：資料主要來自主儲存的資料同步與複製，輔儲存是主儲存的某個檢視，通常面向資料查詢、檢索和分析做優化。在應用系統資料架構中，承擔流量解除安裝或儲存解除安裝的儲存元件，就是輔儲存。

這種主與輔的儲存元件相輔相成的架構設計，我們稱之為『派生資料體系』。在這個體系下，最大的技術挑戰是資料如何在主與輔之間進行同步與複製。

​

• 應用層多寫：這是實現最簡單、依賴最少的一種實現方式，通常採取的方式是在應用程式碼中先向主儲存寫資料，後向輔儲存寫資料。這種方式不是很嚴謹，通常用在對資料可靠性要求不是很高的場景。因為存在的問題有很多，一是很難保證主與輔之間的資料一致性，無法處理資料寫入失效問題；二是資料寫入的消耗堆積在應用層，加重應用層的程式碼複雜度和計算負擔，不是一種解耦很好的架構；三是擴充套件性較差，資料同步邏輯固化在程式碼中，比較難靈活新增輔儲存。
• 非同步佇列複製：這是目前被應用比較廣的架構，應用層將派生資料的寫入通過佇列來非同步化和解耦。這種架構下可將主儲存和輔儲存的資料寫入都非同步化，也可僅將輔儲存的資料寫入非同步化。第一種方式必須接受主儲存可非同步寫入，否則只能採取第二種方式。而如果採用第二種方式的話，也會遇到和上一種『應用層多寫』方案類似的問題，應用層也是多寫，只不過是寫主儲存與佇列，佇列來解決多個輔儲存的寫入和擴充套件性問題。
• CDC（Change Data Capture）技術：這種架構下資料寫入主儲存後會由主儲存再向輔儲存進行同步，對應用層是最友好的，只需要與主儲存打交道。主儲存到輔儲存的資料同步，則可以再利用非同步佇列複製技術來做。不過這種方案對主儲存的能力有很高的要求，必須要求主儲存能支援 CDC 技術。

『派生資料體系』是一個比較重要的技術架構設計理念，其中 CDC 技術是更好的驅動資料流動的關鍵手段。具備 CDC 技術的儲存元件，才能更好的支撐資料派生體系，從而能讓整個資料系統架構更加靈活，降低了資料一致性設計的複雜度，從而來面向高速迭代設計。MySQL 的 CDC 技術是比較成熟的，也演化出來一些中介軟體和雲產品，比如 Canal 以及阿里雲的 DTS。所以在我們的現代應用系統資料架構中，也主要是基於 MySQL 的 CDC 技術來進行資料派生。

現代應用系統資料架構

​

1. 由多儲存元件構成，每個儲存元件各司其職：

   • MySQL：承載事務處理，為整個資料架構的主儲存，其餘元件承擔流量解除安裝和儲存解除安裝的職責。
   • Redis：作為 MySQL 的查詢結果集快取，幫助 MySQL 來抵禦大部分的查詢流量，但 Redis 如果失效，則會有擊穿 MySQL的風險。
   • Elasticsearch：倒排索引和搜尋引擎技術能提供 MySQL 索引所無法支援的高效模糊查詢、全文檢索和多欄位組合條件過濾的能力，所以主要是承擔複雜查詢的流量解除安裝。
   • HBase：分散式 KV 儲存，提供寬表模型。可用於解除安裝 MySQL 內非事務性資料，可儲存 MySQL 內所有表的全量資料，提供低成本的儲存解除安裝。HBase 也是一個線上系統，所以也能提供簡單查詢的流量解除安裝。
   • ClickHouse：MPP 架構的開源數倉，具備非常優異的分析效能，主要職責是分析流量解除安裝。
2. 基於 MySQL CDC 的派生資料架構，由開源產品 Canal 來做實時資料同步。但這裡 ClickHouse 的資料同步並不一定需要是實時增量的，也可採用 T+1 的全量同步方式。
3. 應用系統需要與這些不同元件分別進行互動，且互動介面各不相同。

這個架構具備一定的靈活性，通過 Canal 來解決異構儲存間的資料同步問題，通過外掛機制可靈活增加新的儲存元件來應對未來的新的需求。每個元件都是開源界打磨多年的成熟產品，也有一些中介軟體來降低應用與這些元件的互動成本。但也存在一些明顯的問題：

1. 運維成本極大：運維是一門技術活，需要對元件的原理有比較清楚的瞭解才能更好的運維，以及進行線上問題的排查和優化。這些開源產品已經將使用成本降的足夠低，但是運維成本還是很高，比如 HBase 元件的運維還需要額外運維 Zookeeper、HDFS 等。雲託管產品降低了一定的運維成本，但仍無法做到免運維，業務 OPS 仍需要花大量精力在效能調優、容量規劃等工作上。另外多元件會比單元件運維成本更高，因為還需要管理元件間的資料流。
2. 多 API 互動複雜：每個元件都提供了不盡相同的 API，應用與不同元件的互動很難抽象和解耦。
3. 成本高：每一個新的元件的引入都需要額外的儲存和計算成本，但各元件的偏向不一樣，有的更重計算有的更重儲存。如果多元件間能共享計算或儲存，那能極大的降低成本。而在當前的架構中，每個元件都是相互獨立的，需要獨享儲存和計算資源。

三 雲上資料架構實踐

把現代資料架構搬到雲上，可利用雲的優勢來優化整套架構：一是找到合適的雲原生產品替換開源產品，最大好處是降低運維成本，其次能獲得更強的穩定性和效能；二是用更少的元件做更多的事，來降低管理和使用成本，也能降低應用互動開發複雜度。

​

• DTS（資料傳輸服務）：原理與 Canal 類似，能對接更多資料庫上游和下游，全託管的 MySQL 實時資料同步中介軟體。
• Tair（Redis 企業版）：阿里自研企業級快取，相容 Redis 協議，具備更強的效能。
• Tablestore（表格儲存）：阿里自研 Bigtable，提供相容 HBase 的寬表引擎，以及能力和效能都優於 Elasticsearch 的索引引擎。純 Serverless 免運維能最大程度降低運維成本，同時提供 API 和 SQL 的介面降低應用開發成本。
• ADB（分析型資料庫）：阿里自研實時數倉，具備強大的分析效能，完全相容 MySQL 協議。

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

1 表格儲存 Tablestore

表格儲存 Tablestore 是阿里雲自研的面向海量結構化和半結構化資料儲存的 Serverless 多模型結構化資料儲存，被廣泛用於社交、物聯網、人工智慧、元資料和大資料等業務場景。採用與 Google Bigtable 類似的寬表模型，天然的分散式架構，能支撐高吞吐的資料寫入以及 PB 級資料儲存，具體產品介紹可以參考官網以及權威指南。

​

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

四 總結

技術架構的選擇沒有統一標準答案，是一個綜合的權衡考慮。本文主要介紹了應用系統資料架構的變遷，相信隨著應用場景越來越複雜、更多需求的提出，隨著底層基礎設施的完善，會有更多新技術和產品出現，而資料架構也會繼續演進。但是一些經典的設計思想會保留，例如分而治之、派生資料架構、如何靈活的選擇和組合儲存和計算元件等。

原文連結
本文為阿里雲原創內容，未經允許不得轉載。

​