概述

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

引子

通常，我們做一個活動，我們需要做什么？我們需要UI設計、前端排版、接口定義、數(shù)據庫創(chuàng)建、測試流程等等。這樣下來整個流程快一點上一個活動大概一周左右，慢一點可能兩周左右。但很多時候，一個活動的生命周期可能就一周、一個月左右。我們是否有必要花如此大的開發(fā)代價去做這樣事情？一個活動如此，那十個，一百個呢。

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

3個活動

活動1，為了拉新，針對老用戶，每拉來一個人，獎勵20元的額度提升。 活動2，為了拉GMV，針對老用戶，每還款xx元，獎勵多少優(yōu)惠券。 活動3，為了拉綁卡，針對全部用戶，完成綁卡，就有機會搶100張1000元現(xiàn)金券。 … 我們可以發(fā)現(xiàn)活動的四個要素：人群、目標、門檻、激勵 我們可以用一句話概括運營活動：

針對什么人群，我們想要達到什么目標，設置什么樣的門檻（規(guī)則），最后給用戶什么樣的激勵措施。

活動生命周期這么短，我們是否可以以比較小的開發(fā)代價來完成活動的開發(fā)呢？ 是否針對某個業(yè)務的一個活動開發(fā)完？我可以快速的復用到其他業(yè)務上呢？

在這些活動的開發(fā)中，我們遇到了挑戰(zhàn)和難題：

• 可維護性差：活動的生命周期短，活動下線，接口、數(shù)據庫廢棄，但代碼遺留，代碼維護性差。

• 開發(fā)效率低：重復開發(fā)、開發(fā)效率低、無法復用。每個活動新建接口、新建數(shù)據庫表

• 可擴展性不高：每個活動只能運用到自己的業(yè)務上，無法快速復用到其他業(yè)務。

• 性能和監(jiān)控: 無可靠的數(shù)據監(jiān)控、性能低下。

• 安全低：沒有做接口簽名、接口限流等等，容易被刷。

運營要做什么？

于是我花了一段時間來系統(tǒng)性的來梳理運營體系相關東西，通過已經做了什么，來思考，我們將來怎么做？

運營體系結構

• 接入業(yè)務：具體的產品，我們才有運營他的基礎。

• 運營活動：有了具體的業(yè)務，通過運營活動來運營業(yè)務。

• 用戶觸達：活動出來后，我們需要告知用戶才行。

• 數(shù)據分析：活動效果如何，我們需要分析數(shù)據，改進我們的方案。

• 監(jiān)控告警：系統(tǒng)本身不是100%可靠，我們需要一些儀表盤來監(jiān)控我們的系統(tǒng)。

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

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

• 組件化系統(tǒng)：是否有個可視化的界面，以便于運營人員的快速接入呢。

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

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

系統(tǒng)架構設計

系統(tǒng)的架構設計

從上往下看：

• 前端層：做前后分離，動靜分離、接入按鈕觸發(fā)統(tǒng)計系統(tǒng)、組件化模塊。

• 網關層：接入協(xié)議適配、簽名校驗，接口監(jiān)控統(tǒng)計、限流等等。保障接口安全。

• 邏輯層：分三個子層。

• 第一層：接入統(tǒng)一配置中心，接口標準統(tǒng)一化、插件化、組件化常用模塊。消息處理引入觀察者，抽象公用模塊。

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

• 第三層：抽象所有活動儲存結構（標簽服務）、配置、監(jiān)控、分布式鎖計數(shù)器以服務形式提供給上層調用。

• 基礎平臺：一些依賴的基礎能力：比如用戶信息、訂單信息、平臺優(yōu)惠券系統(tǒng)、基礎推送能力等等。

• 存儲層：所有活動數(shù)據以統(tǒng)一結構存儲。

從左往右看：

• 一個活動可以快速復用到其他業(yè)務。

• 將活動通過廣告系統(tǒng)、消息推送系統(tǒng)等推送出去。通過數(shù)據分析系統(tǒng)做數(shù)據分析和優(yōu)化活動流程。

說明幾個點：

1.活動路由

• 所有接口統(tǒng)一通過SaleService.handler接入

• 根據活動ID與方法找到對應執(zhí)行方法。

• 參考MVC的路由方式

• 通過反射+代理模式實現(xiàn)

活動路由規(guī)則

這樣做的一些好處：

• 由于活動的什么周期短，可以通過對配置的更改，調整接口的有無。維護方便。

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

• 可以與配置系統(tǒng)深度整合。

• 做一些接口監(jiān)控和攔截。

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

• 觀察者模式

• 對修改關閉，對擴展開放

image.png

3.統(tǒng)一配置中心

可以參考之前寫的 【180425】統(tǒng)一配置中心：https://www.jianshu.com/p/edce8e8c139e

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

4.關于組件化

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

魔方系統(tǒng)-組件化結構.jpg

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

前后端如何通過組件交互？

魔方系統(tǒng)-交互圖.png

最好能，在OA編輯就完美了

OA可視化編輯

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

一些個人觀點

• 程序的開發(fā)，應該是一個搭積木的過程，一些小的模塊組合成一個中等模塊，若干中等模塊組合成一個系統(tǒng)，若干系統(tǒng)組合成一個業(yè)務等等。

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

• 了解業(yè)務，才能做出更好的系統(tǒng)設計。

• 性能、可用性、可擴展性、可伸縮性、安全。

想要了解更多關于用戶運營的干貨知識，請繼續(xù)關注135編輯器。