背景
在电商交易中台团队工作了一段时间，越发觉自己需要学习的东西还有很多，因此想要定期整理、反思一下所见、所想，因此先从接触的订单中心开始。
订单是什么，我所理解，订单就是交易行为的记录。是用户某一刻在平台上购买的凭证，订单当时对应的商品、优惠等信息是不可更改的。换一种说法就是订单是交易行为的快照。在按下”快门“（下单）的一刻，所有信息都被锁定了。
订单在公司业务中也是起一个大上下文的作用，保存着完整的元数据，下游需要时自取。因此对订单的设计注定是更加看重扩展性的。不然每来一个新的业务，都需要通过加字段或者和产品说这个需求做不了，那就证明订单的设计还有待提升。
目标
订单中心要能搭载整个电商平台的订单，使用统一、稳定的模型支撑不同的业务。提供稳定、可靠、原子的订单api服务。
模型设计说明
订单模型该怎么设计？订单模型该考虑哪些点？订单表该有哪些字段？
订单表的设计不是腾空降下来的，每个点、每个字段都应该是有凭有据的。
三级订单
订单联系着这么多领域，不同领域关心的订单维度不一样，如何更好的服务着各个领域呢？
为了订单引入了三级订单模型：
支付级订单(L1订单)、店铺级订单(L2订单)、商品级订单(L3订单)。
支付级：L1订单，对应的用户付款，也就是合并支付单，用户的一次交易行为实付款就在这边，平台级的优惠也记录在此。
店铺级：L2订单，对应店铺，下单按照店铺的维度拆分而得，也是c端用户可见的订单，店铺级优惠、运费记录在此。（仔细看看京东、淘宝都不是都是按照此维度拆单的）
商品级：L3订单，对应商品，下单按照sku的维度拆分而得，商品级优惠记录在此。
三级订单之间通过”父子”的方式相互关联，店铺级订单的父订单是支付级，商品级订单的父订单是店铺级。
支付级 1:n 店铺级 1:n 商品级
三个维度的订单，其实大部分字段是相同的，因此就不创建三张表，而是合并在一个订单中，通过level区分到底是哪一级订单。
订单模型详细设计
那么支撑电商平台全业务的订单表主要包含哪些字段呢？我使用脑图的方式列几个大概点
这个多信息，订单都要记，订单表那得有多少字段啊？
仔细分析，非也。有很多数据是无需作为单独字段存储在订单主表的，就比如商品、店铺的完整快照，作用只是为了留存，完全没有必要放在主表中。
一些平常偶有查询需求的信息，可以放在订单的扩展字段中，使用大json保存，方便扩展，可读性也好。
不过排除了这些”冷“字段后，订单表还是有很多字段，毕竟是要作为订单中心支撑电商全业务，字段比一般业务的表要多，也无可厚非了。
容量规划
目标是支持平台未来n年的发展，因此分库分表是必须的，按照电商数据的使用场景维度，划分为买家库、卖家库是最为常见的。
买家库，顾名思义，根据买家id作为分片键路由到某一分表，但订单号作为订单表的”硬通货“，其使用场景比买家id还要多。因此订单表的分片键需要有两个（买家id和订单id是或的关系）。一次sql操作条件必须包含买家id或订单id，两个分片键怎么保证路由到同一分表呢？数据一样，路由算法一样，那么肯定会路由到同一分表，因此想到在订单号中添加用户id就是一个可行的方案。路由函数用最简单的分片键取模分片数。根据分片的数量来计算出订单号中冗余买家id的位数，比如我需要分256片，那么订单号末尾增加用户id的后三位即可。
什么，你问我有支持这种两个分片键的分库分表中间件吗？阿里云drds奉上 阿里云drds，range_hash拆分函数。
什么，你问我有免费的吗？sharding-jdbc 改造下路由策略即可，我司就是之前用的drds，后来迁移至自研sharding-jdbc上。
差点忘了，还有卖家库。想象一下，如果我们是下单系统在下单时不仅要插入买家库，还有卖家库，那下单接口的tps就会严重受限，why？创建订单本就是一个很重的操作，两个很重的sql执行，又慢，大促时还增加了数据库抖动造成下单失败的概率。
我们仔细分析下场景，买家库服务于c端用户，数据实时性要求高，我下了一单，去订单列表结果发现没有？那问题就严重了。
但用户下了一单，卖家在后台列表短时间没看到，这是完全可以接受的，卖家是为了发货，就算实时看到，也不能立马发货。
因此在卖家库数据的产生上，我们使用异步的方式优化。
主要方案是，监听买家库的binlog，插入到卖家库中。卖家库不允许直接修改，完全由binlog保障与买家库的一致性。
方案的优势：提升了下单接口的性能，使用binlog + 消息解耦了卖家库数据的产生。
方案的弊端：一致性不能完全保障，后续需要对账系统进行严格保障。大促数据量大，卖家库可能会有较大的延时。
总结
我认为电商订单中心要想设计的”好“，首先对电商全链路业务必须有一定的了解，不然可能考虑点会欠缺一点，还可能会产生一些额外的过度设计。建立稳定的数据模型与业务模型，系统可以慢慢不断实践、总结、优化，最终朝着目标慢慢迭代。