基于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，并且提供了能力自定义实现组件。

配置平台的组件提供上，有两种思路：

1. X-Render 默认提供的是功能性组件（如输入框、下拉列表等），通过默认功能性组件 + 自定义功能性组件 + 表单字段描述性说明，来生成业务表单；
2. 提供业务组件（如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 实现对应配置的发布。审批流整体接入严选流程平台，利用现有的能力，减少重复造轮子+保持统一的工单审批提醒体验。

表单状态机

插曲：之所以引入研发做终审，有两个原因：

1. 尽量保持了原本 Apollo 的研发检查机制，在平台未完全成熟前，算是多一重保障；
2. 研发终审后，如果由于namespace 锁等缘故导致发布失败，需要研发介入重新发布；

缩小能用->易用的 GAP

在平台基本能力走通后，只是里程碑的一小步，如果平台要实际能够落地，让受众愿意使用，需要理性上耐下心来，因为还有很长的路要走。

在平台的落地阶段，我们分三个方向并行推进：

1. 和用户在一起，提供示例和教学，倾听用户反馈

完善了更多自定义组件

优化了用户难以理解的流程和交互

1. 细节优化，从不成熟->成熟，逐步给用户带来惊喜

组件的细节交互优化

自动恢复草稿

批量绑定数据源

全面推广，挖掘更多业务场景，让平台能力价值最大化

在网易严选不同业务团队内逐步由点及面推广

在从 0-1 的 i 茅台项目中实现技术的自我救赎，全面使用，赋能运营

面向未来

目前乐高（MINOS）配置平台正式上线1个月+后，在多条业务线中已经配置表单 1000+ 次，减少了原本研发介入配置的时长，另外也快速支撑了新业务（i 茅台）的配置构建。

现阶段的乐高（MINOS）配置平台， 只是为了解决技术历史债务而生的一个产物，放眼未来，配置的存储应当回归理性：

1. 业务向的配置和技术向的配置不应该混为一谈，Apollo 的定位还是建议存储系统参数相关的配置；
2. 即使使用 Apollo 来承载业务配置，那么 apollo 的 app 和 namespace 应当完全隔离，且回收 apollo 原有的操作权限，收口到统一配置平台来管理；
3. 资源充分条件允许的情况下，我们肯定建议把业务配置下沉到各业务的管理后台；

如果在乐高发展成熟的情况下，展望进一步发展：

1. 拓展更多数据源，让存储选型趋于合理+多样化；
2. 前台页面可以使用微前端技术嵌入各个业务系统，保持业务系统管理后台的闭环；
3. 提供成熟的业务组件，降低搭建成本；

一切平台的构建，都基于当前业务的痛点、现状，衡量整体 ROI，才能发挥最大的价值，让我们拭目以待~

新闻标题：基于Apollo的通用配置平台设计
网站地址：http://www.csdahua.cn/qtweb/news0/293300.html

网站建设、网络推广公司-快上网，是专注品牌与效果的网站制作，网络营销seo公司；服务项目有等

广告

声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源： 快上网