歡迎光臨
每天分享高質量文章

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

前言

  程式員輸出是他敲寫的代碼,那麼輸入就是他思考好的設計。因此不做設計是不存在,設計只分優秀的設計和糟糕的設計。為了避免過度設計浪費成本,需要針對現有業務與問題進行展開。業務梳理是不可避免的。

  優化是無止盡,為了更有成效的優化,必須瞭解已有的問題與需要優化的標的。

業務背景

   通過做任務獲得增值獎勵等形式,達到以下標的:

  • 引導用戶完成與業務相關指定行為,進而參與業務
  • 提高用戶業務黏度,減少用戶流失
  • 完成日常指定任務,培養用戶APP使用習慣等

業務梳理

業務簡述

  • 運營配置:由公司運營人員在運營系統對相關業務的活動進行配置。

  • 任務串列:配置好的活動將在用戶端展示給用戶觀看,並給與【領獎】或【引導完成】的動作。

  • 底層服務:根據已完成的業務資料源與其相關的活動配置,進行定時跑批完成任務與發放獎勵。

業務關鍵點

  • 三步驟

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

  • 十二個任務型別

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

  • 三個周期
    • 不限
    • 按日
    • 按周
    • 按月
    • 一次性
    • 日迴圈
    • 周迴圈
    • 月迴圈
    • 單次迴圈
    • 參與周期:隱藏屬性不需要配置
    • 任務周期:運營系統配置
    • 領獎周期:運營系統配置
  • 7天領獎有效期

業務例子

  為了更加好的理解,我以簽到任務舉個例子:

  配置:簽到參與周期為每天一次,完成周期為周迴圈,領獎周期為按周,任務完成條件需要連續簽到3天

  場景:用戶已經在在星期日、星期一、星期二連續簽到了3天,那麼符合了完成條件,也在完成周期範圍內,因此可以完成任務並且領獎。

  但是如果繼續簽到 星期三、四、五連續三天,雖然可以繼續參與任務,但是不可完成,因為任務周期是周迴圈。

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

業務流程圖

存在問題

業務過度設計

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

  然而真實場景下,真正用到的組合併不多。

例如:

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

  綁卡雖然可以多次參與,但是我們是希望他綁了後用,而不是希望他綁了再解綁然後又要他綁卡,所以我們會設置成一次性完成周期。

  可以看到不同型別的任務運營起來基本上是配置是固定的,很少說在通用配置里隨意切換。

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

  我個人建議是簡化

  周期就一個維度,在周期內完成了就可以領獎,周期過了就重置,無論是否領獎。也不需要有效期,有效期沒有披露給用戶,對用戶來說不好接受,明明我放了幾天顯示能領的,怎麼今天一看就不能領了呢?

  以上雖然是我個人想法,但是從產品的角度來看,既然已經做了一個“靈活性”這麼好的,那完全沒必要再花時間把他降級呀?

因此本系列只基於原業務進行討論。

任務頁面加載過慢

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

代碼冗餘

  因為早期開發時缺少溝通,很多可以公共的方法單獨實現了一套。

時效性低

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

  有些人會認為,只要把JOB的頻率調快就可以解決了,這不很簡單嗎?無論頻率快慢都會存在相應的問題。

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

結尾

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

赞(0)

分享創造快樂