0 背景
重運營的應用。對於App裡的頂導航、我的頁面、彈窗等，需要根據模式、版本、平臺、語言、渠道等不同的維度進行運營管理。隨著業務快速發展，版本快速迭代，如何：
- 保持運營資源能夠被高效、穩定和靈活地配置
- 高效穩定的為新的運營需求提供支援
透過打造一個穩定、靈活、高效的運營配置平臺來解決前面遇到的問題。本文主要分享我們在建設高效的運營配置平臺過程中積累的一些經驗以及面臨的挑戰和思考。
1 配置資源拆解
運營類配置分類：
- 運營資源
- 基礎資料
| 運營資源範例：彈窗 | 基礎資料：底部導航 |
|---|---|
 |  |
1.1 運營資源
運營資源可理解為App中經常變動的一些廣告、運營活動等。比如上圖中彈窗廣告，就是一個典型的運營資源。
1.1.1 特徵
① 時效性強
只在一定時間範圍內顯示在C端固定位置。
② 模式強相關
每個活動、廣告都只會出現在固定的某些模式。
③ 資料變動頻繁
特別是活動類資料，展示的圖片文案等變動較為頻繁
④ 支援多語言展示
基於公司海外站面向全球使用者的情況，不同模式需展示不同語言文案。
1.2 基礎資料配置
基礎資料配置相對於運營資源來說其變更的頻率相對較低，與時間、版本的關係也沒那麼強。譬如下面愛奇藝海外App-底部導航欄（樣式如上圖）。
1.2.1 特徵
① 多維度
需要針對不同的模式、語言做不同的配置。
② 長期有效
這種型別的配置一般長期存在，過期場景較少。
2 實踐痛點
面對接二連三運營配置需求，最初實現不同的配置介面來對接各類運營產品需求。但這必然很大問題
2.1 運營效率低
新運營配置需求，研發要開發對應配置頁面，然後轉給運營同學進行配置的管理，最後運營人員對資源進行配置上線，流程圖：
每個運營配置需求都經需求評審、頁面開發、配置管理、上線。配置頁面開發，少則1到2天，問題就在：
- 研發成本高，每個需求要開發新的配置管理頁面
- 研發週期長，運營效率低，從需求的提出到運營上線週期長
- 靈活性差，對不同的運營維度（模式、版本、時間等）都需要事先確定好，無法動態調整
2.2 頻繁重複開發
通用型的運營配置後臺，某些特有功能特別對於前後端來說重複開發工作明顯。如操作記錄，稽核機制，根據不同的模式版本語言過濾資料等功能，在每次出現的配置需求中都需重複開發。
3 實踐中的思考
希望設計一個通用解決方案，去解決上文闡述的各種運營資源管理的問題。我們把這個專案稱為運營位。
調研確認
3.0 專案設計原則
- 一切資料皆可配
- 運營資料高可用
- 介面效能高效
不斷實踐和總結，抓手如下：
3.1 資料JSON化
隨業務迭代，無論採用啥資料欄位組成，都很難滿足業務變化欄位（標題、副標題、圖片、跳轉連結等）要求。對底層資料進行JSON化，對應資料欄位即可實現可動態擴充套件，滿足業務迭代需求。JSON化帶來運營位欄位管理問題，在運營後臺提供欄位管理功能即可解決。
3.2 運營資料多點儲存
持久化儲存，分散式快取，以及接入業務方的本地快取，運營資料的多方儲存，保證極端情況都有降級資料獲取，降低系統異常損失。
3.3 介面SDK化
運營資料，無論透過資料庫的落地方案、還是分散式快取，都無法徹底解決服務中心化和服務抖動。透過接入的SDK化，實現資料的本地快取更新機制，解除對中心化服務的依賴，提升服務穩定性和效能。同時整個運營位服務變成可水平擴充套件，在擴充套件過程中也不會影響中心服務的穩定性。
呼叫方請求流程圖
4 運營位架構
運營位配置系統整體框架圖。從功能角度，大體上分為四層：資料層、服務層、接入層和監控層。
4.0 運營位架構圖
4.1 資料層
主要儲存接入運營位的各類運營資料。
難點
- 資料量大
- QPS高
可透過redis叢集做中間快取，透過SDK使各業務方接入本地快取、透過訊息監聽非同步更新，以解決中心服務的流量壓力。
4.2 服務層
服務層向下對底層資料進行操作；向上為接入層獲取資料提供接入能力。提供四個服務能力：
- 運營後臺，面向運營人員和產品，提供資料的配置後臺
- 開放平臺，收歸開發技術人員，提供一個增加運營位配置的後臺
- 資料服務，主要是為呼叫資料的開發提供一個統一的、高可用的、高效能的api介面
- SDK，服務於資料服務，主要簡化開發人員的接入成本，提供資料服務效能和可用性
4.3 接入層
4.3.1 C端接入咋方便？
為簡化開發接入成本，呼叫邏輯在SDK內實現，使用者只需引入maven包，注入OppkitClient，封裝OppkitRequest，透過OppkitClient直接呼叫即可返回過濾並且翻譯後的資料。
4.3.2 B端配置咋更便捷？
設計專案時，後臺配置的唯一原則：一切皆可配置。透過開放後臺來配置運營位，每個運營位相當於一個業務形態，如導航欄，而運營位包含多個資料，如title，link，title包含多種語言，需配置多語言key：
- 開放平臺就是建立運營位，為運營位配置欄位
- 運營後臺，配置開放平臺建立的運營位資料
4.4 監控層
除了資料儲存層監控及烽火臺對資料層與服務層的監控，還監控SDK內實現的本地快取。
C端的接入即資料的獲取在SDK內部實現，SDK內部實現功能：
- 若請求包含某些特定離散欄位如裝置id，因資料量極大，存入本地快取會給業務方機器記憶體壓力，則避開快取直接請求服務
- 為滿足資料實時性要求較高業務方，新增不接入本地快取的邏輯
- 若只包含某些聚合度高欄位如平臺、版本、模式和語言等，則把請求的資料存入本地快取。本地快取透過監聽運營平臺的方式進行非同步更新，當非同步更新獲取資料失敗，則保持之前的資料返回，避免極端情況運營資料全部為空，將業務損失降至最低
- SDK內部透過非同步執行緒，將本地快取使用情況透過定時執行緒存入，透過後臺介面展示各快取使用情況，實時監控各類快取使用
5 穩定性與效能
運營後臺穩定性與效能保障方案。
5.0 整體請求流程圖
5.1 穩定性保障
各類運營資料配置的運營後臺，穩定性很重要。
除了操作機制即運營流程化資料配置機制、多級資料儲存使用分散式快取及分散式資料庫，還提供SDK方案來對服務故障進行降級。來看該方案落地過程。
5.2 SDK本地快取方案
實現本地快取好處
- 緩解中心服務的流量壓力，更多流量請求到本地服務的記憶體
- 基於海外站業務特點，國外網路環境不可預測，環境差，儘可能減少網路請求鏈路
- 一旦中心服務故障，周知各業務方不要重新部署，以本地快取實現資料降級
本地快取方案缺點明顯
一旦有運營後臺資料更新，各業務方無法實時獲取最新資料。對此，SDK開始迭代：
| 系統流程 | 說明 |
|---|---|
 | 架構簡單，實現方便。但併發差，穩定性不夠。 |
 | 本地快取，部分緩解中心服務的流量壓力。但造成資料不一致。 |
 | 實現OPPKIT-SDK，在SDK內部實現本地快取，同時SDK內部透過訊息監聽機制。 |
架構三版，較好解決中心服務流量問題，使運營後臺流量由使用者請求量決定改為後臺的資料更新頻率決定，從而解決流量過載問題。但該版也要解決：
各業務方本地快取的使用情況種類繁多，如何進行提供系統監控？
MQ方案設計
針對問題1，SDK內部透過scheduledexecutorservice定時任務，週期性將快取使用情況拉取到庫內，透過後臺介面根據時間展示本地快取使用情況。可掌握各業務方快取使用情況，給業務方記憶體申請和分配提供資料支撐。
針對問題2，涉及難點：
業務服務機器一般叢集部署，一個訊息的更新需要被多臺部署相同程式碼的伺服器同時消費，確保每臺機器都獲取到最新的資料
訊息Producer是運營後臺服務，而一個訊息要被所有業務方監聽，即所有業務方的每臺機器。所以，每臺機器應屬不同消費組。所以要找到一個每臺機器都不一樣的標識節點，以該節點做消費組。顯然，最好的就是機器地址，可保證每臺機器所在分組不同
運營位有多個，但對於業務方，沒必要在未接入的運營位更新資料時去非同步請求運營後臺中心服務更新資料（因為這些資料這個業務方根本沒接入）
提供一個配置檔案，各業務方在配置檔案內寫入各自業務方使用的運營位名稱，當一個訊息來臨，先判斷訊息中的運營位名稱是否包含在配置檔案：若不在，則這條訊息被忽略（空消費）；在，則請求響應的運營位更新本地資料
5.3 效能保障
SDK提供本地快取可提高後端服務效能。運營位實踐配置中發現，運營人員更改運營資料情形相比網路請求來說非常低頻，如基礎運營資料。因此，資料快取在客戶端可避免客戶端與後端服務網路消耗，極大提高效能。
可為每個運營位資料提供一個版本。透過儲存各運營位的操作最新時間，在客戶端開屏時發起一次請求，將所有運營位最近資料更新時間返給客戶端，客戶端將該時間戳快取本地，當下次開屏請求時，同樣獲取到服務端返回的運營位最近更新時間戳，將本地的與服務的進行匹配，確認是否去更新各運營位資料，如果客戶端快取的運營資料時間與運營後臺返回一致，則直接展示快取在客戶端的資料。
這方案另一好處是極端時如對外暴露API4故障，透過禁止運營後臺的資料更新，可使業務資料正常展示，避免運營資料消失的嚴重故障。
5.4 請求流程圖
6 總結
本文主要介紹了運營位設計開發，先根據痛點提出運營後臺設計原則，針對原則去思考與實現具體技術方案：
- 配置資料Json化實現業務欄位可擴充套件性
- 設計的資料模型來介紹滿足多語言下各類運營配置資料方法
- 提供SDK內部實現本地快取，MQ監聽，非同步更新解決服務中心化的大流量問題和快取導致資料不一致問題。針對海外具體情況，提出客戶端快取的相關方案
如錯誤碼配置舉例，錯誤碼需要給客戶端返回各類錯誤碼以及對應的相關文案，文案是多語言場景的，透過運營位配置化實現，只需要在分析需求，拆分業務欄位和資料露出的條件後，很快就可以給出相應的運營後臺。
關注我，緊跟本系列專欄文章，我們們下篇再續！
作者簡介：魔都技術專家兼架構，多家大廠後端一線研發經驗，各大技術社群頭部專家博主，程式設計嚴選網創始人。具有豐富的引領團隊經驗，深厚業務架構和解決方案的積累。
負責：
- 中央/分銷預訂系統效能最佳化
- 活動&優惠券等營銷中臺建設
交易平臺及資料中臺等架構和開發設計
目前主攻降低軟體複雜性設計、構建高可用系統方向。
參考：