共计 2711 个字符，预计需要花费 7 分钟才能阅读完成。
一、订单零碎概述
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 转载请注明起源
