本文收录在微保技术公众号 – 微保统一配置平台的探索与实践

公司是不断在发展的,业务也是不停拓展的,在业务堆叠时相关的配置数量自然也是疯狂增长的,如果在这个时候没有对配置的整体规划,我们很快就会无法掌控这日益庞大的配置树。笔者将会在下文给大家介绍,我们团队在处理配置时遇到了些什么,又做了些什么,希望能够抛砖引玉,大家能够一同探讨。

背景

笔者入职微保两年以来,正是业务快速拓展的时期。为了尽快能上线各种似同非同的保险产品,我们设计了一个通用的保险产品框架,通过配置来完成绝大部分保险产品上架,前后尝试过不少配置方案,也踩过不少因配置不当而引起的坑。

产品管理系统(PMS)

为了能够方便的配置通用框架的产品详情页以及保险文档,我们开发了PMS系统。这个系统专门用来配置各保险产品的展示素材、管理保险产品相关的文档以及文案。

PMS是定制化的开发模式,前端页面需要什么配置,就在PMS上开发相应的表单。这种完全定制化的开发模式,虽然十分贴近业务,但是无形之中也增加了开发同学的工作量,每当产品详情页或者文档页有新的特性都需要耗费人力去开发表单,以及后续的自测上线,都需要占用开发同学的时间。从长远看来,这并不是一种良好的、可发展的配置开发模式。

JSON配置

在开发一些小型活动页面时,经常会为一些无处安放的零散配置项发愁,所以为了能够方便的配置小程序内的小型活动页面,我们采用过将JSON文件上传到CDN的方案。

如下图,是一个活动页面的外露icon控制,进入页面之后我们将会拉取相应的json配置,然后进行前端页面的渲染。

这种做法虽然开发时很省事,但是日后维护时可能就没那么开心了,既没有版本控制,也没有操作权限控制,且无法监控配置出错的情况,甚至可能会出现CDN缓存无法刷新的尴尬情况。

其他配置

除了上述的方案,我们还使用过中心内的其他系统进行配置,这样的后果就是配置零散分布在各个配置系统中,想完整的配置好一个新产品需要打开多个不同的配置系统才能完成,且这种零碎化的配置很容易造成配置漏发或错发。

尽管这些配置系统的界面都近乎一致,但是配置表单的交互却各不相同,我们很难用同一套操作交互来操作每一个系统,这也降低了配置的效率。

渐渐的,配置数量、配置系统都已经开始野蛮生长,整个系统随着时间的推移,会变得越来越混乱,就如物理学中的熵增一般,如果不及时的对系统进行干预,它必然会走失控甚至消亡。

蓦然回首

上面提及的配置方案基本可以归类为两种类型:开发友好型以及使用友好型

以PMS系统为首的各种配置系统,都是属于使用友好型的配置方案,它们都提供了配置界面甚至还提供了配置预览界面,但是对开发人员来说这就不太友好了,无论是业务的改动还是数据结构的变更,都需要投入本就稀缺的人力去开发。

以JSON配置为首的便捷配置方案,则是开发友好型的方案,它几乎没有任何开发成本,写一个JSON上传到CDN就可以使用了,可以将每个JSON都看作一个微型的配置系统。这样开发人员很轻松,但是配置方就有苦难言了,特别是不熟悉JSON的产品人员,每次改动JSON配置都如履薄冰,每改一个符号都得小心翼翼,因为稍不小心就真的会影响线上的业务。

这么看来,我们使用过的方案可以说是两个极端,我们是否可以取其中间呢,就如同我们常说的中庸,在配置上我们能否取二者之长走出一条中庸之道呢?这就是我们统一配置平台上线之前的历程。

统一配置平台V1.0

在1.0版本中,我们确定了平台的核心理念,也是平台的提供给用户最核心的能力 – 可视化的配置表单。

可视化的配置表单

如上图,如果我们提供一个文本框,在文本框里面输入JSON,这算是可视化的表单么?如果业务要求的是接受一个JSON串,这样也可以算可视化的表单。

但是在统一配置平台对配置的理解中,这还不是一个完善的可视化表单,我们认为JSON内的每个字段都是可以演化成表单组件的,如下图。

例如:一个字符串类型的数据,我们可以通过一个普通的输入框进行输入,一个图片链接,我们可以提供图片上传组件,直接上传并返回字符串链接。我们认为这样的才是符合统一配置平台理念的可视化配置表单。

如何实现表单的可视化?

与传统配置系统的表单组件拖动组成表单不同,我们的表单组件是通过一个proto文件解析而来的。大家可能会有这么一个疑问,为什么是proto呢?

我们可以先从一个情景切入,相信大家看完之后,也会对我们的选择有所理解。假如,有一个前端页面需要这么一个配置:根据请求的来源(H5 or 小程序)展示不同的保司介绍以及品牌露出。我们会怎么去规划这个配置以及配置的界面呢?

规划配置,不外乎这两个方向:数据类型、配置界面。

数据类型,根据业务需求我们大概可以确立以下数据结构:

既然我们已经可以规划出所需的字段了,那么是不是通过一种规范的方式使其成为一种数据结构协议呢?当然可以,我们为每个字段都添加了一个描述类型的字段。

数据类型的描述已经基本完成了,我们能否在其中将配置的界面也描述出来呢?

当然也是可以的,例如companyCode字段,它应该是字符串,那么我们可以为其分配一个输入框组件;而introImgURL字段,虽然最终需要的是字符串,但它应该是一个图片链接,我们自然可以为其分配一个图片上传组件。这么一来,也就得出了下面的配置描述。

至此,已经完成了一个完整的配置描述,并且我们一开始也是这么实现的,但是我们始终觉得这样的配置太过繁琐,并且不够直观。如果让开发同学直接这么定义表单,也并没有想象中的那么方便。

于是我们着手对其进行优化,如果能在一行内完成字段类型、字段名的配置,可以让整个配置直观、简洁不少。顺着这个优化的思路,我们想到了使用proto。

proto作为一个高效、通用的网络通信和数据交换协议,在数据结构的描述上有天然的优势,并且公司内部接入的后端服务可以直接使用定义好的proto进行开发,前端开发人员也可以通过proto提前确定数据结构,进行数据mock。这些优势,促使着我们探索放弃json拥抱proto的可能性。

如上述proto代码,之前通过json描述的数据类型已经可以完美的在proto中复刻,并且更加简洁易懂,但是表单界面的描述该怎么办呢?

这里我们想到的是YAML与proto注释的结合。通过YAML的描述,我们可以为每个字段解析出一套属于它的表单界面(组件)以及表单特性(是否必填、是否有默认值等)。最终实现下图的表单生成流:

开发到这一阶段,我们已经可以做到不进行任何逻辑开发,仅靠一份proto配置就生成一套完整的配置表单。

这也就是我们上面提及的,在开发友好和使用友好中,我们期望各取二者所长:开发人员可以尽量少的关注配置的界面开发,专注配置本身的结构规划;而使用人员则可以通过交互良好的表单组件来修改配置内容,不需要付出额外的学习成本。

但是,这又引申出另一个问题:这种开发模式所输出的表单,岂不是只有开发同学才能进行配置项的修改了吗?

是的,我们认为一个健壮的配置确实是需要开发同学进行编辑。一般,我们在需求开发前就会对整个数据结构有个相对完善的预设,例如需要什么类型的字段、需要怎样的数据结构甚至是否需要这个字段,这些都应该是开发同学比较擅长的。

以上,是统一配置平台第一版的概况,核心已经明确并且也初步实现出来了,随着大家对初版平台的使用深入,我们收集了不少反馈,并以此为契机我们将平台进程推到了第二阶段,通过对搜集来的反馈进行细致分析,并且结合对平台的后续展望,我们认为需要对系统的设计进行重构。为了让系统能够更灵活的面对各种配置需求,我们还需要赋予其应用以及菜单的理念。

统一配置平台V2.0

在本阶段增加了应用层以及菜单集合的功能,并且确立了整个平台的架构。

新版平台架构

系统核心

这里的核心指的是统一配置平台的核心服务,这部分服务是与应用、功能隔离的,它主要的功能是生成应用、挂载应用,以及应用最初的管理员分配。在系统中的其他操作都与核心无关,都属于应用内的操作。

应用层

应用层又名APP层,对于后端服务来说,这是功能层的集合,也就是配置表单的集合,多个业务相关或互相依赖的配置表单将会形成一个应用。

相较于系统核心,应用层需要管理的事情就更多一点。配置的权限分配、菜单管理、角色管理以及一些拓展功能的管理都需要应用层亲力亲为。

功能层

功能层其实就是通过proto文件生成的配置表单,我们认为通过每份配置表单配出来的数据都是可以完成一种功能的,所以将这一层命名为功能层。它掌控着配置表单组件的渲染模板以及数据文档的版本存取。

因为加入了应用的概念,等于在系统核心与配置表单中间加多了一层抽象,正因为应用层的接入,我们将很多原本收束在核心内的权限及功能分发出去。

核心与应用间的分权自治

在我们的设计理念中,系统核心与各个应用间是一种分权自治的关系。

系统核心在生成应用的时候,会做许多初始化的工作来帮助应用实现自治。

当我们输入新应用的信息后,核心会根据所输入的信息建立相应的Git仓库(用于存储proto文件),并为Git仓库挂上Push钩子(用于接收并解析proto)。

然后生成与应用相关的库并内置必备的表,最后在记录应用的表中插入新应用的信息以完成新应用的挂载。

从上述应用生成的流程可以看出,与传统的配置系统不太一样,我们系统核心十分的“佛系”,它只负责应用的初始化,后续并不会干涉应用内部的运作,在生成应用的时候就会将权力下放给各个应用,每个应用都是可以自治的。

2.0版本开发完成后,我们将整个平台面向各个业务开发团队开放。

尾声

回望一下,统一配置平台从一开始的项目构思、项目孵化再到现在的开放使用,已经有接近一年的时间了。

在这一年的时间里,我们创建了13个应用,在每个应用中维护着大家创建的表单配置,一共维护了大约105个表单配置。在这上百个配置表单下,关联着大约11000条数据。已接入的配置中,日均请求量大概有835万次。

在项目的开发实践中,我们尝试了各种配置储存以及归类的方案、也怀疑过自己的设计理念、质疑过自己的项目初衷,但通过不断的实践我们认为这是适合微保的最佳实践,项目的不断完善和口碑也验证了这一点。