背景

網(wǎng)易嚴選主站側(cè)的很多業(yè)務(wù)配置，由于諸多歷史原因由開發(fā)維護在 Apollo 配置平臺中，如：

• 業(yè)務(wù)快速發(fā)展時期， 產(chǎn)品快速迭代的要求，導致研發(fā)資源和成熟的管理后臺落地之間常常做妥協(xié)；
• 部分業(yè)務(wù)配置的生命周期在最初認為較短，或低頻修改，未必值得落地到獨立配置界面；
• Apollo 的使用簡便，在這種場景下對開發(fā)過于友好；
• ……

進而日常需要手動處理業(yè)務(wù)側(cè)的配置訴求，現(xiàn)狀流程是業(yè)務(wù)側(cè)會發(fā)送郵件提供配置內(nèi)容，研發(fā)將配置內(nèi)容轉(zhuǎn)化為技術(shù)語言，在配置平臺進行發(fā)布。在大促高峰期，配置占用的工作量更為凸顯（單表單的配置，跨角色溝通、配置、發(fā)布、端側(cè)檢查平均耗時 15-20 分鐘，有些巨型表單估計花費近半天時間），本著不做重復(fù)簡單工作，釋放研發(fā)人力+提升運營效率的思路，一個 OKR 項目：樂高（MINOS）配置平臺誕生了。

一句話總結(jié)，樂高（MINOS）的初衷是為了快速解決網(wǎng)易嚴選 C 端大促頻繁配置 + 大量已有業(yè)務(wù)配置沉淀在 Apollo 的現(xiàn)狀下，引發(fā)的對研發(fā)資源占用問題，希望能夠把技術(shù)語言的配置轉(zhuǎn)化為業(yè)務(wù)語言，同時將配置的角色擴散到產(chǎn)品、業(yè)務(wù)方等。

因此，樂高（MINOS）配置平臺的核心定位也清晰了：

• 面向?qū)ο螅貉邪l(fā)生成表單、產(chǎn)品/業(yè)務(wù)配置表單。
• 價值：基于現(xiàn)狀快速搭建可視化業(yè)務(wù)表單、提升效率。

基于以上的核心定位和對現(xiàn)有流程的思考，我們拆解了三個設(shè)計過程中要考慮的具體問題：

• 本著修改最小化原則，如何基于現(xiàn)狀的數(shù)據(jù)模型把技術(shù)語言轉(zhuǎn)化為業(yè)務(wù)語言，直接透出給業(yè)務(wù)方進行配置；
• 如何將原本線下的配置流程線上化，將原本的研發(fā)內(nèi)部操作細節(jié)屏蔽，全新設(shè)計面向全鏈路角色的通用線上審批流；
• 平臺能力如果要真正落地長期受益，需要從業(yè)務(wù)體驗、產(chǎn)品體驗、整體易用性上認真審視。

技術(shù)語言轉(zhuǎn)化為業(yè)務(wù)語言

配置平臺的根本核心 = UI 配置展示 + 底層數(shù)據(jù)存儲。最終數(shù)據(jù)的發(fā)布前面提到，現(xiàn)狀下仍然基于 Apollo?，F(xiàn)有的 Apollo 配置的數(shù)據(jù)結(jié)構(gòu)比較靈活，支持 String、Map、List 等多種數(shù)據(jù)類型，映射到業(yè)務(wù)層面的語義覆蓋較廣，如鏈接字符串、SKU 列表、活動生效時間戳、氛圍顏色配置、展示復(fù)雜列表 等。因此需要構(gòu)建一個系統(tǒng)，適配現(xiàn)有的高靈活度的數(shù)據(jù)結(jié)構(gòu)，配置出可視化的表單結(jié)構(gòu)。

UI 配置

在 lowcode 盛行的當今，這種方案遍地開花，不需要自己重復(fù)造輪子。經(jīng)過調(diào)研，我們選擇采用阿里系的 X-Render 來解決。X-Render 提供了豐富的基礎(chǔ)類型的組件，基于組件的拖拽組合能夠輸出不同類型的 JSON Schema，并且提供了能力自定義實現(xiàn)組件。

配置平臺的組件提供上，有兩種思路：

1. X-Render 默認提供的是功能性組件（如輸入框、下拉列表等），通過默認功能性組件 + 自定義功能性組件 + 表單字段描述性說明，來生成業(yè)務(wù)表單；
2. 提供業(yè)務(wù)組件（如SKU 選擇器、商品池選擇器等）；

基于樂高（MINOS）配置平臺的初衷是為了快速解決現(xiàn)存問題（先有技術(shù)負債，再有平臺設(shè)計的被動現(xiàn)狀），我們選擇現(xiàn)階段使用方案 1來解決，提供最大的配置靈活空間，當然也對應(yīng)了會有一定的學習成本，不過現(xiàn)階段表單的搭建工作都是技術(shù)同學完成，認為可以接受。

以上為導購業(yè)務(wù)的表單示例，導購業(yè)務(wù)域的研發(fā)可以通過簡單的搭建，快速創(chuàng)建出適合產(chǎn)品/業(yè)務(wù)介入配置的表單。

底層數(shù)據(jù)存儲

雖然最終數(shù)據(jù)是基于 Apollo 來做分發(fā)，但配置平臺的設(shè)計中，必然會需要有數(shù)據(jù)的暫存，涉及到表單狀態(tài)機的流轉(zhuǎn)，并且前面也提到會涉及到表單的審批流（對應(yīng)有狀態(tài)機流轉(zhuǎn)）。

在 Apollo 的設(shè)計中，有幾個核心概念：

• application （應(yīng)用）：在 apollo 的設(shè)計中，一個應(yīng)用就是一個唯一標識。
• namespace（命名空間）：namespace是配置項的集合，類似于一個配置文件的概念；namespace 可以實現(xiàn)公共組件的配置；
• Item（配置項）：每個 item 是一個 KV 組合；

以 yanxuan-app 為例，主工程（源代碼工程）和 Apollo 配置中心的依賴關(guān)系如圖所示：

由于歷史原因，相同場景業(yè)務(wù)屬性的配置有可能分布在不同的 Apollo AppId 以及不同的 namespace 內(nèi)，為了保持表單配置的靈活性，我們將表單的數(shù)據(jù)最小關(guān)聯(lián)粒度確定為 Item（配置項） 粒度，這就意味著，一個完整的業(yè)務(wù)表單，可能會關(guān)聯(lián)到多個 Apollo AppId，多個 Namespace，多個 Item 的數(shù)據(jù)。

如上圖所示，前面搭建出來的表單子元素（底層即 JSON Schema Root），可以分別設(shè)置映射到 Apollo Item Key 維度。

這里需要注意的是，如果 Apollo 原始系統(tǒng)還在修改，同時在樂高（MINOS）配置平臺也有修改且還在審批過程中（下文會提到），可能會發(fā)生最終的配置不符合預(yù)期，所以我們會建議存放業(yè)務(wù)配置的 AppId/NameSpace 收回研發(fā)發(fā)布權(quán)限（硬限制）或研發(fā)團隊內(nèi)部形成約定（軟限制）。

審批流設(shè)計

原本配置修改的流程如下：

運營有訴求->郵件給研發(fā)->研發(fā) A 翻譯為 Apollo 配置->研發(fā) B 發(fā)布配置（Apollo 的發(fā)布人和修改人不能為同一人）->多方檢查配置效果

由于配置的角色需要向業(yè)務(wù) or 產(chǎn)品轉(zhuǎn)移，所以新設(shè)計的審批流里，我們引入業(yè)務(wù)填寫+審核機制，最終由研發(fā)來做終審。終審?fù)戤吅螅{(diào)用 Apollo 的 openapi 實現(xiàn)對應(yīng)配置的發(fā)布。審批流整體接入嚴選流程平臺，利用現(xiàn)有的能力，減少重復(fù)造輪子+保持統(tǒng)一的工單審批提醒體驗。

表單狀態(tài)機

插曲：之所以引入研發(fā)做終審，有兩個原因：

1. 盡量保持了原本 Apollo 的研發(fā)檢查機制，在平臺未完全成熟前，算是多一重保障；
2. 研發(fā)終審后，如果由于namespace 鎖等緣故導致發(fā)布失敗，需要研發(fā)介入重新發(fā)布；

縮小能用->易用的 GAP

在平臺基本能力走通后，只是里程碑的一小步，如果平臺要實際能夠落地，讓受眾愿意使用，需要理性上耐下心來，因為還有很長的路要走。

在平臺的落地階段，我們分三個方向并行推進：

1. 和用戶在一起，提供示例和教學，傾聽用戶反饋

完善了更多自定義組件

優(yōu)化了用戶難以理解的流程和交互

2. 細節(jié)優(yōu)化，從不成熟->成熟，逐步給用戶帶來驚喜

組件的細節(jié)交互優(yōu)化

自動恢復(fù)草稿

批量綁定數(shù)據(jù)源

全面推廣，挖掘更多業(yè)務(wù)場景，讓平臺能力價值最大化

在網(wǎng)易嚴選不同業(yè)務(wù)團隊內(nèi)逐步由點及面推廣

在從 0-1 的 i 茅臺項目中實現(xiàn)技術(shù)的自我救贖，全面使用，賦能運營

面向未來

目前樂高（MINOS）配置平臺正式上線1個月+后，在多條業(yè)務(wù)線中已經(jīng)配置表單 1000+ 次，減少了原本研發(fā)介入配置的時長，另外也快速支撐了新業(yè)務(wù)（i 茅臺）的配置構(gòu)建。

現(xiàn)階段的樂高（MINOS）配置平臺， 只是為了解決技術(shù)歷史債務(wù)而生的一個產(chǎn)物，放眼未來，配置的存儲應(yīng)當回歸理性：

1. 業(yè)務(wù)向的配置和技術(shù)向的配置不應(yīng)該混為一談，Apollo 的定位還是建議存儲系統(tǒng)參數(shù)相關(guān)的配置；
2. 即使使用 Apollo 來承載業(yè)務(wù)配置，那么 apollo 的 app 和 namespace 應(yīng)當完全隔離，且回收 apollo 原有的操作權(quán)限，收口到統(tǒng)一配置平臺來管理；
3. 資源充分條件允許的情況下，我們肯定建議把業(yè)務(wù)配置下沉到各業(yè)務(wù)的管理后臺；

如果在樂高發(fā)展成熟的情況下，展望進一步發(fā)展：

1. 拓展更多數(shù)據(jù)源，讓存儲選型趨于合理+多樣化；
2. 前臺頁面可以使用微前端技術(shù)嵌入各個業(yè)務(wù)系統(tǒng)，保持業(yè)務(wù)系統(tǒng)管理后臺的閉環(huán)；
3. 提供成熟的業(yè)務(wù)組件，降低搭建成本；

一切平臺的構(gòu)建，都基于當前業(yè)務(wù)的痛點、現(xiàn)狀，衡量整體 ROI，才能發(fā)揮最大的價值，讓我們拭目以待~