在梳理过去做过的项目
之前做项目的时候, 十个月期间做了不少活动, 类型比较多, 有推广/抽奖/小游戏等等.
有些活动需求明确一气呵成, 也有些活动需求模糊一度推倒重来, 还有的活动被刷了><#
好吧, 来说说活动
一些想法, 可以是技术, 非技术
活动的目的是什么? 有没有存在的意义?
存在由于没有想清楚, 耗费人力物力搞了结果不尽人意……所以目的应该先想清楚, 并且明学下来
由于活动本身的性质, 这类代码逻辑属于短平快一类的.
简而言之: 怎么快怎么来
将来, 切忌过渡设计, 空耗费许多精力没有必要前面说过, 很多活动逻辑没有将来
所以, 活动的代码尽量独立, 保证随写随测, 随上随下, 尽量隔离于主体代码之外, 这样上下线也方便
当然, 不可能完全独立, 依赖外部尽量使用独立的服务接口, 被外部依赖提供也尽量通过提供接口解决(情况很少)
数据独立, 包括, 数据库实例/redis or memcached/文件等, 活动需要记录一些数据, 和主体业务独立开来, 尽量不共用, 有条件的话单独提供实例
部署隔离, 尽量不要和关键服务在同一台机器或者共用带宽, 由于活动本身的特质, 可能带来突发的流量, 可能导致带宽/IO/缓存占用/机器负载等变高, 会影响到其他服务.(可以给定独立url, 通过反代定到活动服务)
防刷, 前端需要处理下重复提交很多活动, 可能是热点? 节日? 等等, 时效性比较强的.
然而, 当活动逻辑很复杂的时候, 又要在规定时间内上线, 这时候可以仔细切分需求, 分不同时间上线.
例如, 一个玩游戏/抽奖/兑奖的活动, 可能分为两部分, 用户侧和管理侧, 用户侧逻辑玩游戏/兑奖/查看是否获奖, 管理侧查看获奖情况/颁奖/新增用户统计/渠道统计/流量统计等等
那么, 可以先保证用户侧完成, 同时加入向统计系统发送统计数据的接口, 然后上线, 保证用户侧主体流程. 上线后开始开发管理侧, 管理侧可以按照运营优先级处理, 例如要查看实时统计信息的话, 先做统计, 保证推广效果, 获奖及颁奖可以稍稍押后, 作为第三阶段上线(如果活动兑奖都是在一个周期结束的话)
例如, 要发奖数据, 如果没有管理后台, 直接库里导一份出来就是了. 其实这时候应该思考, 要不要花力气做管理后台, 大不了活动结束手工操作一下, 十分钟.
额, 活动做完, 要下线了.
如果程序是带日期限制的, 到点了自动结束, 提示用户活动结束, 活动流程无法走下去.
如果需要人肉, 直接将外网入口去掉即可.
然后, 可以考虑后续了
首先, 要确认, 该记录的统计数据记录了, 该分析的分析了, 该发奖的也发奖了……
首先, 备份代码到活动代码仓库(供后续参考/复用, 防止雷同逻辑/代码要重写), 然后从代码库删除.
线上, 备份数据到备份服务器, 包括数据库数据/日志/文件等等, 如果缓存中有需要dump的, dump出来. 然后下线数据库, 清空缓存, 日志等
活动, 很大程度上是一堆临时而无用并且没有技术含量, 而且非常短命的代码组成的, 做多了容易烦躁, 最好一个项目组里轮流处理, 当然有人认领更好.
活动成不成功, 决定因素很多, 但无论如何, 下线前做好review, 防止重复犯错
就这些
wklken
2015-08-28
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。