背景
訂單系統存在于各行各業，如電商訂單、銀行流水、營運商話費賬單等，是一個非常廣泛、通用的系統。對于這類系統，在過去十幾年發展中已經形成了經典的做法。但是随着網際網路的發展，以及各企業對資料的重視，需要存儲和持久化的訂單量越來越大，資料的重視程度與資料規模的膨脹帶來了新的挑戰。首先，訂單量對于資料的存儲、持久化、通路帶來了挑戰，這不僅增加了開發面對的困難，也為系統的運維帶來了挑戰。其次，随着大資料技術的發展以及營運水準的不斷提高，訂單資料的後續資料分析工作，如流批處理、ETL，也越來越重要，這也對資料的存儲系統提出了更高的要求。
本文提出了一種基于MySQL + Tablestore 的大規模訂單系統設計方案。這種方案基于分層存儲的思想，使用 Tablestore 輔助 MySQL 共同完成訂單系統支援。在系統中，利用 MySQL 的事務能力來處理對事務強需求的寫操作與部分讀操作；利用 Tablestore 的檢索能力、大資料存儲能力等彌補 MySQL 在功能上的短闆。詳細可見文章：
雲上應用系統資料架構實踐。
本文作為 MySQL + Tablestore 分層存儲架構的大規模訂單系統的架構篇，
- 首先詳細闡述，在大規模訂單系統中，存在哪些需求，存在哪些痛點。
- 進而比較傳統的架構，其現狀如何，各存在什麼樣的劣勢，無法滿足哪些需求。
- 然後講述 MySQL + Tablestore 架構，闡述這種架構是如何滿足大規模訂單系統的需求的。
需求場景
訂單系統，面向 C 端，除了在系統性能要求高外，對于資料的存儲、後續資料的計算、資料實時處理、資料批處理都有一定的要求。而對于 C 端客戶、産品營運、系統運維等不同的角色，他們對系統的需求也有所不同。
C 端需求
對于 C 端客戶以及面向 C 端的開發而言，系統首先需要支援高并發、高穩定性。其次，系統需要能夠支援基于使用者 id 的搜尋以及搜尋使用者 id 下包含特定關鍵詞的記錄。具體的需求有：
- 基于使用者 id 查找使用者近一月的訂單。
- 基于訂單号查詢訂單詳情。
- 搜尋使用者購買過的包含某關鍵字的商品。
- ……
這對于系統的索引能力以及搜尋能力有較高的要求。
營運需求
營運同學需要能夠在不影響線上的情況下使用 SQL 對實時資料進行分析，能夠根據非主鍵字段進行檢索；他們還需要系統對流批計算的支援，需要流式資料處理來進行實時資料統計，需要批處理來進行曆史資料統計。營運同學常見的需求場景有：
- 統計在某旗艦店消費過的使用者有哪些。
- 統計消費過某一件産品的客戶有哪些并且他們還購買了什麼産品，進而向客戶推薦商品。
- 實時統計雙十一開始後的實時成交額，用于宣傳時的實時資料展示。
- 統計某店鋪過去 10 年的成交額。
- 依賴訂單資料對客戶做實時更新的畫像分析，以支援商品的推薦。
運維需求
運維同學更關注系統的穩定性、複雜度并期待低運維成本。而基于 MySQL + Tablestore 的訂單系統可以将運維同學從繁瑣的運維工作中解放出來，大大降低運維成本。它能夠做到：
- 系統高可用，并發能力強。
- 系統複雜度低，不需要維護多個叢集，也不需要關注各叢集間的資料同步過程，運維工作簡單易上手。
傳統訂單系統
訂單系統架構演進
最簡單的訂單系統就是單點的 MySQL 架構，但随着訂單規模的增長，使用者采用分庫分表的 MySQL 替代單點 MySQL 方案。但這種方案下，當資料量達到目前 MySQL 叢集瓶頸，叢集擴容仍然會相當具有難度，需要更大的叢集以及大量資料的遷移工作。資料疊代、膨脹帶來的困擾，是分庫分表 MySQL 方案難于逾越的。
NoSQL 被引入，MySQL + HBase 的方案應運而生。這種方案将實時資料和曆史資料分層存儲，MySQL 中隻存儲實時資料，曆史資料歸檔進入 HBase 存儲。這種方案解決了資料擴容帶來的存儲和運維難題，但它的缺點在于，存儲于HBase的資料很難被合理利用，并且方案整體也不支援檢索功能。
是以，架構中引入了 Elasticsearch，形成了 MySQL + HBase + Elasticsearch 的方案。這種方案利用了 Elasticsearch 提供的資料檢索能力，解決了訂單資料的搜尋問題。但在這種架構下，使用者要維護 HBase、Elasticsearch 兩個叢集，還需要關注向HBase、Elasticsearch 同步資料的任務，維護成本很高。并且這種架構仍無法支援流批處理、ETL等資料分析、加工工作。
MySQL 分庫分表方案
MySQL 自身擁有強大的資料查詢、分析功能，基于 MySQL 建立訂單系統，可以應對訂單資料多元查詢、統計場景。伴随着訂單資料量的增加，使用者會采取分庫、分表方案應對，通過這種僞分布式方案，解決資料膨脹帶來的問題。但資料一旦達到瓶頸，便需要重新建立更大規模的分庫 + 資料的全量遷移，麻煩就會不斷出現。資料疊代、膨脹帶來的困擾，是MySQL 方案難于逾越的。僅僅依靠 MySQL 的傳統訂單方案短闆凸顯。
1、資料縱向（資料規模）膨脹：采用分庫分表方案，MySQL 在部署時需要預估分庫規模，資料量一旦達到上限後，重新部署并做資料全量遷移；
2、資料橫向（字段次元）膨脹：schema 需預定義，疊代新增新字段變更複雜。而次元到達一定量後影響資料庫性能；
資料膨脹還會提高系統運維難度和成本。且 MySQL 叢集一般采用雙倍政策擴容，在重儲存低計算的訂單場景下，CPU的浪費情況也會比較嚴重。
MySQL + HBase 方案
引入雙資料的方案應運而生，通過實時資料、曆史資料分存的方案，可以一定程度解決資料量膨脹問題。該方案将資料歸類成兩部分存儲：實時資料、曆史資料。同時通過資料同步服務，将過期資料同步至曆史資料。
1、實時訂單資料（例如：近 3 個月的訂單）：将實時訂單存入 MySQL 資料庫。實時訂單的總量膨脹的速度得到了限制，同時保證了實時資料的多元查詢、分析能力；
2、曆史訂單資料（例如：3 個月以前的訂單）：将曆史訂單資料存入 HBase，借助于 HBase 這一分布式 NoSQL 資料庫，有效應對了訂單資料膨脹困擾。也保證了曆史訂單資料的持久化；
但是，該方案犧牲了曆史訂單資料對使用者、商家、平台的使用價值，假設了曆史資料的需求頻率極低。但是一旦有需求，便需要全表掃描，查詢速度慢、IO 成本很高。而維護資料同步又帶來了資料一緻性、同步運維成本飙升等難題；
MySQL + HBase + Elasticsearch 方案
MySQL + HBase + Elasticsearch 方案通過引入 Elasticsearch 叢集，解決了其他方案無法應對的資料檢索問題。
3、資料檢索：資料同步任務将需要檢索的字段從 HBase 同步至 Elasticsearch，借助于 Elasticsearch 的索引能力，為系統提供資料檢索能力。然後必要時反查 MySQL 擷取訂單完整資訊；
該方案雖然解決了資料膨脹帶來的擴容問題，也能夠支援資料檢索。但可以看到的是，客戶要維護至少兩套叢集，關注兩處資料同步任務，該方案的系統複雜度很高，運維成本也會很高。此外，這個方案依然不能對資料的流批處理、資料 ETL 再加工提供支援。
傳統訂單架構總結
總之，MySQL 分庫分表方案無法解決資料膨脹帶來的擴容問題。基于 MySQL + HBase 的架構在資料檢索上面存在明顯短闆。而 MySQL + HBase + Elasticsearch 的方案，雖然能夠解決擴容和資料檢索問題，但其系統複雜，維護成本高；另外，這種方案無法對資料分析工作、資料再加工 ETL 工作提供有效支援。而 MySQL + Tablestore 不僅解決了擴容問題、檢索問題，還支援資料流批處理以及 ETL 再加工工作，且系統複雜度低，運維成本低，能夠滿足大規模訂單系統的各項需求。
MySQL + Tablestore 方案
表格存儲（Tablestore）是阿裡雲自研的多模型結構化資料存儲，提供海量結構化資料存儲以及快速的查詢和分析服務。詳情見
什麼是表格存儲MySQL + Tablestore 後，可以很好的滿足大規模訂單場景下遇到的各種需求。其整體架構圖如圖。
MySQL 處理訂單的寫入和近期資料的基本讀取，并且利用資料同步工具如 DTS 将資料實時同步給 Tablestore。在 Tablestore 中，利用其二級索引和多元索引，可以處理檢索需求。通過 DLA，可以實作使用 SQL 直接查詢 Tablestore。Tablestore 的通道服務可以對接 Spark streaming 以及 Flink，可以實作實時資料分析。将 Tablestore 和 ODPS 對接，可以很便捷的實作對訂單資料的 ETL 作業。而結合 OSS 和 Tablestore，可以實作訂單資料的歸檔，并且可以在 OSS 中實作全量曆史資料的分析工作。
資料同步
傳統的訂單架構中，開發者不可避免需要處理資料同步進入 HBase 或者 Elasticsearch 之類的工作。這不僅加重了開發者的開發工作，也提高了運維難度。在 Tablestore 中，阿裡雲提供 DataX、Data Transmission Service（DTS）、Canal 多種資料同步工具完成資料從 MySQL 到 Tablestore 的同步工作。使用者隻需要進行少量的開發和配置工作就可以完成資料實時同步。操作友善簡單，實時性高，大大降低了維護成本。詳情請參見文章：
基于 MySQL + Tablestore 分層存儲架構的大規模訂單系統實踐-資料同步 DTS 篇 基于 MySQL + Tablestore 分層存儲架構的大規模訂單系統實踐-資料同步 Canal 篇資料檢索
Tablestore 提供了二級索引和多元索引來支援資料的檢索。二級索引可以完成基于主鍵列和預定義列的資料查詢，例如查詢使用者過去一個月成交的訂單情況。而多元索引，基于反向索引和列式存儲，對外提供了更加強大的資料檢索功能，他解決大資料的複雜查詢難題。它可以實作如搜尋購買過某産品的使用者這樣的需求。
Tablestore 的多元索引補齊了 MySQL、HBase 等在搜尋上面的短闆。而相對于 Elasticsearch，多元索引不再需要使用者專門維護叢集、維護資料同步任務，成本更低。詳情請參見文章：
基于 MySQL + Tablestore 分層存儲架構的大規模訂單系統實踐-訂單搜尋篇基于SQL的資料分析
Tablestore 以多種方式支援 SQL 對 Tablestore 中資料的讀寫。若想直接讀取 Tablestore 中的資料，建議直接使用 Tablestore 的 SQL 支援能力進行操作；而若希望進行多資料存儲的聯邦查詢，推薦使用 DLA 所支援的 SQL。對于兩種形式的SQL，Tablestore 都利用多元索引對其進行了充分的優化。擁有 SQL 處理能力，開發者可以更加高效率的進行代碼開發、代碼遷移工作。直接使用 SQL 查詢 Tablestore 也會為 MySQL 主庫解除安裝流量。詳情請參見文章：
基于 MySQL + Tablestore 分層存儲架構的大規模訂單系統實踐-SQL 查詢和分析 基于 MySQL + Tablestore 分層存儲架構的大規模訂單系統實踐-基于 DLA 的聯邦查詢實時資料分析
Tablestore 的通道服務，可以将 Tablestore 庫中資料的變化傳入通道。使用 Spark streaming或者 Flink 等流式資料處理工具對接通道，可以實作例如統計實時成交額這一類的實時資料分析需求。詳情請參見文章：
基于 MySQL + Tablestore 分層存儲架構的大規模訂單系統實踐-資料流計算篇曆史資料分析
Tablestore 可以将資料投遞到 OSS 系統，這樣可以完成訂單的歸檔需求，并且利用 OSS 系統對接 Spark ，可以完成對全量曆史資料的分析工作。這樣，在 Tablestore 中存儲近期資料，在 OSS 中存儲全量曆史資料，以 OSS 來支援涉及全量曆史資料的分析工作。詳情請參見文章：
基于 MySQL + Tablestore 分層存儲架構的大規模訂單系統實踐-曆史資料分析篇ETL資料再加工
通過将 Tablestore 資料接入 ODPS ，可以利用 ODPS 強大的資料處理能力，更便捷的對資料做 ETL 作業，進行資料的再次加工。詳情請參見文章：
基于 MySQL + Tablestore 分層存儲架構的大規模訂單系統實踐-資料處理ETL篇總結
本文簡要介紹了基于 MySQL 結合 Tablestore 的大規模訂單系統方案。這種方案支援大資料存儲、高性能資料檢索、SQL搜尋、實時與全量資料分析，且部署簡單、運維成本低。
希望本次分享對你設計資料架構有幫助，如果希望繼續交流，可以加入我們的開發者技術交流群，可搜尋群号『11789671』或『23307953』，亦可直接掃碼加入。
