來源：京東技術
導讀
在京東物流技術中臺架構升級專案中，物流交易體系以新的接入-交易-履約-執行四層架構進行重新搭建，其中交易訂單負責物流與客戶之間產生物流服務契約的單據流量收口，同時承載向下遊物流履約層分發的職責。在這個大的背景下，交易需支撐日千萬訂單儲存，如何保障訂單資料基座高擴充套件、高可用、高吞吐？

01

訂單系統概述

在今年的敏捷團隊建設中，我透過Suite執行器實現了一鍵自動化單元測試。Juint除了Suite執行器還有哪些執行器呢？由此我的Runner探索之旅開始了！

1.1 業務範圍

服務業務線：快遞、快運、中小件、大件、冷鏈、國際、B2B合同物流、CLPS、京喜、三入三出（採購入、退貨入、調撥入、銷售出、退供出、調撥出）等。

1.2 訂單中心價值

1、解耦（提升系統穩定性）

原系統：交易與生產耦合在一起，業務新增需求，涉及上下游多個系統。ECLP、外單、運單、終端系統等。多條業務線的邏輯耦合在一起，單一業務條線的需求改動，涉及原系統中其他業務線的關聯改造。

新系統：交易與生產運營解耦：交易相關的需求在訂單的域內解決；生產側的需求，在生產域內解決，減少上下游的相互影響。

業務條線接耦：不同業務線，業務流程不同，單一業務條線的需求改動，只在具體的流程中做迭代更新，不影響其他業務線。提升整個流程和業務的穩定性。

2、提升新業務接入速度

訂單中心向前臺提供可複用的標準能力，提升新業務的匯入速度。

訂單中心將原系統中的大應用，拆分、抽象為多個小的應用組合，並支援不同場景下按需編排業務流程。新業務透過對中臺公共標準能力的複用，可快速接入訂單中心，避免相同功能的重複建設。

3、提供全域性化統一資料模型

原系統：訂單分屬於多個系統，外單、ECLP、大件系統，有多套資料庫，業務語義不統一，不便於資料化建設。

新系統：訂單中心統一定義訂單的標準資料模型，讓不同業務的資料，沉澱在同一系統，減少訂單域相關功能的重複建設，避免資源浪費，打破部門壁壘。使得資料和流程可以集中得以管理和最佳化，為集團經營分析、預測京東未來的創新空間，提供訂單域的標準資料。

02

架構介紹

理解，首先 MCube 會依據模板快取狀態判斷是否需要網路獲取最新模板，當獲取到模板後進行模板載入，載入階段會將產物轉換為檢視樹的結構，轉換完成後將透過表示式引擎解析表示式並取得正確的值，透過事件解析引擎解析使用者自定義事件並完成事件的繫結，完成解析賦值以及事件繫結後進行檢視的渲染，最終將目標頁面展示到螢幕。

2.1 整體架構設計

交易日均千萬訂單的儲存架構設計與實踐圖1.整體架構

透過技術中臺架構升級專案，將交易體系以新的接入-交易-履約-執行四層架構進行重新搭建。其中交易訂單負責物流與客戶之間產生物流服務契約的單據流量收口，同時承載向下遊OFC（訂單履約層）分發的職責。

2.2 實時資料層架構設計

2.2.1 系統互動圖

系統互動如下：

交易日均千萬訂單的儲存架構設計與實踐圖2.系統互動示意

訂單中心的標準介面在上層做了單據收口，同時在資料層也做了統一的收口。

將業務架構與資料解耦，分散式資料庫、快取、一致性等高可用、高效能設計從業務架構範疇剝離，使業務架構聚焦在業務自身。

持久化系統：用於支撐接單、訂單修改、訂單取消、訂單刪除等資料持久化。

搜尋系統：提供訂單詳情查詢、訂單列表查詢、訂單狀態流水查詢、判斷是否百川訂單等服務。

中繼系統：資料樞紐，透過消費訊息佇列將訂單資料寫入Elasticsearch、HBase、MySQL。

資料對賬系統：用於對比多套儲存中介軟體的資料是否一致，以保障資料最終一致性。

資料同步系統：將訂單列表查詢所需的查詢條件和列表展示欄位從老系統同步至訂單中心，用於解決因切量過程中訂單資料存在於新老系統中而分頁困難的問題。

2.2.2 技術架構圖

交易日均千萬訂單的儲存架構設計與實踐圖3.技術架構圖

【讀寫分離架構】採用讀寫分離架構模式（CQRS），將訂單讀寫流量分離，以提高查詢效能和可擴充套件性，同時達到讀、寫解耦。
【快取】使用分散式快取Redis快取熱門訂單資料以及與訂單相關的資訊提高併發和響應速度減少對HBase的訪問，同時，透過主、備、臨時3套高效能快取以提升系統容災能力。
【訊息佇列】使用訊息佇列JMQ實現非同步處理訂單提升系統吞吐量，同時流量削峰減輕直接請求ES、HBase、資料庫的壓力。將不同業務場景(如下單、回傳)使用不同的Topic進行隔離，可以更好地管理和維護；將不同業務使用不同的Topic隔離，可以實現訊息的並行處理和水平擴充套件，提高系統的吞吐量和效能。
【複雜查詢】使用搜尋引擎Elasticsearch解決訂單複雜查詢，先透過Elasticsearch獲取訂單號，然後根據訂單號查詢分散式快取Redis+列式資料庫HBase。
【低成本持久化儲存】採用HBase列式資料庫以支援海量資料規模的儲存和極強的擴充套件能力。
【資料一致性】透過強事務、最終一致、冪等、補償、分散式鎖、版本號等實現。
【多租戶架構】系統中採用多租戶資料模型，將租戶的資料分離儲存，以確保資料的隔離性和安全性。根據不同租戶的需求動態擴充套件系統的容量和資源，可以支援系統的水平擴充套件。透過共享基礎設施和資源，多租戶架構實現了更高的資源利用率和降低成本。

2.3 設計優勢

2.3.1 高可用

應用伺服器、MySQL、Redis、HBase、JMQ等均跨機房部署；ES單機房部署，搭建ES主備雙機房叢集
隔離、限流、熔斷、削峰、監控

2.3.2 高效能

高效能快取
非同步化

2.3.3 海量資料處理

分庫分表
冷熱分離
列式儲存(HBase)

2.3.4 資料安全

敏感資訊加密儲存，Log、Redis、ES、MySQL、HBase等均採用加密儲存，“誰儲存誰加密，誰使用誰解密”。

03

訂單資料模型

理解，首先 MCube 會依據模板快取狀態判斷是否需要網路獲取最新模板，當獲取到模板後進行模板載入，載入階段會將產物轉換為檢視樹的結構，轉換完成後將透過表示式引擎解析表示式並取得正確的值，透過事件解析引擎解析使用者自定義事件並完成事件的繫結，完成解析賦值以及事件繫結後進行檢視的渲染，最終將目標頁面展示到螢幕。

3.1 PDM模型

在訂單模型設計上，基於統一業務屬性、抽象通用模型、歸納共性實體的原則，將訂單模型主要分成了訂單的主檔資訊、訂單的貨品資訊、訂單的物流服務資訊、訂單的營銷資訊、訂單的財務資訊、訂單的客戶渠道資訊、訂單的收發貨資訊、訂單的操作資訊、訂單的擴充套件資訊等幾類。

圖4.

交易日均千萬訂單的儲存架構設計與實踐圖5.

3.2 模型擴充套件性

3.2.1 標準模型擴充套件性設計

訂單中存在幾十上百個標識欄位，若每次都採用新增欄位形式，訂單業務屬性、資料模型會大量膨脹，腐蝕模型，同時開發效率較低，故採用KV形式承接和儲存。將標識劃分到各個業務域中，如訂單標識、貨品標識、營銷標識等。

3.2.2 個性化業務模型擴充套件性

針對個性化業務，提供了一套可配置的資料庫欄位管理方案，透過開箱即用的一些設定，訂單在提交、修改、查詢時，可以根據業務身份+業務型別+業務欄位找到不同的資料模型以及資料擴充套件編碼，即找到儲存到哪張表哪個欄位。在每張表都預留N個擴充套件屬性，同一個擴充套件屬性，不同的業務身份+業務型別表示不同的含義，以此實現擴充套件儲存。

圖6.

04

未來及挑戰

理解，首先 MCube 會依據模板快取狀態判斷是否需要網路獲取最新模板，當獲取到模板後進行模板載入，載入階段會將產物轉換為檢視樹的結構，轉換完成後將透過表示式引擎解析表示式並取得正確的值，透過事件解析引擎解析使用者自定義事件並完成事件的繫結，完成解析賦值以及事件繫結後進行檢視的渲染，最終將目

4.1 訂單個性化查詢

個性化查詢需求增多，如模糊查詢、根據查詢條件實時聚合等需求，若ES索引都放在同一個叢集中，會影響整體叢集穩定性，但拆分後該業務資料無法與其他業務一塊查詢展示。

4.2 單元化架構

當前接單持久化TP99是47ms，在非跨機房情況下TP99是20ms，從資料來看，跨機房對效能影響很大。

交易日均千萬訂單的儲存架構設計與實踐圖7.

單元化，可以讓同一個使用者的相關請求，只在一個機房內完成所有業務「閉環」，不再出現「跨機房」訪問。單元化的部署方式，可以讓每個機房部署在任意地區，隨時擴充套件新機房。透過單元化，持續加強訂單平臺的基座穩固。

4.3 硬體成本控制

訂單日均單量不斷上升，資料量越來越大，隨之而來是硬體成本的增加，如何控制硬體成本增加，是當下及未來的一項挑戰。計劃透過資料歸檔、冷熱溫資料分層等方式來降低資料儲存成本。

05

總結