电商系统架构全链路解析

1、电商系统可能是世界上最复杂的业务系统

说个有意思的小事，和一位PM同行聊工作，问我电商做的如何，我说并不是一件易事。对方哈哈一笑，说电商不就那么回事吗，有啥难的，是个PM都能做，我嘿嘿一笑，不作辩解。

光说中国电商，发展至今已有20多年的历史，且一直处于高速的发展和竞争当中，时至今日，都不可妄语尘埃落定，对于大型公司来说，电商仅为销售渠道之一，而在此基础上衍生出来的研、产、供、销、服整套的信息系统体系，才是支撑其运作的核心。当你从销售或是用户这个点来看电商，会觉得无比简单，而当你从整个体系的面来看电商时，会觉得没有边际。

2、一图描述电商架构

以下仅展示与电商直接有关联的系统模块，而对于一个大型企业的IT系统架构，是远不止下图中包含的系统单元的。随着业务的发展，每个系统单元都需要长时间迭代，其成熟的过程中凝聚了大量的人力物力，鄙人只能管中窥豹，从概念层面来描述，每个系统模块的大致功能。

3、从一个订单开始说起

由一个用户下单的主干流程，可以看出所有系统之间的交互流程，直接画图说明。不同公司的业务、团队划分都不同，故此IT架构的划分也不是绝对的，举例来说，支付业务，我在图中划分到了交易中心，而现实中也有并入结算中心的。

4、库存怎么来的？

5、各业务单元概念及作用简析

由以上2个主干流程和系统架构图，可以对电商系统的全链路有个基础了解，下面再用文字描述一下各个系统单元的概念和作用。每个模块的PRD都可以单独成章，在一篇文章当中也不可能描述所有细节，但对于部分系统的解析，可以在我的博客中看到，我也会持续更新。

6、大前台

6.1各个销售前端

一家公司往往有多个销售渠道，线下有不同类型的加盟店直营店等等，线上也有不同模式的电商，而这些触点用于直接让用户接触到商品。拿阿里巴巴来说，在淘宝体系下本身有天猫超市、普通商家端、淘宝直播、天猫App等等。

6.2 CMS

除了商品页面之外网站和APP还有其他的内容页面，比如说店铺的首页、维修退换政策、活动页面等，这些都要用单独的内容管理系统去承载，直观的了解来看大家都用过QQ空间，其中空间的装修就可以理解为是一个简单的cms系统。

6.3交易中心

交易中心其实是一个技术的中间件，所有和销售前端交互的系统都要通过交易中心来完成，此外还要承担一些用户主要交易流程当中的逻辑，举例来说，下单之前需要先调用库存服务，查询库存，用户加入购物车之后，要通过调用营销中台来计算购物车内商品活动后的总价等。

7、大中台

7.1商品中心

简单来说，商品中心就是一个商品的数据库，会在所有的业务系统当中都用得到，其来源包含第三方的和自主建立的。主要包含的有三层关系，第1层关系是类目，产品的类目分前台类目和后台类目可以在不同的渠道下自定义支持。第2层关系是spu和sku的关联。第3层关系是属性，属性可以绑定在类目下，也可以绑定在spu下或者是sku下，子会继承父的商品属性，相关的文章也有很多，我的博客《从小卖铺开始，聊聊商品和库存模型》中也有大致介绍。

7.2营销中台

营销中台主要包含两大块，第1块为活动，第2块为优惠券码。可以针对不同的用户、产品、渠道进行优惠活动的设置，对于用户感觉来说，优惠活动一般是在购物车当中呈现，而优惠券码一般是在结算时扣除相应的金额，我的博客《非平台型营销中台搭建全貌》一文中也有概述。

7.3库存服务

库存一般会分为三级，渠道当前可售库存、产品可售库存、仓库实际库存。其解决的核心问题是，用户从下单开始到最终扣除仓库库存，在不同环节应该如何去扣减，从而达到最高的库存使用效率，我的博客《销售库存模型讲解》一文中也有介绍。

7.4 wps

WPS解决的核心问题是，商品应该如何调度。具体来看，当订单接收之后，应该由哪个仓库来进行满足，用户在商城界面看到是否有货，应该如何判断。我的博客《多仓模式下的分仓和拆单》一文中也有介绍。

7.5 Express

Express解决的问题是，当商品的发货任务已经分到了具体的仓库，我们应该使用哪一家的快递，才能同时兼顾成本和速度。因为在不同地区的仓库，快递公司的服务响应、成本是不一样的。其核心逻辑是，对于不同的仓库，在路线的配置上选取不同的快递公司。

7.6会员中心

会员中心其实和我们玩王者荣耀的用户等级很像，是对不同的渠道提取出共性的用户升级规则，又或者是付费型会员。举例来说，一个游客用户看到的商品价格是100元，当游客登录后，会发现用户的会员等级是付费会员，此时前端页面会调取商品中心当中的会员价格再呈现给用户，此时用户看到的商品价格是80元。

7.7发票中心

一般来说，业务发展到全球化的时候，才会诞生发票中心。因为不同的国家才会对于开票的规范有不同的要求。其核心流程就是两个，一个是开票，另一个是冲红，但是在不同的业务下，可能对于开票和冲红的时间点会有不同，这一点一般是由订单中心来进行定义。

7.8客服服务

这一点比较好理解，一般客服系统的搭建现在分为三大块。第1块是在线聊天客服，用户发起的聊天会分配给系统后台的人工坐席。第2块是智能知识库，会将用户所有的常见问题汇总到知识库当中，给用户自动推荐，从而减少人工客服的压力。第3块是客服的系统操作台，客服可以帮助用户人工的干扰一些订单的进程，比如修改价格建立退换单等等。

7.9秒杀

由于中国用户的数量众多，特价商品的活动，几乎都会用秒杀的方式来进行。故此秒杀已经成为了各个中大型电商的基本服务，其核心逻辑就是在于多极缓存，逐级筛选用户。

7.10风控

风控的应用场景其实有很多，这里只谈谈下单场景的应用。如果我们判断出一个高风险的订单，这个订单将会被系统给拒绝，一般我们会从两个方面去判断，一个是用户历史的行为，一个是用户当前的下单风险，前者来说，我们可以看用户的账号是否高风险，是否有比平常人更高的拒收率等等，后者来说一般是判断用户是否存在技术刷接口的可能性，比如判断这个用户在当前下单的时候，是否请求过于频繁。

7.11结算

一般包含三个步骤，对账清分和结算。将我们从第三方支付获取的货款进行自动结算，告知财务一个结果，从而打到供应商的账户当中，一般会和集团的OA审批流进行结合。

7.12数据中心

所有系统的数据都会共享给数据中心然后基于数据去进行各种场景的组合和应用。举例来说最常见的是用户画像平台，运营人员需要通过用户画像平台去筛选出用户的偏好，来进行精准营销。举例来说，当我们想主推一款手机壳的时候，运营人员可能先去筛选出最近30天购买过新手机、加购过手机壳、最近30天没有购买过手机壳的用户群ID，然后给这些用户去发PUSH。

7.13订单中心

所有渠道的订单都必须汇聚到订单中心，然后进行统一处理，举例来说，我们的天猫店，淘宝店，抖音店，快手店以及自营电商平台，用户提交的订单都会汇聚到订单中心，然后再进行下一步的流转和操作。同时财务的结算也会以订单中心的订单状态为标准，这样保障所有系统的上下游数据都有一个通用的数据源。

8、大后台

8.1WMS

和某一个具体仓库相关的所有业务流程都在wms管理，具体包含的业务流程有三个出库，入库和上架。出库的类型有很多种，比如说电商订单的类型就是购买出库，当仓库接收到出货单以后会打印分拣单，仓库员工会根据分拣单对于货物进行拣货、打包等操作，最后将打包完毕的商品放在出库区等待承运商拉走。入库的类型也有很多种，一般最常见的就是采购入库。而商品上架则是需要先根据仓库的库位管理划分很多的区域，然后再将不同的商品商家都不同的区域。

8.2XMS

XMS中文名称叫售后管理系统，售后的类型有三种退换修，然而退换修需要有不同的备件库，可能是更换零件进行维修，也可能是直接更换整机。如果是退货的话，则需要在XMS当中判定用户发回的货是满足退货条件的，此时在XMS当中会告诉订单中心，从而再触发支付和结算业务的退款流程。

8.3用户中心

用户中心也就是存储用户基础数据的地方，同时需要承担用户的注册登录找回密码，更换手机号的相应流程，对于不同的国家，需要支持不同类型的注册方式，比如手机号注册和邮箱注册或者是谷歌账户注册，同时在技术方案上也要支持不同类型的前端产品，比如说支持Web、Webview、APP等。对于不同风险等级的业务，也要支持不同类型的注册方式，比如只是电商业务的话，只需要手机号注册即可，但如果是金融信贷业务，则还需要支持人脸识别或者是身份证认证等。

8.4 SRM

SRM的中文名为供应商管理系统，核心逻辑是对于不同的供应商进行打分和评判，筛选初优质的供应商。同时对于询价、采购、物流、财务等供应流程进行数据化管理。