背景

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

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

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

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

因此，樂(lè)高（MINOS）配置平臺(tái)的核心定位也清晰了：

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

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

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

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

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

UI 配置

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

配置平臺(tái)的組件提供上，有兩種思路：

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

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

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

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

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

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

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

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

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

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

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

審批流設(shè)計(jì)

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

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

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

表單狀態(tài)機(jī)

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

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

縮小能用->易用的 GAP

在平臺(tái)基本能力走通后，只是里程碑的一小步，如果平臺(tái)要實(shí)際能夠落地，讓受眾愿意使用，需要理性上耐下心來(lái)，因?yàn)檫€有很長(zhǎng)的路要走。

在平臺(tái)的落地階段，我們分三個(gè)方向并行推進(jìn)：

1. 和用戶(hù)在一起，提供示例和教學(xué)，傾聽(tīng)用戶(hù)反饋

完善了更多自定義組件

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

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

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

自動(dòng)恢復(fù)草稿

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

全面推廣，挖掘更多業(yè)務(wù)場(chǎng)景，讓平臺(tái)能力價(jià)值最大化

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

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

面向未來(lái)

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

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

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

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

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

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