背景
网易严选主站侧的很多业务配置，由于诸多历史原因由开发维护在 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，才能发挥最大的价值，让我们拭目以待~
