概述

一個產品業務的發展總是離不開運營二字。隨著業務快速的發展以及新業務的擴充，運營需求越來越大，並且很多時候需要追熱點，因此在有限的資源下，如何做到快速、準確、靈活、穩定的滿足日趨增多的運營需求，成了個問題。我們根據運營的四個基本要數（目標、人群、門檻、激勵）通過對活動的抽象、建模、元件化，實現了能滿足80%的運營需求的自動化運營系統，運營產品同學只需要通過一份配置檔案就可以生成一個新的活動。

引子

 

通常，我們做一個活動，我們需要做什麼？

我們需要UI設計、前端排版、介面定義、資料庫建立、測試流程等等。這樣下來整個流程快一點上一個活動大概一週左右，慢一點可能兩週左右。

但很多時候，一個活動的生命週期可能就一週、一個月左右。我們是否有必要花如此大的開發代價去做這樣事情？一個活動如此，那十個，一百個呢。

我們先來通過三個活動來了解一下活動的本質。

活動1，為了拉新，針對老使用者，每拉來一個人，獎勵20元的額度提升。

活動2，為了拉GMV，針對老使用者，每還款xx元，獎勵多少優惠券。

活動3，為了拉綁卡，針對全部使用者，完成綁卡，就有機會搶100張1000元現金券。

…

我們可以發現活動的四個要素：人群、目標、門檻、激勵

我們可以用一句話概括運營活動：

針對什麼人群，我們想要達到什麼目標，設定什麼樣的門檻（規則），最後給使用者什麼樣的激勵措施。

活動生命週期這麼短，我們是否可以以比較小的開發代價來完成活動的開發呢？ 是否針對某個業務的一個活動開發完？我可以快速的複用到其他業務上呢？

在這些活動的開發中，我們遇到了挑戰和難題：

可維護性差：活動的生命週期短，活動下線，介面、資料庫廢棄，但程式碼遺留，程式碼維護性差。

開發效率低：重複開發、開發效率低、無法複用。每個活動新建介面、新建資料庫表

可擴充套件性不高：每個活動只能運用到自己的業務上，無法快速複用到其他業務。

效能和監控: 無可靠的資料監控、效能低下。

安全低：沒有做介面簽名、介面限流等等，容易被刷。

運營要做什麼？

於是我花了一段時間來系統性的來梳理運營體系相關東西，通過已經做了什麼，來思考，我們將來怎麼做？

接入業務：有了具體的產品，我們才有運營他的基礎。

運營活動：有了具體的業務，通過運營活動來運營業務。

使用者觸達：活動出來後，我們需要告知使用者才行。

資料分析：活動效果如何，我們需要分析資料，改進我們的方案。

監控告警：系統本身不是100%可靠，我們需要一些儀表盤來監控我們的系統。

安全/防刷：運營是有激勵措施的，有利益，需要防止惡意侵入。

基礎能力：通過抽象化、工具化提高開發效率。

元件化系統：是否有個視覺化的介面，以便於運營人員的快速接入呢。

根據已做的活動經驗和遇到的問題，讓我不斷的思考，我該如何去優化該運營系統，來提高開發效率、安全、和效能。最後，確定的一個大方向：

平臺化、標準化、配置化、元件化。

系統架構設計

 

 

從上往下看：

前端層：做前後分離，動靜分離、接入按鈕觸發統計系統、元件化模組。

閘道器層：接入協議適配、簽名校驗，介面監控統計、限流等等。保障介面安全。

邏輯層：分三個子層。

第一層：接入統一配置中心，介面標準統一化、外掛化、元件化常用模組。訊息處理引入觀察者，抽象公用模組。

第二層：根據運營四要素，抽象出規則集（綁卡？還款等等）、獎勵集(優惠券、實物？等等)構成活動主邏輯。

第三層：抽象所有活動儲存結構（標籤服務）、配置、監控、分散式鎖計數器以服務形式提供給上層呼叫。

基礎平臺：一些依賴的基礎能力：比如使用者資訊、訂單資訊、平臺優惠券系統、基礎推送能力等等。

儲存層：所有活動資料以統一結構儲存。

從左往右看：

一個活動可以快速複用到其他業務。

將活動通過廣告系統、訊息推送系統等推送出去。通過資料分析系統做資料分析和優化活動流程。

說明幾個點：

1.活動路由

所有介面統一通過SaleService.handler接入

根據活動ID與方法找到對應執行方法。

參考MVC的路由方式

通過反射+代理模式實現

這樣做的一些好處：

由於活動的什麼週期短，可以通過對配置的更改，調整介面的有無。維護方便。

可以很方便的做一些公共校驗或埋一些鉤子，（比如是否限制登入、是否過期等）

可以與配置系統深度整合。

做一些介面監控和攔截。

2. mq訊息（訊息的解耦）

觀察者模式

對修改關閉，對擴充套件開放

3.統一配置中心

可以參考之前寫的統一配置中心

這裡可以優化的點是，引入版本號，先更新配置+新的版本號到redis，然後再更新每個配置的版本號id, 客戶端來取配置的時候，先取配置的版本，在根據版本號+配置key去redis中取配置內容，這樣可以平滑的將快取配置切換到新的快取配置。

4.關於元件化

一個活動通常可以看成若干個元件組成。

每一個元件又有他自己的特性。

前後端如何通過元件互動？

最好能在OA編輯就完美了

最後，通過一些配置，可以快速的上線一些活動，無需開發接入，做到自動化運營。

一些個人觀點

程式的開發，應該是一個搭積木的過程，一些小的模組組合成一箇中等模組，若干中等模組組合成一個系統，若干系統組合成一個業務等等。

一個大的問題，可以分層分模組成若干小問題，解決若干小問題，最後解決大問題。

瞭解業務，才能做出更好的系統設計。

系統設計，要充分考慮到效能、可用性、可擴充套件性、可伸縮性、安全性等。

歡迎工作一到五年的Java工程師朋友們加入Java架構開發：744677563

本群提供免費的學習指導 架構資料 以及免費的解答

不懂得問題都可以在本群提出來 之後還會有職業生涯規劃以及面試指導