0 背景 重運營的應用。對於App里的頂導航、我的頁面、彈窗等，需要根據模式、版本、平臺、語言、渠道等不同的維度進行運營管理。隨著業務快速發展，版本快速迭代，如何： 保持運營資源能夠被高效、穩定和靈活地配置 高效穩定的為新的運營需求提供支持 通過打造一個穩定、靈活、高效的運營配置平臺來解決前面遇到的 ...
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監聽，非同步更新解決服務中心化的大流量問題和緩存導致數據不一致問題。針對海外具體情況，提出客戶端緩存的相關方案
如錯誤碼配置舉例，錯誤碼需要給客戶端返回各類錯誤碼以及對應的相關文案，文案是多語言場景的，通過運營位配置化實現，只需要在分析需求，拆分業務欄位和數據露出的條件後，很快就可以給出相應的運營後臺。
關註我，緊跟本系列專欄文章，咱們下篇再續！
作者簡介：魔都技術專家兼架構，多家大廠後端一線研發經驗，各大技術社區頭部專家博主，編程嚴選網創始人。具有豐富的引領團隊經驗，深厚業務架構和解決方案的積累。
負責：
- 中央/分銷預訂系統性能優化
- 活動&優惠券等營銷中台建設
- 交易平臺及數據中台等架構和開發設計
目前主攻降低軟體複雜性設計、構建高可用系統方向。
參考：
本文由博客一文多發平臺 OpenWrite 發佈！
