本文起了一個稍微大的名字。又是運營管理，又是中臺的。其實只是想闡述一下廣告資源運營管理系統設計，但是再一想，在大公司，這樣的運營管理系統其實是劃分到中臺範圍的。隨着公司逐漸發展壯大，剛開始一條業務線，也會逐漸衍生出多條業務線。一條業務線就是一個大部門，每個大部門又會有自己的技術部門。這時的公司其實會有多個同級的技術部門的，大家做着各自的業務，彼此會有交集。那麼這個時候中臺就出現了，中臺是解決技術服務複用問題的，也就是把共性業務抽離出來，比如消息發送模塊（發送push消息、短信、郵件等等），這個功能幾乎每個業務部門都需要，如果每個部門都開發一套消息發送程序，那實在是浪費人力、物力。共性業務無需重複開發，應該將其下沉到更底一層，形成一個獨立服務供上層業務方調用。類似這樣的服務多起來後，也就形成了中臺系統，如：用戶服務、支付服務、訂單服務等等，本文要介紹的運營管理系統，也算是中臺系統的一員。如果用面向對象思維來解讀的話，中臺就是抽象類了，各個業務方就好比繼承類，共有方法無需重寫，繼承類可以直接調用。
一款app，我們常見的廣告有閃屏、彈框、橫幅等廣告資源，每個資源基本包括圖片、文字、跳轉鏈接等字段，那麼這就需要一個系統來管理。但是運營人員投放思路是經常變化的，某天，想投放一個彈框廣告，但是隻針對android平臺的某個渠道，那麼這個系統不僅可以建廣告，還需要支持建投放規則。同時，該系統還要支持各業務線，各個業務線的運營人員都可以使用，這就還需要權限管理。
基本概念：
資源位：app上的一個位置，比如閃屏頁資源位、首頁彈窗資源位。資源位具有唯一性，可以根據自己的需求建資源位，併爲資源位分配一個code。 業務調用方就根據這個code請求廣告資源。注意這裏說的業務調用方，指的是業務方服務端，而非客戶端或前端，因爲業務線的客戶端、前端是不能直接和中臺打交道的，他們應該和各自的業務方服務端打交道。
廣告資源：圖片、文字、跳轉鏈接等基本元素。當然有的廣告複雜一些，還有按鈕什麼的。
廣告組：一組有相同屬性的廣告資源集合，廣告組還有這一組廣告展示開始時間、結束時間、結果集篩選策略（組內互斥，選一展現；還是組內多選，同時展現等）、權重等信息。
規則：根據請求參數，及配置的條條框框，決定這次請求命中哪個廣告組。
疲勞度控制：單用戶日展示上限、總展示上限、點擊N次後不再顯示等。對於某個用戶，一旦達到設定就不在下發數據。
下面是時序圖，結合上述概念看這個時序圖還是比較好懂的。
下面是一些頁面圖，新建資源位時，需要新建請求輸入參數，以及返回資源內容，比如下面例子，入參比較簡單：用戶id、平臺號、渠道號、設備號等，輸出僅有一項：跳轉鏈接，如果業務場景複雜，可以繼續建各種入參及出參。
資源位建好後，就可以建廣告組、廣告資源，以及規則。如下圖：
規則要複雜一些，資源都是靜態的，無非圖片、文字、url地址等，而規則是可配置的，並且可以隨時修改。比如上面的定向規則，根據入參平臺號，及當前設置的平臺號做匹配，匹配上纔會下發數據，規則一旦調整，需要立即生效，同時大量的查詢請求，需要及時響應，這其中需要使用大量的緩存。
羅馬不是一天建成的，這個系統也不是一次成型做成這樣，而是根據各業務線需求，不斷迭代開發纔會做到這樣。上面介紹的只是一部分功能點，該系統還可以對接數據倉庫及機器學習平臺，另外也可以看到除了配置廣告資源，其實還可以配置其他非廣告資源，屆時這個系統又可以起到一些配置中心作用。本文僅做介紹，提供一點點思路，具體像表結構如何設計、模塊如何劃分和設計，就不一一說了。不論誰做類似這樣的系統，都要相信自己能做的更好。