.NET-記一次架構優化實戰與方案-梳理篇

目錄

1. .NET-記一次架構優化實戰與方案-梳理篇

2. .NET-記一次架構優化實戰與方案-前端優化

3. .NET-記一次架構優化實戰與方案-底層服務優化

前言

　　程序員輸出是他敲寫的代碼，那麼輸入就是他思考好的設計。所以不作設計是不存在，設計只分優秀的設計和糟糕的設計。爲了不過分設計浪費成本，須要針對現有業務與問題進行展開。業務梳理是不可避免的。

　　優化是無止盡，爲了更有成效的優化，必須瞭解已有的問題與須要優化的目標。

業務背景

 　　經過作任務得到增值獎勵等形式，達到如下目標：

• 引導用戶完成與業務相關指定行爲，進而參與業務
• 提升用戶業務黏度，減小用戶流失
• 完成平常指定任務，培養用戶APP使用習慣等

業務梳理

業務簡述

• 運營配置：由公司運營人員在運營系統對相關業務的活動進行配置。
  •  
• 任務列表：配置好的活動將在用戶端展現給用戶觀看，並給與【領獎】或【引導完成】的動做。
   
  •  
• 底層服務：根據已完成的業務數據源與其相關的活動配置，進行定時跑批完成任務與發放獎勵。

業務關鍵點

• 三步驟

　　參與、完成、領獎，一個用戶完成一個活動必須經歷前面三個步驟

• 十二個任務類型

　　註冊、實名、風險評測、簽到……意見反饋等等（避免過多的暴露公司業務，不一一例舉）

• 三個週期
  • 參與週期：隱藏屬性不須要配置
  • 任務週期：運營系統配置
    • 一次性
    • 日循環
    • 周循環
    • 月循環
    • 單次循環
  • 領獎週期：運營系統配置
    • 不限
    • 按日
    • 按周
    • 按月

• 7天領獎有效期

業務例子

　　爲了更加好的理解，我以簽到任務舉個例子：

　　配置：簽到參與週期爲天天一次，完成周期爲周循環，領獎週期爲按周，任務完成條件須要連續簽到3天。

　　場景：用戶已經在在星期日、星期1、星期二連續簽到了3天，那麼符合了完成條件，也在完成周期範圍內，所以能夠完成任務而且領獎。

　　可是若是繼續簽到 星期3、4、五連續三天，雖然能夠繼續參與任務，可是不可完成，由於任務週期是周循環。

　　再假設上面的配置只修改了完成周期爲日循環，仍然是星期日到星期5連續簽到，在星期二的時候能夠完成而且領獎一次，在星期五的時候又可完成任務，可是這個時候不能領獎，所以領獎週期按周，因此必須等到下個星期日，才能領獎。

業務流程圖

存在問題

業務過分設計

　　本業務一共有3個維度，參與、完成、領獎，其場景共有X*Y*Z的個數。本來產品的意思是想作一個靈活性比較大的配置，只要有新的活動來，能夠隨意組合應對。

　　然而真實場景下，真正用到的組合並很少。

例如：

　　簽到幾乎連續一個月籤一個月才能完成與領獎。

　　綁卡雖然能夠屢次參與，可是咱們是但願他綁了後用，而不是但願他綁了再解綁而後又要他綁卡，因此咱們會設置成一次性完成周期。

　　能夠看到不一樣類型的任務運營起來基本上是配置是固定的，不多說在通用配置裏隨意切換。

　　這麼多的組合狀況也容易致使運營人員意外配置錯誤，並對於新加入參與業務的員工理解不友好。（先排除我的理解能力怎麼樣，反正咱們的部分運營人員不理解怎麼用，大部分時間都須要咱們技術部門協助配置）

　　我我的建議是簡化：

　　週期就一個維度，在週期內完成了就能夠領獎，週期過了就重置，不管是否領獎。也不須要有效期，有效期沒有披露給用戶，對用戶來講很差接受，明明我放了幾天顯示能領的，怎麼今天一看就不能領了呢？

　　以上雖然是我我的想法，可是從產品的角度來看，既然已經作了一個「靈活性」這麼好的，那徹底不必再花時間把他降級呀？

所以本系列只基於原業務進行討論。

任務頁面加載過慢

　　有多慢？11秒。具體問題分析與優化在下一篇文章《.NET-記一次架構優化實戰與方案-前端優化》討論。

代碼冗餘

　　由於早期開發時缺乏溝通，不少能夠公共的方法單獨實現了一套。

時效性低

　　這個問題主要是由於早期設計的活動觸發方式由JOB定時跑致使的。

　　有些人會認爲，只要把JOB的頻率調快就能夠解決了，這不很簡單嗎？不管頻率快慢都會存在相應的問題。

　　以上具體兩個問題問題分析與優化在下一篇文章《.NET-記一次架構優化實戰與方案-底層服務優化》討論。

結尾

　　本篇花了一些時間整理了業務流程與問題點，爲了更好的理解與驗證是否最適合的方案，業務整理的過程沒法避免的。若是有其餘的問題，可在下方評論反饋給我。