如何設計一個高可用的運營系統

概述

一個產品業務的發展老是離不開運營二字。隨着業務快速的發展以及新業務的擴充，運營需求愈來愈大，而且不少時候須要追熱點，所以在有限的資源下，如何作到快速、準確、靈活、穩定的知足日趨增多的運營需求，成了個問題。咱們根據運營的四個基本要數（目標、人羣、門檻、激勵）經過對活動的抽象、建模、組件化，實現了能知足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

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

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