1. 回顾
成长计划第一版上线已经四个月了，参与人数已经有四十万，期间又迭代了好几版。但是，现在回顾当初的设计，觉得有些欠妥。在此做一个回顾，毕竟以后也没什么机会再去想这些了。
第一版成长计划的核心是围绕着计划展开的，每个计划下面关联着详情、任务、勋章、提醒等，典型的主从表。
看起来，大概是这样的：
主要的功能就是：开始测试、生成计划、查看计划、完成任务、获得奖励。业务就这么简单，但是做起来可能并没有想象中的辣么简单。具体的实现前文已经说过，不再详陈。服务只有三个，结构也非常简单，如下图所示
故事的开头总是一帆风顺，无限美好。单单看成长计划，很简单，功能也比较单一。毕竟它只是一个提高用户留存和会员转化的工具而已。
但是，当它和新手礼包、微信裂变、会员等一起用的时候，业务就有些复杂了。
2. 成长计划+微信裂变
刚开始，阵地只是APP，后来扩大到微信，目的也很明显：拉新。这个时候就有些不一样了，问题来了：
1、一个普通的H5页面，只要是微信用户就可以点开。也就是说，非用户也可以参与。就这一点就够头疼的，因为在APP里面要求必须是我们的用户才能参加。为了兼容这种情况，我在计划主表上新增了一个渠道（channel 1:APP 2:微信）字段用于标识来源。还有，非用户开启了计划，但是他看不到，需要输入手机注册为我们的用户以后登录APP才能看到。这就需要有一个地方先存着这些非用户开启计划的数据，等到他成为用户以后再讲数据迁移过去。对于这种临时数据，为了不新建表，我直接存到了MongoDB中，为了能快速判断用户输入的手机号是否已经有计划了（以最后一次测试结果为准），我将手机号存到了Redis中。当用户注册成功以后，通过MQ我收到消息，便将数据迁移至MySQL。这样就完成了一个用户拉新。
2、当一个用户把链接分享出去（微信群、朋友圈等）以后，有三个人因此而成为我们的用户的话，就给分享者一张7天会员体验卡。简单地理解，就是拉3个新用户就得7天会员体验卡。这就必须要记着谁是因为点了谁的链接而成为用户的，需要记录这个对应关系。这个当然也是在临时数据中保存。
3. 成长计划+会员
最初，完成成长计划获得勋章（PS：成年人可能不能理解，勋章有毛用啊，我QQ勋章多得是……但是，请回忆一下，小时候为了收集各种卡片而买了多少小浣熊方便面）。后来，又新增了一种奖励：会员体验卡。完成7个计划以后，就得7天会员体验卡。这就意味着：
1、新增一种奖励类型（1：勋章，2：体验卡）。必须在生成计划的时候就要判断出，完成本次计划到底是得勋章还是得体验卡。因此，要在计划主表上新增一个字段以标识奖励类型。
2、勋章和体验卡的属性不一样，也就是字段不一样。本来它们是可以放在一起的，但是考虑到二者的获得的方式，也为了不想改动一起的逻辑，更为了便于日后数据统计，于是新增了一张表用于保存体验卡，等于说勋章是一张表，体验卡又是一张表。这里再多解释一下什么叫获得方式不同，勋章是常规任务奖励，体验卡算是额外的奖励。
4. 成长计划+AB测试
这里AB的区别在于测试题目不一样，这就意味着计算方式需要调整一下。这个小功能主要是通过前端传的标识来返回不同的数据而已，但是麻烦的是，我这边要记录有多少人是A，多少人是B，包括用户点到第几个页面，于是加了表保存打点数据。
5. 成长计划+新手礼包
成长计划和新手礼包打通以后，可以通过在成长计划完成任务来使奖励翻倍，比如新手礼包是7天会员体验卡，那么在成长计划完成任务后时长翻倍就变成14天了，如果没有领新手礼包，那么在成长计划页面也可以领，领完以后接着开启翻倍任务。至于首页楼层如何展示，是展示新手礼包楼层，还是成长计划楼层，以及成长计划楼层展示那种状态就不再详述了，是业务而定。稍微麻烦一点的是：在原来成长计划的常规任务前面硬生生加了一个新手礼包奖励翻倍任务。这个任务与常规任务大不一样，任务完成的方式也不一样，因此在目前的结构上来看，只能单独处理。
未来， 成长计划还有更多可能。成长计划简直就是儿童内容领域的互联网+ （PS：我自己胡诌的）
7. 成长计划之数据打点/统计
开发任何功能，数据打点（或者叫埋点）都是必须的，是非常重要的。没加打点，就好比是服务上线了却没有监控，这就没有指标数据参考了呀。
打点主要跟客户端密切相关，一般都是在客户端打点，将数据采集上报到大数据那边。服务端的打点也有，但相对较少。不过，为了后续统计更方便，必要的服务端打点还是不能少的。
这一次，除了用户的行为，已经路径（点到哪一个页面了）等等这些数据外，其它绝大部分产品需要的统计都可以从数据库里查出来。比如，每天新增用户多少，会员转化率多少，每日时长，次日留存，微信过来的有多少，发了多少体验卡，AB哪个效果好一点等等。
8. 成长计划之弹窗
每个任务开始和结束的时候有弹窗，计划完成或过期有弹窗。最初设计的时候，弹窗是单独的，与某个计划没有关系，每次进首页该弹什么窗都是根据计划完成情况计算出来的。后来，随着业务越来越复杂，弹窗也有点乱了。比如，体验卡的弹窗和勋章的弹窗就不一样，翻倍任务的弹窗和常规任务的弹窗又不一样。以至于后来，什么时候弹什么窗这部分逻辑变得越来越复杂。
后来，我想了一下，如果最好还是把弹窗与任务绑定在一起比较好。当前是什么任务就弹什么窗，给什么奖励，多么清晰，多个简洁明了。
9. 结构优化
我后来想到的是，将弹窗和奖励都和任务进行绑定，而任务之间又是层层递进的关系。
就像，拦截器和过滤器。类似的还有，js中的事件冒泡，设计模式中的责任链模式
于是，主要的关联关系就变成了：计划之下是内容和任务，任务之下是奖励和弹窗，APP和微信消息提醒是独立的。
于是，按照我的设想，一个计划的生命周期应该是这样的：
任务有任务类型：一次性任务和周期性任务。所谓一次性任务就是指完成就进入下一个任务，比如常规任务；周期性任务指的是每天任务都从新开始，直到任务完成，比如翻倍任务就是这样的。
任务之间又内在的关联关系，就像一个链表一样，要知道它的上一个任务和下一个任务都是谁。
有了这种链表结构，那么想增加一个任务或者删除一个任务就变得轻而易举，如此巧妙灵活的设计，我可真是个小机灵鬼
再回到这次的翻倍任务上来，这种任务跟常规任务不一样，奖励什么的运行方式乃至弹窗都不一样，简直要疯了。如果我们的任务是这种链表结构，那么，请随便插入。
所有任务完成以后的奖励挂在最后一任务的奖励上。
10. 降本增效
为什么要用SSDB呢？最主要的原因是：降本增效
我就提几点吧：
- 成本比Redis低
- 完美支持Redis常用的数据类型及操作
- 容量大，久经考验
- 性能与Redis不相上下
- 从Redis迁移至SSDB也非常容易
文档在这里：
https://github.com/ideawu/ssdb
具体的，看文档吧，我就不多说了，这里直接引用了
11. 其它
曾经截了几张接口优化过程中的截图，一并放上来吧，留着也没用，以后也没有机会了
祝我们在2020年都好