基于 Apollo 的通用配置平臺設計
背景
網易嚴選主站側的很多業務配置，由于諸多歷史原因由開發維護在 Apollo 配置平臺中，如：
- 業務快速發展時期， 產品快速迭代的要求，導致研發資源和成熟的管理后臺落地之間常常做妥協；
- 部分業務配置的生命周期在最初認為較短，或低頻修改，未必值得落地到獨立配置界面；
- Apollo 的使用簡便，在這種場景下對開發過于友好；
- ……
進而日常需要手動處理業務側的配置訴求，現狀流程是業務側會發送郵件提供配置內容，研發將配置內容轉化為技術語言，在配置平臺進行發布。在大促高峰期，配置占用的工作量更為凸顯（單表單的配置，跨角色溝通、配置、發布、端側檢查平均耗時 15-20 分鐘，有些巨型表單估計花費近半天時間），本著不做重復簡單工作，釋放研發人力+提升運營效率的思路，一個 OKR 項目：樂高（MINOS）配置平臺誕生了。
一句話總結，樂高（MINOS）的初衷是為了快速解決網易嚴選 C 端大促頻繁配置 + 大量已有業務配置沉淀在 Apollo 的現狀下，引發的對研發資源占用問題，希望能夠把技術語言的配置轉化為業務語言，同時將配置的角色擴散到產品、業務方等。
因此，樂高（MINOS）配置平臺的核心定位也清晰了：
- 面向對象：研發生成表單、產品/業務配置表單。
- 價值：基于現狀快速搭建可視化業務表單、提升效率。
基于以上的核心定位和對現有流程的思考，我們拆解了三個設計過程中要考慮的具體問題：
- 本著修改最小化原則，如何基于現狀的數據模型把技術語言轉化為業務語言，直接透出給業務方進行配置；
- 如何將原本線下的配置流程線上化，將原本的研發內部操作細節屏蔽，全新設計面向全鏈路角色的通用線上審批流；
- 平臺能力如果要真正落地長期受益，需要從業務體驗、產品體驗、整體易用性上認真審視。
技術語言轉化為業務語言
配置平臺的根本核心 = UI 配置展示 + 底層數據存儲。最終數據的發布前面提到，現狀下仍然基于 Apollo。現有的 Apollo 配置的數據結構比較靈活，支持 String、Map、List 等多種數據類型，映射到業務層面的語義覆蓋較廣，如鏈接字符串、SKU 列表、活動生效時間戳、氛圍顏色配置、展示復雜列表 等。因此需要構建一個系統，適配現有的高靈活度的數據結構，配置出可視化的表單結構。
UI 配置
在 lowcode 盛行的當今，這種方案遍地開花，不需要自己重復造輪子。經過調研，我們選擇采用阿里系的 X-Render 來解決。X-Render 提供了豐富的基礎類型的組件，基于組件的拖拽組合能夠輸出不同類型的 JSON Schema，并且提供了能力自定義實現組件。
配置平臺的組件提供上，有兩種思路：
- X-Render 默認提供的是功能性組件（如輸入框、下拉列表等），通過默認功能性組件 + 自定義功能性組件 + 表單字段描述性說明，來生成業務表單；
- 提供業務組件（如SKU 選擇器、商品池選擇器等）；
基于樂高（MINOS）配置平臺的初衷是為了快速解決現存問題（先有技術負債，再有平臺設計的被動現狀），我們選擇現階段使用方案 1來解決，提供最大的配置靈活空間，當然也對應了會有一定的學習成本，不過現階段表單的搭建工作都是技術同學完成，認為可以接受。
以上為導購業務的表單示例，導購業務域的研發可以通過簡單的搭建，快速創建出適合產品/業務介入配置的表單。
底層數據存儲
雖然最終數據是基于 Apollo 來做分發，但配置平臺的設計中，必然會需要有數據的暫存，涉及到表單狀態機的流轉，并且前面也提到會涉及到表單的審批流（對應有狀態機流轉）。
在 Apollo 的設計中，有幾個核心概念：
- application （應用）：在 apollo 的設計中，一個應用就是一個唯一標識。
- namespace（命名空間）：namespace是配置項的集合，類似于一個配置文件的概念；namespace 可以實現公共組件的配置；
- Item（配置項）：每個 item 是一個 KV 組合；
以 yanxuan-app 為例，主工程（源代碼工程）和 Apollo 配置中心的依賴關系如圖所示：
由于歷史原因，相同場景業務屬性的配置有可能分布在不同的 Apollo AppId 以及不同的 namespace 內，為了保持表單配置的靈活性，我們將表單的數據最小關聯粒度確定為 Item（配置項） 粒度，這就意味著，一個完整的業務表單，可能會關聯到多個 Apollo AppId，多個 Namespace，多個 Item 的數據。
如上圖所示，前面搭建出來的表單子元素（底層即 JSON Schema Root），可以分別設置映射到 Apollo Item Key 維度。
這里需要注意的是，如果 Apollo 原始系統還在修改，同時在樂高（MINOS）配置平臺也有修改且還在審批過程中（下文會提到），可能會發生最終的配置不符合預期，所以我們會建議存放業務配置的 AppId/NameSpace 收回研發發布權限（硬限制）或研發團隊內部形成約定（軟限制）。
審批流設計
原本配置修改的流程如下：
運營有訴求->郵件給研發->研發 A 翻譯為 Apollo 配置->研發 B 發布配置（Apollo 的發布人和修改人不能為同一人）->多方檢查配置效果
由于配置的角色需要向業務 or 產品轉移，所以新設計的審批流里，我們引入業務填寫+審核機制，最終由研發來做終審。終審完畢后，調用 Apollo 的 openapi 實現對應配置的發布。審批流整體接入嚴選流程平臺，利用現有的能力，減少重復造輪子+保持統一的工單審批提醒體驗。
表單狀態機
插曲：之所以引入研發做終審，有兩個原因：
- 盡量保持了原本 Apollo 的研發檢查機制，在平臺未完全成熟前，算是多一重保障；
- 研發終審后，如果由于namespace 鎖等緣故導致發布失敗，需要研發介入重新發布；
縮小能用->易用的 GAP
在平臺基本能力走通后，只是里程碑的一小步，如果平臺要實際能夠落地，讓受眾愿意使用，需要理性上耐下心來，因為還有很長的路要走。
在平臺的落地階段，我們分三個方向并行推進：
- 和用戶在一起，提供示例和教學，傾聽用戶反饋
完善了更多自定義組件
優化了用戶難以理解的流程和交互
- 細節優化，從不成熟->成熟，逐步給用戶帶來驚喜
組件的細節交互優化
自動恢復草稿
批量綁定數據源
全面推廣，挖掘更多業務場景，讓平臺能力價值最大化
在網易嚴選不同業務團隊內逐步由點及面推廣
在從 0-1 的 i 茅臺項目中實現技術的自我救贖，全面使用，賦能運營
面向未來
目前樂高（MINOS）配置平臺正式上線1個月+后，在多條業務線中已經配置表單 1000+ 次，減少了原本研發介入配置的時長，另外也快速支撐了新業務（i 茅臺）的配置構建。
現階段的樂高（MINOS）配置平臺， 只是為了解決技術歷史債務而生的一個產物，放眼未來，配置的存儲應當回歸理性：
- 業務向的配置和技術向的配置不應該混為一談，Apollo 的定位還是建議存儲系統參數相關的配置；
- 即使使用 Apollo 來承載業務配置，那么 apollo 的 app 和 namespace 應當完全隔離，且回收 apollo 原有的操作權限，收口到統一配置平臺來管理；
- 資源充分條件允許的情況下，我們肯定建議把業務配置下沉到各業務的管理后臺；
如果在樂高發展成熟的情況下，展望進一步發展：
- 拓展更多數據源，讓存儲選型趨于合理+多樣化；
- 前臺頁面可以使用微前端技術嵌入各個業務系統，保持業務系統管理后臺的閉環；
- 提供成熟的業務組件，降低搭建成本；
一切平臺的構建，都基于當前業務的痛點、現狀，衡量整體 ROI，才能發揮最大的價值，讓我們拭目以待~
