目录

*
.NET-记一次架构优化实战与方案-梳理篇 <https://www.cnblogs.com/skychen1218/p/10320951.html>

*
.NET-记一次架构优化实战与方案-前端优化 <https://www.cnblogs.com/skychen1218/p/10320994.html>

*
.NET-记一次架构优化实战与方案-底层服务优化 <https://www.cnblogs.com/skychen1218/p/10320998.html>

前言


  程序员输出是他敲写的代码,那么输入就是他思考好的设计。因此不做设计是不存在,设计只分优秀的设计和糟糕的设计。为了避免过度设计浪费成本,需要针对现有业务与问题进行展开。业务梳理是不可避免的。

  优化是无止尽,为了更有成效的优化,必须了解已有的问题与需要优化的目标。

业务背景

   通过做任务获得增值奖励等形式,达到以下目标:

* 引导用户完成与业务相关指定行为,进而参与业务
* 提高用户业务黏度,减少用户流失
* 完成日常指定任务,培养用户APP使用习惯等
业务梳理

业务简述

* 运营配置:由公司运营人员在运营系统对相关业务的活动进行配置。
*  
* 任务列表:配置好的活动将在用户端展示给用户观看,并给与【领奖】或【引导完成】的动作。  
*  
* 底层服务:根据已完成的业务数据源与其相关的活动配置,进行定时跑批完成任务与发放奖励。
业务关键点

* 三步骤
  参与、完成、领奖,一个用户完成一个活动必须经历前面三个步骤

* 十二个任务类型
  注册、实名、风险评测、签到……意见反馈等等(避免过多的暴露公司业务,不一一例举)

* 三个周期
* 参与周期:隐藏属性不需要配置
* 任务周期:运营系统配置
* 一次性
* 日循环
* 周循环
* 月循环
* 单次循环
* 领奖周期:运营系统配置
* 不限
* 按日
* 按周
* 按月
*
7天领奖有效期

业务例子

  为了更加好的理解,我以签到任务举个例子:

  配置:签到参与周期为每天一次,完成周期为周循环,领奖周期为按周,任务完成条件需要连续签到3天。

  场景:用户已经在在星期日、星期一、星期二连续签到了3天,那么符合了完成条件,也在完成周期范围内,因此可以完成任务并且领奖。

  但是如果继续签到 星期三、四、五连续三天,虽然可以继续参与任务,但是不可完成,因为任务周期是周循环。

  再假设上面的配置只修改了完成周期为日循环,
仍然是星期日到星期5连续签到,在星期二的时候可以完成并且领奖一次,在星期五的时候又可完成任务,但是这个时候不能领奖,因此领奖周期按周,所以必须等到下个星期日,才能领奖。

业务流程图



存在问题

业务过度设计

  本业务一共有3个维度,参与、完成、领奖,其场景共有X*Y*Z的个数。原本产品的意思是想做一个灵活性比较大的配置,只要有新的活动来,可以随意组合应对。

  然而真实场景下,真正用到的组合并不多。

例如:

  签到几乎连续一个月签一个月才能完成与领奖。

  绑卡虽然可以多次参与,但是我们是希望他绑了后用,而不是希望他绑了再解绑然后又要他绑卡,所以我们会设置成一次性完成周期。

  可以看到不同类型的任务运营起来基本上是配置是固定的,很少说在通用配置里随意切换。


  这么多的组合情况也容易导致运营人员意外配置错误,并对于新加入参与业务的员工理解不友好。(先排除个人理解能力怎么样,反正我们的部分运营人员不理解怎么用,大部分时间都需要我们技术部门协助配置)

  我个人建议是简化:


  周期就一个维度,在周期内完成了就可以领奖,周期过了就重置,无论是否领奖。也不需要有效期,有效期没有披露给用户,对用户来说不好接受,明明我放了几天显示能领的,怎么今天一看就不能领了呢?

  以上虽然是我个人想法,但是从产品的角度来看,既然已经做了一个“灵活性”这么好的,那完全没必要再花时间把他降级呀?

因此本系列只基于原业务进行讨论。

任务页面加载过慢

  有多慢?11秒。具体问题分析与优化在下一篇文章《.NET-记一次架构优化实战与方案-前端优化
<https://www.cnblogs.com/skychen1218/p/10320994.html>》讨论。

代码冗余

  因为早期开发时缺少沟通,很多可以公共的方法单独实现了一套。

时效性低

  这个问题主要是因为早期设计的活动触发方式由JOB定时跑导致的。

  有些人会认为,只要把JOB的频率调快就可以解决了,这不很简单吗?无论频率快慢都会存在相应的问题。

  以上具体两个问题问题分析与优化在下一篇文章《.NET-记一次架构优化实战与方案-底层服务优化
<https://www.cnblogs.com/skychen1218/p/10320998.html>》讨论。

结尾

  本篇花了一些时间整理了业务流程与问题点,为了更好的理解与验证是否最适合的方案,业务整理的过程无法避免的。如果有其他的问题,可在下方评论反馈给我。