基于腾讯蓝鲸智云SaaS的业务配置同步管理平台设计与实现

本文来自腾讯蓝鲸智云社区用户：donkey

业务背景

该平台设计的初衷，本是源于另外一个环境治理项目的一部分，主要是负责跨环境的业务配置修改与同步，同时考虑到这块能力除了在该项目中可以应用到外，也可以独立作为一个单点能力提供给其他用户使用，故考虑设计为一个saas应用模式，既支持用户在管理端界面进行操作，也支持通过管理api与第其他第三方效能工具进行集成。

技术选型

项目主导

该项目主要针对测试域的环境治理，由测试团队主导，而团队已有的测试工具均以python为主，考虑到后期协同，故平台建设也以python为准。

功能需求

配置修改

• Tars：鹅厂开源的微服务框架，自带配置管理功能，支持主流异构服务配置管理，是目前内部主站业务配置管理主要维护方式。
• Appolo：携程开源的配置管理中心，后期新引入，主要是针对Java类应用。

以上不管哪个方式，都需要用户在管理端界面去手动进行修改，而想要实现的配置同步功能，是希望能达到业务配置的自动获取、修改与同步，所以没有现成能力可以直接使用，但可以在已有能力基础上做进一步封装，故此处主要通过Tars框架的管理api对业务配置修改做二次处理。

配置同步

此处同步主要有以下两方面含义：

• 首先，是将源端环境指定配置文件的内容，实时修改后应用到目标端环境指定配置文件中（一般都是针对环境不同但对应业务服务相同的配置），并且能被业务应用正确解析和读取；
• 其次，同步范围既可以具体到单个服务或单个配置，也可以针对环境级别下涵盖的服务配置，并且能对同步结果进行实时检验。

同样，此处配置同步功能也是基于Tars框架管理api实现。

内部基建

此处主要表示该平台功能的实现，所依赖的内部已有基础设施能力：

• Gitlab：平台项目使用代码托管平台。
• Tars：通过Tars管理api进行Tars业务配置的实时修改与同步。
• 蓝鲸Saas：测试环境资源是基于蓝鲸进行管理，故可以利用蓝鲸Saas的扩展能力，既能省略额外的环境资源开销，也能方便调用其他蓝鲸内置的功能如监控、日志分析等。
• 蓝盾：蓝鲸devops流水线平台，可以通过和蓝盾进行集成（通过蓝盾流水线插件扩展能力），与环境治理项目其他模块实现更有效地配合，同时也可以进一步拓展配置同步平台的应用场景。
• Tapd：项目管理工具，源自鹅厂，主要用来对项目整体进度进行记录和把控。

技术框架

即蓝鲸Saas研发框架为主：

• web框架：Django2
• 后端：Python3
• 前端：Vue2
• UI组件库：MagicBox
• 数据库：MySQL5.7

方案实现

需求分析与设计

架构设计

确定基本技术栈之后，就是基础架构的设计，因为一开始对业务线整体状况都不是很熟悉，包括技术背景和业务背景，经过不断深入了解和团队沟通之后，才逐渐迭代出来自觉更加符合企业规范的样子，图示的架构设计已经是后期进一步优化的结果，即通过抽象出规则、策略组、任务等管理模块，对整个配置同步过程进行自动化管控。

流程设计

有了基本的架构设计相当于有了个骨架，但很多细节还是很模糊的，首先，就是具体用户应该怎么去使用，才能达到配置修改和同步的目的，所以就要先把基础的业务流程确定出来，而不是想一步做一步。
按照已有的架构设计，以下是各管理模块基本的业务流程：

规则管理

策略组管理

任务管理

原型设计

这里主要指UI原型设计，就是根据已经确定的业务流，设计用户交互的前端，说实话比起业务系统有分工明确的部门协作在搞，这个项目实际就我一人专职在弄，当时研究去画这个原型也是花了我不少时间，无奈老板有要求，然后后期实际效果出来其实又有不少变动，这里就简单展示下，后面会有实际效果展示。

【贴士】一开始画原型用的Axure，很多PMO应该不陌生，后面发现draw.io也不错，上手也简单，很多图就转到draw.io上来了。

后端设计

完成业务流设计后，接下来就是数据流设计，有了前面的铺垫，其实数据流这块就轻松一些，当然这块的设计和DB设计也是息息相关的。（如下为后端设计概要展示）

DB设计

对于有经验的后端开发，一般看库表设计，对于后端功能很多就知道个大概了，但是当有多个模块的功能都要设计库表时，怎样才能更合理，更符合数据库设计范式，只能靠自己在不断折腾中去感悟了。（如下为DB设计概要展示）

编码实现

贴士1：当前面的设计准备比较充分之后，编码阶段就会相对比较轻松，但有事先设计不代表就可以一蹴而就，实现过程也会不断发现一些设计过程重没有考虑到的因素，这就需要不断将发现的设计问题，通过一定的管理方式（比如项目管理工具，此处使用的是Tapd）进行记录和跟踪，当然也包括过程中的需求变更和缺陷追踪等。

贴士2：开发过程中，后端和前端实际都是独立分开的项目，当有一定阶段成果后再合并部署验证，生产业务一般都是并行开发，但比如像我只有一人独立负责的时候，优先实现前端，一个是前端产出用户感知更明显，一个也是更容易发现交互流程设计的缺陷，确定交互流程没问题之后，再对应实现后端功能。

前端

具体实现到这里就没有什么了，就是按照前面确定的业务流程和UI原型按部就班搞即可，就是过程中有些个人经验感觉可以分享一下：

• 蓝鲸saas研发框架会通过bk_site_url这个全局变量区分本地开发环境和线上环境，故可以在前端项目配置main.js中将baseURL设置成自动判断，而不是每次合并部署前再手动修改，避免忘记修改合并部署后前端访问失败。

  

• 由于Vue实例化的特性，实际不同URL访问的html文档可能都是同一个，这对用户常规认为的不同URL代表不同访问页面的习惯是冲突的，所以此处使用vue-router插件作为路由控制，同时也能反过来通过路由变化来触发页面组件的变化；
  使用：在项目配置main.js中引入，然后在route目录下针对具体页面做指定。

  

• 使用Vuex进行状态管理，基于vue组件根据数据变化而变化的特性，当项目庞大复杂起来之后，各种父子组件、兄弟组件、跨模块嵌套组件一层层传值有时真会让人崩溃，当把数据统一用Vuex进行纳管后，项目组件状态管理至少不再是原来那种乱糟糟的状态，让人感觉有条理很多，同时这也是vue官方推荐的组件状态管理解决方案。

  

  

后端

注意：在设计一些功能模块，特别是需要做类似持久化操作的时候，要注意防重复操作，举个例子，像调用Tars管理api进行配置写入的功能，本地开发的时候调用写入是正常的，部署到蓝鲸上就发现，同个配置记录会重复写入三次，原因在于本地部署是一个服务实例，但蓝鲸线上是默认3个服务实例（提升服务可用性），做成自动化调度的时候就会出现重复执行的问题，此处主要是通过添加文件锁的方式解决。

部署

注意：着手开发之前，要先将初始化的研发框架先部署一版到蓝鲸环境上，验证没问题之后再继续后续的开发，不然的话，先开发一部分再部署到蓝鲸环境上，然后发现访问出问题，日志报错又不明显的时候，都不知道是配置问题，代码问题，还是组件兼容问题，比如 Saas部署到蓝鲸后界面显示空白异常处理。

功能验收

一期效果

规则管理

计划管理

二期效果

规则管理

策略管理

任务管理

个人总结

• 即便是独立负责项目，也要讲究章法，比如通过使用项目管理工具帮自己进行项目进度的把控，不至于淹没在各种项目琐事细节中；
• 可以充分设计，但不要过度实现，特别是在项目前期对于产品并没有很明确规划的时候，先demo，再迭代，小步快跑；
• 一开始就要站在后期推广角度思考项目所能带来的业务价值，否则效能类实践一旦落地效果不好，自己又没有考虑长远，很容易就被毙掉，特别像现在整体不景气的职场环境背景下；
• 没有过不去的槛，迈过去了，那就是你的护城河。