.NET-记一次架构优化实战与方案-梳理篇 .NET-记一次架构优化实战与方案-梳理篇 .NET-记一次架构优化实战与方案-前端优化 .NET-记一次架构优化实战与方案-底层服务优化 .NET-记一次

目录

1. .NET-记一次架构优化实战与方案-梳理篇

2. .NET-记一次架构优化实战与方案-前端优化

3. .NET-记一次架构优化实战与方案-底层服务优化

前言

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

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

业务背景

 　　经过作任务得到增值奖励等形式，达到如下目标：

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

业务梳理

业务简述

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

业务关键点

• 三步骤

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

• 十二个任务类型

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

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

• 7天领奖有效期

业务例子

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

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

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

　　可是若是继续签到 星期3、4、五连续三天，虽然能够继续参与任务，可是不可完成，由于任务周期是周循环。

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

业务流程图

存在问题

业务过分设计

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

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

例如：

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

　　绑卡虽然能够屡次参与，可是咱们是但愿他绑了后用，而不是但愿他绑了再解绑而后又要他绑卡，因此咱们会设置成一次性完成周期。

　　能够看到不一样类型的任务运营起来基本上是配置是固定的，不多说在通用配置里随意切换。

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

　　我我的建议是简化：

　　周期就一个维度，在周期内完成了就能够领奖，周期过了就重置，不管是否领奖。也不须要有效期，有效期没有披露给用户，对用户来讲很差接受，明明我放了几天显示能领的，怎么今天一看就不能领了呢？

　　以上虽然是我我的想法，可是从产品的角度来看，既然已经作了一个“灵活性”这么好的，那彻底不必再花时间把他降级呀？

所以本系列只基于原业务进行讨论。

任务页面加载过慢

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

代码冗余

　　由于早期开发时缺乏沟通，不少能够公共的方法单独实现了一套。

时效性低

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

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

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

结尾

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