.NET-架构优化实战-梳理篇

原文:.NET-架构优化实战-梳理篇

前言

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

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

业务背景

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

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

业务梳理

业务简述

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

业务关键点

• 三步骤

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

• 十二个任务类型

　　注册、实名、风险评测、签到……意见反馈等等（避免过多的暴露公司业务，不一一例举）

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

• 7天领奖有效期

业务例子

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

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

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

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

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

业务流程图

存在问题

业务过度设计

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

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

例如：

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

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

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

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

　　我个人建议是简化：

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

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

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

任务页面加载过慢

　　有多慢？11秒。具体问题分析与优化在下一篇文章《.NET-架构优化实战-前端优化》讨论。

代码冗余

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

时效性低

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

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

　　以上具体两个问题问题分析与优化在下一篇文章《.NET-架构优化实战-底层服务优化》讨论。

结尾

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