架构|一文读懂电商产品架构( 三 )

支付对账。对于先款后货订单，各类支付方式均设有支付额度限制，对公转账的方式也无法保证用户一定按照订单实收支付，因此存在实际支付金额不一定等于订单应收金额，所以需要经过对账系统完成对账。

4. 订单寻源履约中心介于交易流程和仓储流程之间的系统——将电商系统生成的数以万计的订单，按时下发给最适合的库房进行生产，就是订单寻源履约系统的职责。订单寻源履约中心由多个子系统或服务组成，包括拆分系统、分摊计算服务、转移系统、履约控制中心等。

订单拆分：对账成功后，订单会进入到寻源履约中心的第一个系统——拆分系统。拆分的场景主要有：生产维度（仓库不同、商家不同、配送方式不同···）、业务类型维度（实物订单、虚拟订单、生鲜订单···）等，该系统的职责是按照不同的规则将父订单拆分成多个子订单进行生产。拆分时会调用分摊计算服务计算每个新子订单的金额。
订单转移。订单拆分完成之后会流转到转移流程，订单拆分完成之后会生成不同类型的订单，经过转移之后，不同的订单要执行不同的生产时机、不同的生产地点、不同的生产流程。
针对虚拟订单，不用经由库房实际生产，直接由转移给订单中心或者虚拟业务对应的系统进行处理。
针对厂商直发订单和POP订单，因为这类订单都是由三方卖家发货或者工厂直接发货，转移系统会与对应的业务系统交互，生成供应商采购单或下传订单给POP对应的系统。
针对自营的订单，由于订单商品所属的仓库不同、配送时效不同、商品的类型不同（如生鲜如要走冷链库房生产）、用户指定送达时间等原因，转移系统会控制订单生产的时机（如一周后送达订单则需要控制不要立刻下传库房）、生产的流程，生产的仓库。
履约控制：履约控制系统负责控制订单生产的流程，将订单推送至对应的库房，并回传生产节点（拣货、复核、打包出库···）给前台系统；针对取消逆向订单，根据订单流转的不同节点做对应的控制：如订单未流转到仓库，则负责暂停订单下传，订单未出库则负责通知仓库终止生产、订单未派件则通知配送系统终止派件等。
订单下传。订单经过拆分、转移、履约控制后，按时下传到对应的库房进行生产。

以上就是电商全流程的介绍，全流程中的每个流程节点都是一个独立的、庞大的系统，本文只是介绍各个系统之间的流转关系和基本职责，详细的功能设计将在后续的系列文章中展开。
三、大型电商产品架构我们通过电商业务流程得到了系统流程，有了系统流程就得到了电商系统的基本功能模块，我们基于上面梳理出来的基础功能模块，再从系统全局的角度进行扩展和做更细粒度的拆分，将最终拆分出的功能模块按照架构图的逻辑进行组织，就得到了一下产品架构图。

文章插图
（图片过大无法正常显示，请用电脑放大查看）
这张架构图的组织逻辑比较简单（可结合架构图对比查看）。
从上到下分别是：用户端系统>运营系统>履约系统>生产系统>基础平台>BI系。
用户端系统：主要负责用户选购商品的需求，核心系统包括注册/登录、黄金流程和个人中心等；用户端系统属于前台系统，在产品设计上更注重用户体验、数据分析等。
运营系统：主要承载了内部运营的能力，核心系统包括用户管理、商品管理、价格管理以及营销管理等。
交易履约系统：交易履约系统是一个中枢系统，向上承载订单交易，向下控制生产履约，核心系统有订单中心和寻源履约中心，属于电商系统中比较黑盒的部分，界面较少，更多的是底层逻辑。