浅析电商系统架构
时间：2023-03-16 12:36:01 | 来源：电子商务
时间：2023-03-16 12:36:01 来源：电子商务
1. 电商系统概况
此处省略一万字........ ...
2. 整体架构
电商大致可以分为：
前台，中台， 和后台前台：主要面向客户以及各个终端销售者，实现营销推广以及交易转换
中台：在系统中被共用的中间件的集合。它存在的目的就是更好的服务前台，包含技术中台、 业务中台、组织中台、数据中台等一系列的数据平台带来共享和便捷性，中台的一个核心就是共享性
后台：数据库怎删改查， 各渠道数据获取等
不同公司， 不同业务，不同场景其划分会有所不同。
3. 一个订单的流程
4. 库存来源
5. 大前台：
前台是直接展现给用户的看和操作的，崇尚用户体验的年代，让用户简单的学习和使用是基础准则。所以前台的功能尽量简单，复杂的规则都通过后端来解决。目前前台显示形式有PC的网站或者客户端、移动的APP或H5。以后随着科技的发展也有可能出现万物皆屏的前台。前台基本就是业务的表现层，不会处理过多的逻辑，不做说明。
6. 大中台：
- 商品中心
简单来说，商品中心就是一个商品的数据库，会在所有的业务系统当中都用得到，其来源包含第三方的和自主建立的。主要包含的有三层关系，第1层关系是类目，产品的类目分前台类目和后台类目可以在不同的渠道下自定义支持。第2层关系是spu和sku的关联。第3层关系是品牌，与类目建立一对多关系，用于发布商品和检索赏评，第4层关系是属性，属性可以绑定在类目下，也可以绑定在spu下或者是sku下，子会继承父的商品属性，相关的文章也有很多。
- sku/spu：sku的英文缩写为stock pepping unit,意思为库存量单位，是库存控制的最小可用单位，spu的英文缩写为standard product unit,意思为标准话产品单元，相信通过英文缩写已经很能够区分sku与spu之间的差距了，举个例子说明，如17新版的mac pro 13.3英寸、灰色为 i5 256g为一个sku，17新版mac pro 13.3英寸为一个spu
- 类目：类目是一个商品的分类，这个分类区分为前台分类与后台分类，后台分类是固定的，一般不会增改，是一个商品的固有分类，不会随时间或者营销而调整，前台分类对应为具有营销性质的商品的分类，如一件衬衫的后台分类为衬衫，其前端分类可能对应为新品上市
- 品牌：电商后台需要有对应的品牌库，一个品牌对应一个或多个类目，建立品牌库及对应到相应类目的好处在于发布商品时能提高效率及减少出错，另外在进行商品搜索的时候也可以通过搜索品牌来进行搜索
- 商品属性：商品属性区分为关键属性、销售属性、基本属性，关键属性为能确定商品唯一的属性，销售属性又称销售规格，如颜色、尺码等，基本属性如材质、生产日期、工艺等
2. 营销中台
营销中台主要包含两大块，第1块为活动，第2块为优惠券码。可以针对不同的用户、产品、渠道进行优惠活动的设置，对于用户感觉来说，优惠活动一般是在购物车当中呈现，而优惠券码一般是在结算时扣除相应的金额。
3. 库存服务
库存一般会分为三级，渠道当前可售库存、产品可售库存、仓库实际库存。其解决的核心问题是，用户从下单开始到最终扣除仓库库存，在不同环节应该如何去扣减，从而达到最高的库存使用效率。
4. WPS
WPS解决的核心问题是，商品应该如何调度。具体来看，当订单接收之后，应该由哪个仓库来进行满足，用户在商城界面看到是否有货，应该如何判断。我的博客《多仓模式下的分仓和拆单》一文中也有介绍。
5. Express
Express解决的问题是，当商品的发货任务已经分到了具体的仓库，我们应该使用哪一家的快递，才能同时兼顾成本和速度。因为在不同地区的仓库，快递公司的服务响应、成本是不一样的。其核心逻辑是，对于不同的仓库，在路线的配置上选取不同的快递公司。
6. 会员中心
会员中心其实和我们玩王者荣耀的用户等级很像，是对不同的渠道提取出共性的用户升级规则，又或者是付费型会员。举例来说，一个游客用户看到的商品价格是100元，当游客登录后，会发现用户的会员等级是付费会员，此时前端页面会调取商品中心当中的会员价格再呈现给用户，此时用户看到的商品价格是80元。
7. 发票中心
一般来说，业务发展到全球化的时候，才会诞生发票中心。因为不同的国家才会对于开票的规范有不同的要求。其核心流程就是两个，一个是开票，另一个是冲红，但是在不同的业务下，可能对于开票和冲红的时间点会有不同，这一点一般是由订单中心来进行定义。
8. 客服服务
这一点比较好理解，一般客服系统的搭建现在分为三大块。第1块是在线聊天客服，用户发起的聊天会分配给系统后台的人工坐席。第2块是智能知识库，会将用户所有的常见问题汇总到知识库当中，给用户自动推荐，从而减少人工客服的压力。第3块是客服的系统操作台，客服可以帮助用户人工的干扰一些订单的进程，比如修改价格建立退换单等等。
9. 秒杀
由于中国用户的数量众多，特价商品的活动，几乎都会用秒杀的方式来进行。故此秒杀已经成为了各个中大型电商的基本服务，其核心逻辑就是在于多极缓存，逐级筛选用户。
10. 结算
一般包含三个步骤，对账清分和结算。将我们从第三方支付获取的货款进行自动结算，告知财务一个结果，从而打到供应商的账户当中，一般会和集团的OA审批流进行结合。
11. 数据中心
所有系统的数据都会共享给数据中心然后基于数据去进行各种场景的组合和应用。举例来说最常见的是用户画像平台，运营人员需要通过用户画像平台去筛选出用户的偏好，来进行精准营销。举例来说，当我们想主推一款手机壳的时候，运营人员可能先去筛选出最近30天购买过新手机、加购过手机壳、最近30天没有购买过手机壳的用户群ID，然后给这些用户去发PUSH。
12. 订单中心
所有渠道的订单都必须汇聚到订单中心，然后进行统一处理，举例来说，我们的天猫店，淘宝店，抖音店，快手店以及自营电商平台，用户提交的订单都会汇聚到订单中心，然后再进行下一步的流转和操作。同时财务的结算也会以订单中心的订单状态为标准，这样保障所有系统的上下游数据都有一个通用的数据源。
13. 供方
自营电商、代运营电商还是平台电商都会涉及供方的管理，供方可以提供商品也可以提供原材料，供方的管理是商品系统的起始，建立供方信息、联系人信息、系统权限信息、有效日期、证件信息等，并且对供方的增删改增加审核流程。供方关联商品，如供方是失效状态则商品要下架不可售卖。
14. 合同
根据供方创建合同，基本信息如合同签订日期，有效起止日期，结算周期：是按月结还是按季度结，结算方式：是订单完成就结算，还是支付成功结算。主体信息就如甲乙方联系人信息；账户信息：账户信息单独立菜单维护方便拓展；品类信息：关联商品类目或者直接挂靠商品，分别建立不同类目的结算金额，按比例结算还是按固定金额结算。合同审核通过才能依据合同创建商品，合同到期或人为停止，已上线商品要下架。未上线不可上架。
7. 大后台
- 风控
风控的应用场景其实有很多，这里只谈谈下单场景的应用。如果我们判断出一个高风险的订单，这个订单将会被系统给拒绝，一般我们会从两个方面去判断，一个是用户历史的行为，一个是用户当前的下单风险，前者来说，我们可以看用户的账号是否高风险，是否有比平常人更高的拒收率等等，后者来说一般是判断用户是否存在技术刷接口的可能性，比如判断这个用户在当前下单的时候，是否请求过于频繁。
2. WMS
和某一个具体仓库相关的所有业务流程都在wms管理，具体包含的业务流程有三个出库，入库和上架。出库的类型有很多种，比如说电商订单的类型就是购买出库，当仓库接收到出货单以后会打印分拣单，仓库员工会根据分拣单对于货物进行拣货、打包等操作，最后将打包完毕的商品放在出库区等待承运商拉走。入库的类型也有很多种，一般最常见的就是采购入库。而商品上架则是需要先根据仓库的库位管理划分很多的区域，然后再将不同的商品商家都不同的区域。
3. XMS
XMS中文名称叫售后管理系统，售后的类型有三种退换修，然而退换修需要有不同的备件库，可能是更换零件进行维修，也可能是直接更换整机。如果是退货的话，则需要在XMS当中判定用户发回的货是满足退货条件的，此时在XMS当中会告诉订单中心，从而再触发支付和结算业务的退款流程。
4. 用户中心
用户中心也就是存储用户基础数据的地方，同时需要承担用户的注册登录找回密码，更换手机号的相应流程，对于不同的国家，需要支持不同类型的注册方式，比如手机号注册和邮箱注册或者是谷歌账户注册，同时在技术方案上也要支持不同类型的前端产品，比如说支持Web、Webview、APP等。对于不同风险等级的业务，也要支持不同类型的注册方式，比如只是电商业务的话，只需要手机号注册即可，但如果是金融信贷业务，则还需要支持人脸识别或者是身份证认证等。
5. SRM
SRM的中文名为供应商管理系统，此处包含商家模块，核心逻辑是对于不同的供应商进行打分和评判，筛选初优质的供应商。同时对于询价、采购、物流、财务等供应流程进行数据化管理。
6. 财务
收入、支出、对账、调账、退款、成本管控、GMV核算等
在线咨询
