移動終端的開發變得越來越複雜，隨之而來的是對 C 端動態化要求越來越高。動態化需要對 C 端裡的基礎配置、運營資源進行靈活的管理。如何在版本快速迭代過程中，滿足業務場景的高效靈活變更？傳統的解決方案無法滿足這種複雜場景，美團點評基於自身移動運營的實踐，打造了穩定、靈活、高效的運營配置平臺。本文根據美團點評高級架構師蔣國寶在 QCon 上海的演講整理而成。
兩年前，我以聽眾身份參加了一次 QCon 大會。那次大會提升了我自己在技術的深度和廣度，讓我受益匪淺。今年很榮幸作為受邀講師參加 QCon 上海站，在這次主題中我分享了自己這幾年來做運營配置平臺的一些經驗和感悟。希望能給同行在解決類似問題的時候一些新思路和新方向。
1
打造好一個運營配置平臺最重要的點是什麼？
運營配置平臺是滿足產品在迭代過程中不斷變化的一些配置資源（包括圖片、文本、鏈接等）的管理。主要有三個關鍵點：
- 第一個是高效，如何理解高效？簡單來說就是好用，運營配置平臺是給產品同學用的。交付給產品的工具，你不可能說這個東西你去改改數據庫它就生效了。那肯定行不通，產品同學也不知道數據庫如何操作。況且，你不可能讓產品同學去寫 SQL。
- 第二個是靈活。靈活怎麼理解？因為產品的需求是不斷變化的，我們很難琢磨產品整個業務形態的發展變化，所以運營配置平臺要做的足夠靈活才能滿足產品不斷迭代的需求。
- 第三點是穩定，我是做移動後端的，為 C 端用戶提供數據服務。從後端的角度來看穩定性是第一位的，無論什麼時候都不能掛。即使掛了，接入方還能正確獲取到你的數據。做到這點，穩定性就有很大的保障。
2
高效的工具平臺可以從哪幾個點入手？
通過這些年積累的經驗，我覺得可以從以下幾個方面進行著手。
第一點就是所見即所得的可視化界面，這樣能大大提升操作的便捷性，也易於理解。在這裡，我通過一個商戶頁的模塊化例子做了詳細的說明。如下圖所示，對商戶頁做一個模塊化的拆分，拆分後的模塊可進行自由的組裝和排序，從而達到運營可配置。
在運營配置界面，我們做了一個可視化的操作界面（如下圖）。操作界面的最左邊是可複用的模塊池列表，這些可複用的模塊列表是 C 端同學開發並積累起來的。操作界面的中間部分是動態化的配置管理，運營同學可對模塊進行靈活的調整，包括模塊的添加、刪除、以及順序的調整等。操作界面最右邊是實際在 C 端顯示的效果。
第二點是上線的流程化， 配置完成之後是不是直接生效？我們最開始做的版本就是配置完成後點提交就生效。這樣的流程會有什麼問題？大家想一想，如果我配置錯了，那是不是會影響生產環境？對用戶造成困惑，這是一個關鍵點。另外，在不同的商戶頁裡它所需要的配置是不一樣的。比如說餐飲如果配置一個親子的模塊，那就是一個很大的失誤。所以在這裡面我們引入了審核機制來保證上線的可靠性。在實現上，我們將數據切分成三大塊：後臺數據、流程數據和線上數據。在數據層面做隔離，在流程上做把控，保證了上線的穩定性。
第三點是提前預覽，也稱之為測試預覽。產品有這樣的訴求，希望配置在發佈上線之前看到實際上線後的效果。那如何實現呢？其實很簡單，我們每個設備它都有一個唯一的標識，我們稱之為設備 ID。APP 發起數據請求，數據進入到業務接入層，再調運營配置服務拿到數據。在這個調用的過程中我們會判斷一下這個設備是不是測試用戶的設備，那如何判斷它是否為測試用戶設備？產品在上線路過程中如果想測試的話，必須把自己設備的 ID 加入到測試用戶集裡面去。這裡我們提供一個掃描二維碼的功能，把自己的設備 ID 直接加入到測試用戶集裡。流程如下所示：
3
在快速迭代過程中，如何保證運營配置平臺的靈活性？
越複雜的需求我們需要做越簡單的設計，我們怎麼做的呢？其實很簡單，數據存儲我們採用 JSON 格式，保證能應對需求的靈活變化。我們知道 JSON 有一個很大的特點就是靈活，K/V 可以隨時增刪。但是這裡面還有一點，但光存儲還不夠，因為 JSON 的 K/V 結構。這裡 K/V 如何定？必然需要有一個字段管理的流程。如下圖，從右邊運營人員看到的運營界面是一個動態化的界面。這個動態化界面由兩部分組成，第一部分是數據，第二部分是控制這個頁面展示的一個字段。通過這兩點，最終生成一個動態化的渲染頁面（運營人員實際操作的界面）。C 端用戶通過不同的業務接入層，業務接入層再通過 SDK 獲取我們的配置數據，最後在 C 端顯示。
4
怎樣提供穩定可靠的配置數據服務？
經常有業務同學過來找我，問我們的系統能保證什麼樣的穩定性。我說我們的系統能保持這樣的穩定性：即使我們系統掛了，你也能拿到數據，這樣的話你是不是很放心？你肯定很放心。在穩定性方面，我們進行了三個階段的演進.
第一階段
最初的時候，我們採用的是經典的數據存儲方案：C 端用戶到業務接入層，到配置後臺數據服務，最後到數據庫。業務接入層去調配置後臺數據服務的時候是通過 RPC 方式進行調用的。配置後臺數據服務是怎麼取的？首先會從 Redis 裡取，當 Redis 緩存裡沒有數據，就去數據庫裡取，同時把數據庫裡的數據同步到 Redis 裡面去，最後把數據進行返回。這種架構它有什麼缺點？
我相信做過整體架構設計的同學有很多體會，任何架構都是為滿足業務需要的。可能很多同學說這種架構是很完美的，其實它是有很多的缺點的。首先配置後臺數據服務到數據庫，或者到 Redis 緩存是通過（內部）網絡的。這個雖然很快，但是它還是有網絡時延的，這是第一個缺點。第二個缺點，如果哪天 Redis 抖動，我們提供的服務也會出現同樣的抖動現象。因為我們提供的是一個很基礎的服務，所以說這種現象我們是不能接受的，那我們怎麼去優化？
第二階段
針對第一階段架構的問題，我們的架構演進到第二版。如下圖所示，和第一版的唯一區別就是我們在配置後臺數據服務裡面加了本地緩存。看這個架構圖，我們首先解決了配置後臺數據服務到數據庫這層之間的網絡時延。因為配置後臺數據服務它不再通過數據庫拿數據，它是通過本地緩存拿數據。本地緩存數據的更新是通過一個異步線程完成。這樣一種架構是不是完美的？我們解決了配置後臺數據服務到數據庫之間的時延。但是業務接入層與配置後臺數據服務之間，這個網絡時延還是存在。
還有一個很重要的點，業務接入層都往配置後臺請求數據。這時，配置後臺數據服務就成了一箇中心節點，這樣它的風險就很大了。另外，每臺機器內存是有大小限制的，這也是一個瓶頸點。怎麼解決這些問題呢？
第三階段
針對第二階段的三個問題：網絡時延、中心節點、有限緩存，我們演進到第三種方案，如下圖所示：
這是一個 SDK 的解決方案。之前我們的緩存是放在配置後臺數據服務中。SDK 方案裡我們把這個緩存移到業務接入層，並提供接入的 SDK。數據都是存儲在業務接入層，這樣有一個非常大的好處，所有的請求不會打到配置後臺數據服務，而是請求到業務層獲取到數據後就返回了。請求的鏈路變成：C 端用戶請求過來到業務接入層，業務接入層直接取自己本地緩存的配置數據，返回給 C 端用戶。這樣的話解決了一箇中心化的問題。
同樣的，存儲問題也解決了。之前我們數據都是存儲在配置後臺數據服務裡，即存儲在我們自己服務器緩存裡。全公司所有的數據緩存在中心服務機器裡遲早有一天內存會打滿。如果數據存在 SDK 裡面，它是在業務接入層，它把數據存儲的壓力分散化了，為什麼這樣說？舉一個例子：親子的服務不會用到外賣的數據，這樣在親子的服務器上就不需要緩存外賣的數據。這樣就解決了數據存儲層中心化的問題，下面的對比圖可以形象說明這一點。
5
總結
本文通過美團點評移動運營平臺的實踐，介紹了我們在打造穩定、靈活、高效的運營配置平臺過程中積累的一些方法論：通過數據 JSON 化，運營流程化，接口 SDK 化分別解決了運營平臺的靈活性、高效性和穩定性。運營平臺幫助產品、運營和研發提升 C 端的開發和運營效率，加速產品的迭代過程。
閱讀更多 e薦客 的文章
