《电商系列》文章是本人做电商平台的思考与设计的总结，里面包含之前做电商平台遇到的问题、解决思路、设计、重构等方面的经验，也有一些设计上的技巧，希望能帮到新入手的小伙伴。
一、背景
在做电商平台时，相信都离不开各种推广，通过分享二维码、分享海报、商品链接、店铺链接等方式，来进行线上，或者线下的推广。线上诸如朋友圈、软文、广告、群组等方式、线下诸如店铺海报、地推海报、贴二维码等方式。
从这些推广方式来看，要么通过扫二维码打开链接，要么直接打开链接到推广的版面上，好像没有什么好设计的，无非就是将当前的网页/H5/App动作协议，生成对应的二维码/链接，不就结束了吗？是的，刚开始做商城时，我们也是按照这个原则来做，起初就分享个链接/活动版面链接好像也没什么问题，但随着运营部门的各种推广需求与日俱增，开始遇到挺多问题。
最明显的一个问题是，当初要进行线下推广，由于运营人员的疏忽，导致生成的二维码的链接是错误，但当时已经打印了几千张二维码了，也已经分发到不同的市场人员手上，线上也分享了，这样通过改正在打印二维码又不现实，当初只能是去互调二个活动了。
面对当初的情况，总结的问题有：
分享的内容分散（难以维护管理）生成分享的逻辑代码分散（难以维护及调整）分享信息与购买信息无关系（难以评估某个分享业务的效益情况）缺少分享信息的采集产生订单，难以根据分享信息来计算（无法细化到某些渠道）难以提供效益的评估
二、想达到的目标是什么
既然有这些问题，又为了能满足运营的快速推广与发展，通过考虑，当时想达到的目标主要有：
实现分享信息的统一管理与维护。为每一种类型分享分配一个唯一编号。在产生的分享链接或二维码中，带上唯一编号。记录产生分享链接或二维码那一刻的信息（分享连接上不带具体的业务信息）在下单的入口，加入记录订单来源信息（包括分享链接，唯一码等信息）
三、分享服务的设计
3.1 服务交互设计
在电商平台中，有用户端（APP，小程序，PC端，公众号等）、运营端、商家端，而在后台，是采用微服务的架构来划分服务及组装信息，通过初步讨论，规划的流转图如下：
上图大概画出了主要的服务之间的交互逻辑，那具体的过程是如何进行的呢？
3.2 分享信息配置过程
- 根据需求方获取分享信息，包括分享logo，标题，描述，链接等。
- (新增)在【运营管理系统】中的【分享信息管理】中，注册一个分享事件。
- (新增) 绑定一条计算收益【科目】（后续计算收益用）。
- (新增)注册成功后，获取分享事件唯一码（后续接口使用）。
- (修改) 找到修改的分享信息，对分享内容进行修改，然后保存。
3.3 分享信息生成过程
- （前端）调用【统一分享信息生成接口】，传入【分享事件唯一码】，及业务参数。
- （后端）根据传入的信息处理 - 根据【分享事件唯一码】，找到分享信息。
- 判断is_enable状态，如果禁用，则返回失效。 - 组装分享信息，生成【分享记录唯一码】，并赋到链接上或返回给调用方。
- 记录分享信息到表上（分享记录表） - 记录分享的参数（绑定分享日志表记录id）
- 返回分享信息给到调用方（组装）
3.4 打开分享链接
- 前端获取链接上的【分享记录唯一码】。
- 传递【分享记录唯一码】到后端。
- 后端根据【分享记录唯一码】查找到分享信息绑定的业务参数。
- 判断is_enable状态，如果禁用，则返回失效。
- 根据业务参数获取展示的内容，并组装好。
- 返回组装后的内容给到前端。
3.5 预下单及下单过程
- 调用方必须传递【分享记录唯一码】。
- 【预下单】必须在日志上输出【分享记录唯一码】。
- 【预下单】返回一个【预下单号】给到接口调用方。
- 【下单】必须记录【分享记录唯一码】，【预下单号】及下单参数到一个日志表上【订单数据生成成功后】。
- 【下单】可以通过广播的方式，来通知下游服务去处理分享的信息（可选）需带上【预下单号】。
3.6 下游业务处理（比如计算分享提成）
- 下游业务接收订单广播。
- 根据自己的实际业务对内容进行过滤处理。
- 提取【预下单号】，到下单事件记录表上，查找相应的下单参数。
- 如果需要处理分享的业务，可以根据【分享记录唯一码】到【分享记录表】上查找分享当时的配置信息及业务信息。
- 判断【分享信息配置】上的is_enable状态，如果禁用，则返回失效。
- 如果是计算收益，获取分享信息表上的【收益科目id】。
- 若为空，则不计算。
- 若不为空，则到收益科目表查找收益等计算信息（可能是多个表，一个基本信息，一个规则等）。
- 可能还需要根据【分享唯一码】，查找不同的关系表（这里是否有其他优化思路？）。
四、数据存储模型
4.1 分享信息配置表（share_info_conf）
- id : bigint: 主键
- share_code : char(8) : 分享唯一码（采用数字字母组成，不重复）
- share_title ：varchar(255) : 分享标题
- share_logo : varchar(255) : 分享logo
- share_desc : varchar(255) : 分享内容描述
- share_type : char(2) : 分享类型（00-店铺，01-商品，等）
- jump_type : char(2) : 跳转方式
- jump_info : varchar(255) : 跳转的格式（链接），挖空参数
- remarks : varchar(255) : 备注
- is_enable : int : 状态（0-禁用，1-可用）
- earning_subject_id : bigint: 收益科目id
- created_time, creator, revised_time, reviser
4.2 分享参数配置表（share_param_conf）
- id : bigint: 主键
- share_id : bigint: 分享配置id（关联share_info_conf表）
- param_key : varchar(64) : 参数名
- param_value : varchar(255) : 参数值
- remarks : varchar(255) : 备注
- is_enable : char(1) : 状态
- created_time, creator, revised_time, reviser
4.3 分享记录表（shared_log_info）
- id : bigint: 主键
- share_id : bigint : 分享配置id（关联share_info_conf表）
- shared_code : char(10) : 分享记录唯一码（采用数字字母组成，不重复）
- share_link : varchar(255) : 分享链接
- shop_id : char(32) : 店铺id - commodity_id char(32) : 商品id
- client_type : int : 客户端（ClientTypeEnum）
- creator : char(32) : 创建人id
- created_time : datetime : 创建时间
- reviser : char(32) : 修改人id
- revised_time : timestamp : 修改时间
4.4 分享记录参数表（shared_log_param）
- id : bigint : 主键
- shared_id : bigint : 分享配置id（关联shared_log_info表）
- param_key : varchar(64) : 参数名
- param_value : varchar(255) : 参数值
- remarks : varchar(255) : 备注
- is_enable : char(1) : 状态
- created_time, creator, revised_time, reviser
4.5 下单信息记录表（order_submit_log）
- id : bigint : 主键
- shared_code : char(10) : 分享记录唯一码
- pre_order_id : bigint: 预下单id
- order_code : bigint : 父订单id
- refer_link : varchar(255) : 关联页面链接（如果是app，则是apple/android）
- param : text : 下单参数json串
- ip : varchar(128) : 下单ip
- client_type : int : 客户端类型（ClientTypeEnum）
- version : int ： 版本号
- created_time, creator, revised_time, reviser
五、总结
按照上面的设计，完成了分享服务的开发及上线，上线后，确实能达到当初预设的目标，通过运营后台的数据统计分析，能分析出那些分享的效益，也能分析到业务人员的推广情况。同时满足了动态调整（不会因为二维码错，而导致要重新印刷）。
