目录
-
.NET-记一次架构优化实战与方案-梳理篇
-
.NET-记一次架构优化实战与方案-前端优化
-
.NET-记一次架构优化实战与方案-底层服务优化
前言
程序员输出是他敲写的代码，那么输入就是他思考好的设计。因此不做设计是不存在，设计只分优秀的设计和糟糕的设计。为了避免过度设计浪费成本，需要针对现有业务与问题进行展开。业务梳理是不可避免的。
优化是无止尽，为了更有成效的优化，必须了解已有的问题与需要优化的目标。
业务背景
通过做任务获得增值奖励等形式，达到以下目标：
- 引导用户完成与业务相关指定行为，进而参与业务
- 提高用户业务黏度，减少用户流失
- 完成日常指定任务，培养用户APP使用习惯等
业务梳理
业务简述
- 运营配置：由公司运营人员在运营系统对相关业务的活动进行配置。
-
- 任务列表：配置好的活动将在用户端展示给用户观看，并给与【领奖】或【引导完成】的动作。
-
- 底层服务：根据已完成的业务数据源与其相关的活动配置，进行定时跑批完成任务与发放奖励。
业务关键点
- 三步骤
参与、完成、领奖，一个用户完成一个活动必须经历前面三个步骤
- 十二个任务类型
注册、实名、风险评测、签到……意见反馈等等（避免过多的暴露公司业务，不一一例举）
- 三个周期
- 参与周期：隐藏属性不需要配置
- 任务周期：运营系统配置
- 一次性
- 日循环
- 周循环
- 月循环
- 单次循环
- 领奖周期：运营系统配置
- 不限
- 按日
- 按周
- 按月
-
7天领奖有效期
业务例子
为了更加好的理解，我以签到任务举个例子：
配置：签到参与周期为每天一次，完成周期为周循环，领奖周期为按周，任务完成条件需要连续签到3天。
场景：用户已经在在星期日、星期一、星期二连续签到了3天，那么符合了完成条件，也在完成周期范围内，因此可以完成任务并且领奖。
但是如果继续签到 星期三、四、五连续三天，虽然可以继续参与任务，但是不可完成，因为任务周期是周循环。
再假设上面的配置只修改了完成周期为日循环，仍然是星期日到星期5连续签到，在星期二的时候可以完成并且领奖一次，在星期五的时候又可完成任务，但是这个时候不能领奖，因此领奖周期按周，所以必须等到下个星期日，才能领奖。
业务流程图
存在问题
业务过度设计
本业务一共有3个维度，参与、完成、领奖，其场景共有X*Y*Z的个数。原本产品的意思是想做一个灵活性比较大的配置，只要有新的活动来，可以随意组合应对。
然而真实场景下，真正用到的组合并不多。
例如：
签到几乎连续一个月签一个月才能完成与领奖。
绑卡虽然可以多次参与，但是我们是希望他绑了后用，而不是希望他绑了再解绑然后又要他绑卡，所以我们会设置成一次性完成周期。
可以看到不同类型的任务运营起来基本上是配置是固定的，很少说在通用配置里随意切换。
这么多的组合情况也容易导致运营人员意外配置错误，并对于新加入参与业务的员工理解不友好。（先排除个人理解能力怎么样，反正我们的部分运营人员不理解怎么用，大部分时间都需要我们技术部门协助配置）
我个人建议是简化：
周期就一个维度，在周期内完成了就可以领奖，周期过了就重置，无论是否领奖。也不需要有效期，有效期没有披露给用户，对用户来说不好接受，明明我放了几天显示能领的，怎么今天一看就不能领了呢？
以上虽然是我个人想法，但是从产品的角度来看，既然已经做了一个“灵活性”这么好的，那完全没必要再花时间把他降级呀？
因此本系列只基于原业务进行讨论。
任务页面加载过慢
有多慢？11秒。具体问题分析与优化在下一篇文章《.NET-记一次架构优化实战与方案-前端优化》讨论。
代码冗余
因为早期开发时缺少沟通，很多可以公共的方法单独实现了一套。
时效性低
这个问题主要是因为早期设计的活动触发方式由JOB定时跑导致的。
有些人会认为，只要把JOB的频率调快就可以解决了，这不很简单吗？无论频率快慢都会存在相应的问题。
以上具体两个问题问题分析与优化在下一篇文章《.NET-记一次架构优化实战与方案-底层服务优化》讨论。
结尾
本篇花了一些时间整理了业务流程与问题点，为了更好的理解与验证是否最适合的方案，业务整理的过程无法避免的。如果有其他的问题，可在下方评论反馈给我。