共计 3108 个字符，预计需要花费 8 分钟才能阅读完成。
本文来自腾讯蓝鲸智云社区用户：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，再迭代，小步快跑；
- 一开始就要站在前期推广角度思考我的项目所能带来的业务价值，否则效力类实际一旦落地成果不好，本人又没有思考久远，很容易就被毙掉，特地像当初整体不景气的职场环境背景下；
- 没有过不去的槛，迈过去了，那就是你的护城河。
