服务业务线：快递、快运、中小件、大件、冷链、国际、B2B合同物流、CLPS、京喜、三入三出（采购入、退货入、调拨入、销售出、退供出、调拨出）等
1、解耦（提升系统稳定性）
原系统：交易与生产耦合在一起，业务新增需求，涉及个上下游多个系统。ECLP、外单、运单、终端系统等。多条业务线的逻辑耦合在一起，单一业务条线的需求改动，涉及原系统中其他业务线的关联改造。
新系统：交易与生产运营解耦：交易相关的需求在订单的域内解决；生产侧的需求，在生产域内解决，减少上下游的相互影响。
业务条线接耦：不同业务线，业务流程不同，单一业务条线的需求改动，只在具体的流程中做迭代更新，不影响其他业务线。提升整个流程和业务的稳定性。
2、提升新业务接入速度
订单中心向前台提供可复用的标准能力，提升新业务的导入速度。
订单中心将原系统中的大应用，拆分、抽象为多个小的应用组合，并支持不同场景下按需编排业务流程。新业务通过对中台公共标准能力的复用，可快速接入订单中心，避免相同功能的重复建设。
3、提供全局化统一数据模型
原系统：订单分属于多个系统，外单、ECLP、大件系统，有多套数据库，业务语义不统一，不便于数据化建设。
新系统：订单中心统一定义订单的标准数据模型，让不同业务的数据，沉淀在同一系统，减少订单域相关功能的重复建设，避免资源浪费，打破部门壁垒。使得数据和流程可以集中得以管理和优化，为集团经营分析、预测京东未来的创新空间，提供订单域的标准数据。
通过技术中台架构升级项目，将交易体系以新的接入-交易-履约-执行四层架构进行重新搭建。其中交易订单负责物流与客户之间产生物流服务契约的单据流量收口，同时承载向下游OFC（订单履约层）分发的职责。
系统交互如下：
订单中心的标准接口在上层做了单据收口，同时我们在数据层也做了统一的收口。
将业务架构与数据解耦，分布式数据库、缓存、一致性等高可用、高性能设计从业务架构范畴剥离，使业务架构聚焦在业务自身。
持久化系统：用于支撑接单、订单修改、订单取消、订单删除等数据持久化。
搜索系统：提供订单详情查询、订单列表查询、订单状态流水查询、判断是否百川订单等服务。
中继系统：数据枢纽，通过消费消息队列将订单数据写入Elasticsearch、HBase、MySQL。
数据对账系统：用于对比多套存储中间件的数据是否一致，以保障数据最终一致性。
数据同步系统：将订单列表查询所需的查询条件和列表展示字段从老系统同步至订单中心，用于解决因切量过程中订单数据存在于新老系统中而分页困难的问题。
敏感信息加密存储，Log、Redis、ES、MySQL、HBase等均采用加密存储，“谁存储谁加密，谁使用谁解密”。
在订单模型设计上，基于统一业务属性、抽象通用模型、归纳共性实体的原则，将订单模型主要分成了订单的主档信息、订单的货品信息、订单的物流服务信息、订单的营销信息、订单的财务信息、订单的客户渠道信息、订单的收发货信息、订单的操作信息、订单的扩展信息等几类
订单中存在几十上百个标识字段，若每次都采用新增字段形式，订单业务属性、数据模型会大量膨胀，腐蚀模型，同时开发效率较低，故采用KV形式承接和存储。将标识划分到各个业务域中，如订单标识、货品标识、营销标识等。
针对个性化业务，提供了一套可配置的数据库字段管理方案，通过开箱即用的一些设置，订单在提交、修改、查询时，可以根据业务身份+业务类型+业务字段找到不同的数据模型以及数据扩展编码，即找到存储到哪张表哪个字段。在每张表都预留N个扩展属性，同一个扩展属性，不同的业务身份+业务类型表示不同的含义，以此实现扩展存储。
个性化查询需求增多，如模糊查询、根据查询条件实时聚合等需求，若ES索引都放在同一个集群中，会影响整体集群稳定性，但拆分后该业务数据无法与其他业务一块查询展示。
当前接单持久化TP99是47ms，在非跨机房情况下TP99是20ms，从数据来看，跨机房对性能影响很大。
单元化，可以让同一个用户的相关请求，只在一个机房内完成所有业务「闭环」，不再出现「跨机房」访问。单元化的部署方式，可以让每个机房部署在任意地区，随时扩展新机房。通过单元化，持续加强订单平台的基座稳固。
订单日均单量不断上升，数据量越来越大，随之而来是硬件成本的增加，如何控制硬件成本增加，是当下及未来的一项挑战。我们计划通过数据归档、冷热温数据分层等方式来降低数据存储成本。
