轉載自? ?如何設計一個高可用的運營系統

這是一篇來自粉絲的投稿，作者【林灣村龍貓】近一年在做關于運營活動方面的設計。本文是他的關于運營活動的總結，Hollis做了一點點修改。

?

概述

一個產品業務的發展總是離不開運營二字。隨著業務快速的發展以及新業務的擴充，運營需求越來越大，并且很多時候需要追熱點，因此在有限的資源下，如何做到快速、準確、靈活、穩定的滿足日趨增多的運營需求，成了個問題。我們根據運營的四個基本要數（目標、人群、門檻、激勵）通過對活動的抽象、建模、組件化，實現了能滿足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編輯就完美了

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

?

一些個人觀點

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

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

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

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

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的如何设计一个高可用的运营系统的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。