继续订单拆分，从服务化的角度，订单拆分业务可以做成一个单独的微服务，即拆分的框架和流程。
订单如何进入拆分系统
用户下单之后，可以先构建一个订单缓冲池，再加入订单管道——它是订单的全流程的管理，工作流的管理，它会负责去接到这张订单，然后把这张订单推送给订单的拆分系统，由订单系统进行相应的拆分操作。在这里，订单的拆分系统又被分为两块：一块是一次拆分，一块是二次拆分。
什么叫做一次拆分，而什么又称之为二次拆分？
一次拆分是把一些相关的订单全部在订单提交以后再拆分，相当于是一个独立拆单服务—即前面谈到的那次流程的升级，就用会把它做一个拆分的服务，直接拆分掉；而二次拆分需要做的，比如没有付款的订单（后付费），如果一次没有拆干净，会进入到一个定时任务里，即拆分队列里——这是一个大的订单池子。所有没拆干净的单子，都会进入到这个池子里，然后通过二次拆分——轮循看订单什么时候付款、什么时候满足了订单的拆分条件，再去进行拆分的这么一个流程。
订单拆分流程
通过获取订单信息，然后进行拆分，和构建。真正的订单拆分动作做的是——根据拆分的业务逻辑，按照业务逻辑的条件去生成满足仓储生产的订单。相当于构建子单之后将父单取消，再调取管道重新生成一张订单——即根据业务的条件，重新生成仓储可以生产的一些订单。同时，会有一些其他操作，比如取消父单。以上是拆分的一个大体的业务流程。
订单金额拆分
SKU（最小库存单位）拆分是一种，订单金额的拆分也是一种。在电商平台买过东西就会知道，平台经常会有不同类型的促销，最简单的直降，又满减、用优惠卷、积分兑换，还有各种各样的促销等等。比如买个东西，满199减100啊（活动预热），大家都会凑单凑到199。于是，用户就会买食品凑够199然后减掉100。假如用户买了10件商品，减了100元，那么具体这 100块钱怎么减呢？对于客户来说，他们不理会平台怎么操作这个优惠折扣，只要这100块钱在自己结算的时候抵扣即可。比如，用户花了200块钱，而实际只是收了用户100块钱，这就可以了。但对于平台来说，这100块钱并不是直接减100这样来登记的，它不在订单里，而是从商品的订单金额里，商品金额的比例来分拆优惠的钱--也就是拆单服务要做的工作。
拆单服务的基本原则就是按SKU的金额比例去分摊并取整数。这里面不光包括优惠，还有各种运费，虚拟资产（如积分）等。比如这次花了1000积分来抵扣10元，这1000个积分抵的这10块钱就会分摊到用户具体的每一个SQ上（Sales-order Quantity 销售订单数量）。现在，前台会直接显示减几块钱几块，记得不是特别细，其实在后台都是会具体的记录每行减多少钱，包括运费——像我们在北京，买自营的商品体验不是特别那个深，如果在偏远山区，一般是要加收特殊的运费，或者买商家的商品会收运费，运费怎么分摊也都是在这里计算的。
拆分系统最终对外提供了一个订单金额查询服务，一般来说，售后系统，比如发票系统，还有外围系统都会去调这个服务。举例，售后系统中，用户要退的一个东西，那用户买的时候是什么钱？买的时候用了什么样的优惠？优惠摊了多少钱？最后售后要退款的时候实际退多少钱？都是通过拆分系统这么一个金额计算的服务去算出来的。
通过以上的解说，订单拆分就是按照客户履约的行为，将订单拆成符合平台由此产生一系列的可生产的子单。所谓的生产对于自营平台来说就是定位的是不同库房；对于入驻商家来说，定位的是不同商家。订单系统最直接的两个下游系统，对于自营来说，下游系统就是WMS即仓储系统；对于入驻商家来说，下游系统就是平台下发给商家的订单系统（或者说订单系统客户端）。所以平台的单子都会发给这两个系统。
