一、訂單系統概述

1.1 業務範圍

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

1.2 訂單中心價值

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

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

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

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

2、提升新業務接入速度

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

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

3、提供全局化統一數據模型

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

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

二、架構介紹

2.1 整體架構設計

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

2.2 實時數據層架構設計

2.2.1 系統交互圖

系統交互如下：

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

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

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

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

中繼系統：數據樞紐，通過消費消息隊列將訂單數據寫入Elasticsearch、HBase、MySQL。

數據對賬系統：用於對比多套存儲中間件的數據是否一致，以保障數據最終一致性。

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

2.2.2 技術架構圖

• 【讀寫分離架構】採用讀寫分離架構模式（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等均採用加密存儲，“誰存儲誰加密，誰使用誰解密”。

三、訂單數據模型

3.1 PDM模型

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

3.2 模型擴展性

3.2.1 標準模型擴展性設計

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

3.2.2 個性化業務模型擴展性

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

四、未來及挑戰

4.1 訂單個性化查詢

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

4.2 單元化架構

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

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

4.3 硬體成本控制

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

作者：京東物流 王衛東

來源：京東雲開發者社區 自猿其說Tech 轉載請註明來源