'活动'设计的一些trick
在梳理过去做过的项目
之前做项目的时候, 十个月期间做了不少活动, 类型比较多, 有推广/抽奖/小游戏等等.
有些活动需求明确一气呵成, 也有些活动需求模糊一度推倒重来, 还有的活动被刷了><#
好吧, 来说说活动
一些想法, 可以是技术, 非技术
目的
活动的目的是什么? 有没有存在的意义?
存在由于没有想清楚, 耗费人力物力搞了结果不尽人意……所以目的应该先想清楚, 并且明学下来
活动开发简要流程
- 需求分析: 整体流程, 用户侧细节, 管理侧需求, 统计需求等等, 对整个流程达成一致, 对每个环节的条件/处理逻辑/后续出口等等明确下来, 对一些资质/数字限制等确定下来
- 设计出图/后端建模-逻辑代码-API/前端开发
- 测试环境上线
- 内部测试, 试玩, 针对活动本身给意见. 测试人员测试, 针对逻辑本身, 同时进行网速测试(2g/3g/wifi) / 浏览器测试 / 不同手机-系统测试
- 修正迭代, 测试
- 正式上线
- 管理侧/统计侧上线
- 推广/监控
- 活动结束
- 奖品派发/数据统计等
- 活动下线
quick and maybe dirty
由于活动本身的性质, 这类代码逻辑属于短平快一类的.
简而言之: 怎么快怎么来
- 可以不要考虑复用
- 当然, 有些代码是复用的, 例如CRUD/get some list/check permission/call base service等等
- 不要考虑将来/以后, 很多活动上了就下了, 不会有所谓的
将来, 切忌过渡设计, 空耗费许多精力没有必要 - 要快
注意代码/数据/部署隔离
前面说过, 很多活动逻辑没有将来
所以, 活动的代码尽量独立, 保证随写随测, 随上随下, 尽量隔离于主体代码之外, 这样上下线也方便
当然, 不可能完全独立, 依赖外部尽量使用独立的服务接口, 被外部依赖提供也尽量通过提供接口解决(情况很少)
数据独立, 包括, 数据库实例/redis or memcached/文件等, 活动需要记录一些数据, 和主体业务独立开来, 尽量不共用, 有条件的话单独提供实例
部署隔离, 尽量不要和关键服务在同一台机器或者共用带宽, 由于活动本身的特质, 可能带来突发的流量, 可能导致带宽/IO/缓存占用/机器负载等变高, 会影响到其他服务.(可以给定独立url, 通过反代定到活动服务)
开发注意
- 做好缓存
- 每个接口做好资质/权限控制, 这类逻辑放在api代码的前面(判断条件放到最前面), fail fast, 验证通过后才进入主体逻辑代码
- 友好的异常处理/用户提示
- 后端需要考虑
防刷, 前端需要处理下重复提交 - 做好事务控制(并发), 特别是涉及数字增减的情况, 例如奖品数
- 涉及步骤的活动, 做好流程限制, 第一步-第二步-第三步……, 防止用户跳过某一步直接进入下一步.(可以通过签加密token的方式)
- 图片, 尽量放到 CDN (血的教训, 前端一张背景图导致带宽被跑满, 后续用户进不来)
- 需要有一套成熟的统计系统, 活动数据直接发送到统计系统, 由统计系统统一出数据
- 对于关键性的步骤/数据, 可以记日志
- 有必要的话, 做成一期一期的, 有开始结束时间, 自动切换(有些复杂的活动)
- 有必要的话, (传说中的开关)提供方便的配置或者入口, 可以一键上下线活动/奖品(valid/invalid/shutdown)
- 对于关键性的代码, 做好注释, 例如一些限制逻辑/数量等等
学会打时间差
很多活动, 可能是热点? 节日? 等等, 时效性比较强的.
然而, 当活动逻辑很复杂的时候, 又要在规定时间内上线, 这时候可以仔细切分需求, 分不同时间上线.
例如, 一个玩游戏/抽奖/兑奖的活动, 可能分为两部分, 用户侧和管理侧, 用户侧逻辑玩游戏/兑奖/查看是否获奖, 管理侧查看获奖情况/颁奖/新增用户统计/渠道统计/流量统计等等
那么, 可以先保证用户侧完成, 同时加入向统计系统发送统计数据的接口, 然后上线, 保证用户侧主体流程. 上线后开始开发管理侧, 管理侧可以按照运营优先级处理, 例如要查看实时统计信息的话, 先做统计, 保证推广效果, 获奖及颁奖可以稍稍押后, 作为第三阶段上线(如果活动兑奖都是在一个周期结束的话)
例如, 要发奖数据, 如果没有管理后台, 直接库里导一份出来就是了. 其实这时候应该思考, 要不要花力气做管理后台, 大不了活动结束手工操作一下, 十分钟.
下线
额, 活动做完, 要下线了.
如果程序是带日期限制的, 到点了自动结束, 提示用户活动结束, 活动流程无法走下去.
如果需要人肉, 直接将外网入口去掉即可.
然后, 可以考虑后续了
首先, 要确认, 该记录的统计数据记录了, 该分析的分析了, 该发奖的也发奖了……
首先, 备份代码到活动代码仓库(供后续参考/复用, 防止雷同逻辑/代码要重写), 然后从代码库删除.
线上, 备份数据到备份服务器, 包括数据库数据/日志/文件等等, 如果缓存中有需要dump的, dump出来. 然后下线数据库, 清空缓存, 日志等
活动, 很大程度上是一堆临时而无用并且没有技术含量, 而且非常短命的代码组成的, 做多了容易烦躁, 最好一个项目组里轮流处理, 当然有人认领更好.
活动成不成功, 决定因素很多, 但无论如何, 下线前做好review, 防止重复犯错
就这些
wklken
2015-08-28