电商导购平台架构设计

业务背景

一、业务价值：自购省钱

入驻在各大电商平台（如淘宝、拼多多）的商家，为了推广自家的商品，几乎都会开通满减优惠券和推广佣金。这样就会吸引推广者们帮商家出货，赚取推广佣金。既然商家给到额外的优惠券和佣金，这个钱完全可以让消费者自己拿了。可能每单省下的钱不多，几毛几块几十块不等，但数量多了，日积月累下来，也是一笔不小的额外收入。

哪些平台购物可以省钱？在淘宝/天猫、京东、拼多多、抖音、唯品会上购物都可以省钱，前提是相关商品开通了推广。此外，美团、饿了么、滴滴打车也可以领满减/折扣券，生活充值类的（话费慢充、电费慢充、视频/音乐会员等）也有折扣。

具体如何操作？消费者该去淘宝买、还是去淘宝买；该去拼多多买、还是拼多买，原来的购物方式不需要改变。当消费者打算下单的时候，顺手复制下商品链接，发送到公众号，搜索一下有没有券和返利，用公众号返回的链接复制到原购物平台购买即可。APP更方便更直观，搜索商品后可以直接跳转原购物平台。购买商品后，约1分钟，消费者可以看到自己的预估收益。导购平台每月25号会结算上月确认收货的订单佣金，申请提现就能到消费者绑定的账户。

二、业务价值-推广赚钱

1、带货推广赚钱

赚钱的逻辑就是，推广者把他专属的商品链接分享出去，有人购买了，推广者就能拿到佣金。推广者的工作就类似于导购，只要服务好客户，就能得到相应的回报。超级聚合导购APP帮推广者提供了各大主流电商平台：淘宝/天猫、拼多多、京东、抖音、唯品会等的商品榜单（实时榜、高佣榜、母婴榜等）、平台官方活动，同时也提供发圈素材等推广所需要的各种文案、工具等。推广者要做的就是找意向客户，把导购平台的商品链接分享出去，让客户去下单消费。对客户来讲，也没有任何额外的操作成本，直接用链接该在哪买就在哪买，购物方式不变。

2、推广给自购粉丝
带货很好理解，消费者用推广者的链接下单了佣金全归推广者。而推广者推广的粉丝，只要他下了单，那么可以拿到他自购佣金的约5%左右。佣金虽然比带货低，但是胜在成本低、数量大，毕竟带货也是花大量精力的。

推广者这两种方式结合起来做效果更好，建立自己的私域流量，收益还是很可观的。推广者的佣金会从一个月500,1000,1500...20000这样按照等差数列递增。

三、推广的方式方法

在APP内设置有识别度的头像、昵称。这样推广者邀请粉丝注册时，靠谱的头像和昵称会让粉丝感觉到靠谱。设置好记的邀请码，比如112233这种，粉丝在注册的时候也不容易输错。设置微信号。方便粉丝加推广者微信好友解决问题，有利于推广者沉淀私域流量资源和裂变。通过APP内的分享功能，可便捷分享邀请注册的海报、链接给粉丝，有利于推广者快速锁粉。锁粉后关注粉丝使用情况，优先推荐下载APP使用。APP功能比较多，可视化界面比较直观，说不定还能再给推广者推荐粉丝。如果粉丝实在觉得下载APP麻烦，可以把公众号推荐给他，这样就不耽误粉丝下单。

四、分佣的类型和比例

假设淘宝联盟给导购平台100元，分配比例如下：
1、自购佣金（自己带货的也是自购佣金）：L1为86.55元（内测期间新用户额外补贴8.88元），L2为91.11元，L3为95.55元，最高L4为102元。L1成长到L4需要满足一定的条件，达到条件自动升级
2、直邀粉丝佣金（自己直接邀请的粉丝）：5.61元
3、推广粉丝佣金（自己邀请的粉丝再邀请的粉丝）：3.74元，这部分佣金只有激活推广者身份才能拿到，激活推广者身份需要一定的条件。基于推广者分佣不超过3层，体系内的推广者轮流拿。

粉丝的自购成长值越高，相应的直邀/推广佣金比例则会相应减少。意思就是L1的直邀/推广佣金高于L4的直邀/推广佣金。这也是平衡各方利益的一种规则。

所有粉丝都会有一定几率的粉丝滑落。只要你的邀请人厉害，或者你邀请的人厉害，你就不用担心体系内没有粉丝。导购平台本身也会做广告去推人，从而帮先动的粉丝滑落。粉丝越多，推广佣金从而也会越多。

五、出类拔萃的推广者权益

推广者要是推广厉害的话，也可以争取成为
1、运营商：推广佣金额外补贴
2、高级运营商：推广佣金额外补贴，体系内产生的佣金一定的百分比(最高3%)
3、运营合伙人：除去体系内分给粉丝的，其他平台保留的佣金通过线下结算给运营合伙人，平台不拿钱

系统概述

整个系统分成客户端和服务端。

客户端包括移动网站、安卓、iOS、微信小程序，使用uniapp框架开发。uni-app 是一个使用 Vue.js 开发所有前端应用的框架，开发者编写一套代码，可发布到多个平台。

客户端通过http协议与服务端通信，数据请求统一经过部署在阿里云服务器上的nginx web代理服务器。

服务端应用系统采用微服务架构模式，框架用的是Spring Cloud。Spring Cloud是一系列框架的有序集合，它利用Spring Boot的开发便利性巧妙地简化了分布式系统基础设施的开发，如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等，都可以用Spring Boot的开发风格做到一键启动和部署。

服务端应用系统的正常运行基于若干中间件。如结构化数据存储采用关系型数据库Mysql，数据缓存采用redis;RabbitMQ用于常见的分布式事务处理以及应用系统解耦等问题；非结构化数据如图片存储在阿里云oss对象存储上。使用xxl-job管理定时任务。日志查询、监控、告警目前都是基于阿里云的相关产品。

服务端应用系统目前拆分成四个子系统，包括门户子系统（商品、订单、分佣、钱包等模块），会员子系统（用户数据处理）、账户子系统（财务账户处理）和消息子系统（短信、推送等消息管理）。

服务端部署在阿里云ECS上，使用DOCKER部署。目前发布会对用户有40s左右的感知。对外暴露的端口只有nginx 80端口，服务端内部的通信都是在内网进行的。

功能模块

一、渠道授权

在开发之前，需要开通所有平台的联盟账号和开放平台。如京东调用京推推开放平台，拼多多调用拼多多开放平台。淘宝比较麻烦，涉及到商品ID和权限问题，需要走多方平台调用：淘宝官方开放平台、工具商接口（好单库、折淘客、大淘客）。

有的平台直接发放appkey和appSecret，有的平台需要定期授权，否则失效之后就无法调用接口。授权功能放在运营管理系统。

二、商品

核心是调用相关渠道开放平台的接口。

商品抽象成以下几个接口，具体调用渠道接口使用简单工厂设计模式

1、商品搜索   查询主要字段：平台编号、关键字、分页、排序。返回结果主要字段：商品标题、商品图片、商品价格、优惠券金额、预估收益、店铺名称等。

2、商品列表  查询主要字段：平台编号、分页、查询类型（榜单、推荐、频道页等）、查询值、子查询值

3、商品详情  查询主要字段：平台编号、商品ID。商品详情有些字段是对商品列表字段的补充，需要价格、佣金、券信息准确无误还需要额外调用其他接口。

4、商品转链  目的是跟平台的用户关联上。查询主要字段：平台编号、商品ID

另外还有些用户辅助功能，如商品收藏、浏览足迹。如有多个平台的商品则多线程调用渠道接口，最慢的线程即为最长响应时间。

商品核心的两个接口还有：

1、剪切板搜索   通过关键字（商品链接、口令）搜索相应商品。多线程查找渠道商品搜索接口，以最快有结果的线程返回结果为准。

2、快捷转链   展现形式跟剪切板搜索不同，如果是商品链接则复用剪切板搜索逻辑，如果是活动链接链接直接调用渠道转链接口。

三、会员

1、排列特征    每个节点挂最多100个子节点，按照多排排列

第一排：100^0 = 1个节点

第二排：100^1 = 100个节点

第三排：100^2 = 10000个节点

第四排：100^3 = 1000000个节点

以此类推。。。

子节点按照顺序增加到父节点上，如果节点满了就放到相邻节点，如果一排满了就放到下一排 (子节点只能挂在邀请人的树下) 

根节点的邀请码为123456，如果注册没填邀请码默认邀请人为根节点

2、成长升级规则  满足一定的业务条件（比如确认收货9单）可升级。等级所对应的称谓、升级规则放配置中心

3、推广粉丝   

自定义推广码：唯一、可修改（系统自动生成默认邀请码，6位，大写字母+数字组合，自定义邀请码：6位，大写字母+数字组合，预留豹子号（000000,1111111等）以及123456）

总粉丝数：用户树节点下的所有人数。在表结构设计时，要考虑查询的性能问题

邀请人数：邀请人是该用户的所有人数

4、登录认证    手机号/密码注册、手机号/密码登录、手机号/验证码一键登录注册、微信快捷登录、手机号绑定

四、订单同步&分佣

1、订单同步接口

调用渠道相关接口。其他渠道都很简单，唯独淘宝、拼多多比较特殊，需要用户授权。特别是淘宝，需要跳转淘宝授权。拼多多通过链接授权就可以。

2、订单同步策略   保证订单无遗漏的同步到数据库

1分钟同步一次最近5分钟的订单（按照支付时间） ；1分钟同步一次最近5分钟的订单（按照更新时间）      

【兜底】1天同步一次近1天的订单（按照更新时间）

淘宝维权单、京东报价单需要每月结算前额外调用接口处理。

3、特殊订单标识   区分比价单、淘礼金订单、报价单、维权单、CPA活动等特殊订单场景

4、分佣规则   新订单正向分佣，退款单逆向分佣（扣除）。

分佣金额：用户成长等级有关。个人佣金=总佣金*个人佣金比例；推广佣金=总佣金*（团队佣金比例-个人佣金比例），直邀佣金和间接推广佣金根据推广佣金六四开分成。

1、分给自己  

2、分给直邀

3、分给推广者：根据会员排数，找对应的推广者，最多分3级。加入X上级推广者有4层，A、B、C、D，则第一单分给A，第二单分给B，第三单分给C，以此顺序循环。如果X上级推广者只有A，那么每次都分给A。

五、财务

1、账户设计

待结算账户（借）、待结算账户（贷）

可提现账户

冻结账户（申请中）

2、资损场景

不可控：每月25日结算完之后，发生上月订单取消、佣金扣除。用户已经提现打款完成

可控：结算完之后~打款之间发生的订单取消。【方案】在真实打款之前查询有没有已结算的订单发生取消，如有并且有待结算欠款则直接置为驳回并扣除欠款。(提现申请自动打款和审核通过打款入口控制)

3、对账结算

每月23号对账：出账单

订单和分账记录表对，分账汇总和账户请求汇总对

人工再次核对系统账单跟渠道账单，无误则手动触发结算，将待结算账户余额转账到可提现余额

4、提现打款

提现触发某些风控条件需要审核，通过审核调用支付宝接口转账。成功后扣减可提现余额

提现相关配置化，根据配置化判断提现逻辑

架构图

整体架构

服务暂时不拆那么细。

 

系统架构

部署架构

暂时不用K8s，线上应用用docker部署。

中间件&基础服务 

前端h5页面（高带宽）   

业务应用

接口文档

请求地址

swagger自动生成

接口规范

原则上遵循restful风格，查询get、新增post、修改put，删除delete

{

"code":0, //除了0是成功的code，其他code都是错误的

"msg":"", //code非0对应错误的描述信息

"data":"如果本次请求有数据返回则为json格式表示的数据对象或者为null"

}

http header

需要鉴权：  Token

客户端类型（必传）: ctype    

   wap,//手机网页

    pc,//PC网页

    wx_h5,//微信内网页

    wx_xcx,//微信小程序

    dy_xcx,//抖音小程序

    ios,//IOS

    android//安卓

客户端ID（有就传）: cid

错误码

尾号后四位或者shotCode

2999  token解析失败

3000  需要第三方绑定

数据模型

忽略。