猿设计23——真电商之订单中的那些秘密

经过前面一段时间的学习，相信你对类目、属性、商品、促销、库存、购物车的业务和设计有了一定的了解。上一章节我们也讨论了订单的实体信息。

似乎应该去讨论下单的流程问题了，不过在这之前，还有一下事情需要来解决。今天是订单的第三个章节，猿人工厂君打算和你聊一聊订单那些你必须知道的小秘密。

提起订单有哪些你必须知道的秘密，也许你会说，猿人工厂君又在卖关子了，其实今天要讲的内容，对于经验十分丰富的朋友来讲，实在算不得什么，但是离开了这些东西，电商就真的不好意思称为电商了。

我们先来说说提交订单的一个场景。说用户A一次性买了很多东西，分别属于不同的商家，提交订单之后，却只有一个订单，那么个订单就会带来一些问题？订单中的货物由谁来配送呢？

相信细心的朋友已经发现了，猿人工厂君在抽取实体的时候，给每一个订单相关的实体分配了一个parentOrderId的属性，从字面含义都能猜到，是父单号的意思。那么很明显，一个订单很可能会被拆分开来噢。

是哒，必须给拆了，要不然商家怎么去发货啊？大家都用一个订单号，然后各种去处理相应的商品发货问题？很明显一个订单会被拆成多个订单了。那么猿人工厂君再提一个问题——什么时候拆？

有的朋友说，下单的时候生成多个订单，每个订单包含一个商家的商品不就好了？这样子做只是理论上可以，而且暴露你毫无经验的实锤了。下单时就拆开，那么请问支付怎么办？用户挨个去支付吗？这样做的后果很明显让客户更加麻烦——注意，我说的是客户不再提的是用户（给钱了才叫客户）。

客户觉得麻烦之后，自然可能临时改变主意，不支付某些商品。或者直接找到平台优惠的一些漏洞，先给优惠拿到手，剩下的你们自己玩耍吧。所以什么时候拆——支付之后拆（除了货到付款）！客户给完钱了，确定买了，然后需要生产履约了，拆开它就好了。

那么第二个问题可以开始讨论了——按什么业务规则去拆分?第一个维度，按商家，大家都知道了。不按商家拆分，根本没法玩儿。那么第二个维度是什么呢？注意到storeId没有？按仓库拆分。仓库和地址是有关系的，其实在下单的时候，还涉及到一个库存的问题——从近的地方发货，自然成本低啊，要不建立仓库的意义何在？

这两个维度其实基本上地球人都知道的。那么猿人工厂君再说说你可能不知道的了——从运输的角度出发，不同的货物可能寻找不同的供应商比较合适。那么就是按物流供应商来拆分也会是一个考量。

还有没有其它的因素？当然有，比如一个商家搞了活动，优惠力度比较大，订单金额也比较大。有的人买完东西看着一笔订单比较大，可能反悔退货的。或者说他仅仅是看中了某一个货物，又想利用漏洞来套取优惠，那么在设计拆单的时候可以考虑按金额拆、按优惠拆等等策略了。甚至在生产上搞点儿小手段——赠品后发也是有的噢。好了，我们来梳理下拆单的逻辑吧。

接下来我们需要聊一聊一个几乎被人快要被人聊烂掉的话题——订单号生成。无可厚非，在下单之前有一些业务逻辑其实是依赖订单号的。比如库存预占，甚至有一些特殊的促销计算和扣减也是需要订单号的。

关于订单号如何生成的话题，最烂大街的应该是某些机构不知道处于什么目的搞出来的“雪花算法”生成订单号。猿人工厂君就一句话放在这里——但凡面试时听到“雪花算法”生成订单ID的说法的，几乎就是那啥刚完事儿出来找工作的。

在真正的业务场景中，订单号是存在一些秘密的，各家电商系统在设计和考虑的时候都有所不同。但是以下两点应该是一致的。

第一，订单单号应该有它的特殊含义。看着订单号就大致能确定，订单是哪条业务线的订单。

第二，订单单号和用户存在一定的联系。为什么会这样？一个正常运转的电商系统，订单是很多的，在存储时，时需要采取策略的，比如分库分表，按用户分库分表肯定会是一个考虑的维度。至少在被考虑的维度上单个访问信息，可以快速定位路由。

我们可以通过下面这个例子来说明这个小秘密。

比如指定订单单号第三位和第四位代表某一类型业务，比如第三方订单，第789位为路由值。那么根据10020003400001这个订单号就能一目了然的看出，是什么订单，是哪个路由上的订单了。当然猿人君也就是举了个实际的例子，具体的规则嘛嘿嘿真是商业秘密了。

也许你会问，内部单号怎么唯一取得的？嘿嘿，最稳妥的还是数据库的方式来保障了，你会喷，性能上怎么行？比“xx算法差远了”。不过怎么来实现具体的细节，在具体实现时来体现，没有差的，只有不会设计的。

以上就是订单业务中，你必须要知道的两个小秘密了，这样的秘密其实还有很多噢。下一个章节，我们一起来聊一聊订单流程的那些事情了。