网上找了很多资料，没有找到一套比较心仪的架构参考，于是跟 leader 结合业务设置出通用的 CPS 架构，覆盖绝大多数应用场景。
CPS 就是业务上的各种推广、邀请、拉新等活动，通常我在开发的时候没有想过通用性，都是来一个需求做一堆表和一个活动页，其实有更优雅的方式，抽象出其中的共同点，做一套通用的 CPS 架构。
接下来以拉新为例，解释架构设计。
三大角色
用户（推广人和被邀请人）、前端和后端。
sequenceDiagram
participant 用户
participant 前端
participant 后端
用户->>后端: 推广人生成邀请链接
后端->>用户: 组装推广人信息密钥，生成短链接并且返回
用户->>前端: 被邀请人点击短链
前端->>后端: 将短链作为参数给后端解析
后端->>前端: 解析短链接对应的密钥和信息，返回具体活动页面url、信息密钥、uuid等
前端->>用户: 跳转到具体活动页，并将其他信息存入浏览器，保证活动页面内其他请求都携带这些参数
用户->>后端: 活动流程请求1
用户->>后端: 活动流程请求2
用户->>后端: 活动流程请求3...
用户->>后端: 活动完成奖励请求
后端->>用户: 校验活动风控，给予/拒绝活动奖励
架构流程:
- 推广人生成邀请链接，后端根据活动 id、版本号、用户id、时间戳等信息生成密钥，然后做短链接（最简单的比如组装成json，使用 aes 加密然后截取前 8 位作为短链接，与完整密钥数据库做对应，考虑到不同版本迭代的解密方式可能不同，密钥开头要以明文标识版本，如V1xxxxxxxx）
- 推广人将链接给被邀请人，此链接为统一的前端 CPS 中转页面，前端将短链接发送给后端，由后端解析出具体的活动页面、完整密钥、uuid 等
- 前端跳转到具体活动页面，并将完整密钥和 uuid 存到浏览器本地缓存，保证以后活动中每次请求都携带这些参数
- 被邀请人参与活动，发送请求1、2、3...等等
- 被邀请人完成活动，发送领取奖励请求，后端根据 uuid 校验用户行为风控，发放奖励。
注意点:
- 流程1 和 2 中短链接使用的为中转页面，此页面并非具体活动页面。
- uuid 主要为了校验用户行为风控，可以将活动中的请求存在 redis，在发放奖励时校验。
此图为前后端的交互图，看不懂多看两边，看懂了 CPS 怎么玩你就搞透了。下次面试可以吹牛逼。
数据库设计
业务
- cps 主表
- cps 用户表，记录推广人和被邀请人关联关系
- cps 订单表
统计
- cps 推广人表，如邀请人数，奖励详情等
- cps 被邀请人表，如完成订单数等
业务和统计的数据一定要区分开，具体原因在下期统计架构中再讲。
总结
以上就是 CPS 可抽象的架构。不同的活动只需做扩展就能满足业务需求。这样写出来的代码有逻辑、思维清晰易懂，摆脱了枯燥的 CRUD 和 CVS，让开发不再做需求的奴隶。
统计是个大坑，你永远不知道运营需要哪些数据以及数据的计算公式，如果把统计和业务写在一起，那么数据库会直接炸。
下一篇写数据统计的架构，下次再见拜拜。
