运维开发体系升级的思考

这是学习笔记的第 2367篇文章

在大概4年前，我们算是从0到1的构建了现在的数据库运维开发体系，这个过程有较长的启动周期，从我个人主导到后来的成员独当一面，从零星的功能建设到现在有了相对体系化的建设，现在想想真是不易。

运维开发这件事情的理念契合，我们花了很长的时间，限于有限的资源和技术储备，我最终选择了Python技术栈，其实第1年是最让我焦虑的，这种焦虑打个比方，就好像我是司机，手里拿着方向盘，车上的乘客的心态是和我完全不同的，乘客就希望准时到达终点（满足眼前当下的需求），同时希望路程要快，耗时短，而且车费便宜，在能够满足当下需求的情况下，要推进新的体系需要额外的精力和时间，也是在这段时间，我自己算是新手上路了，直接从零开始了Python技术体系的学习和构建。

我们早期的项目框架是基于OpsManage来构建的，在前后端框架的基础上我们完全裁剪了前后端功能，也就意味着所有的模块都是在不断的磨合中构建出来的，早期的项目代码质量相对不高，以快速交付为主，当然也留下了一些祸根，那就是“祖传代码”不太好改；代码克隆的现象比较普遍，导致很多逻辑有重复之处；此外开发习惯的不同，导致缺少一些基本的开发规范，所以从性能和设计角度来说是相对欠缺的。

当然在这个过程中也总结了一些经验，比如对于模块化的思考，早期的OpsManage体系的构建是一个相对独立的Python服务，随着业务的接入，有了MySQL,Redis等数据库，为了对一些运维功能和技术栈有所区别，开始刻意配置了大类的目录结构。

随后我们把Django中view层的代码尝试提炼出来，单独成为一个Restful模块，这个模块中没有任何前端逻辑，是作为API对接的核心模块，同时Restful又通过API和view实现无缝的对接，随着前端功能的外部支持，我们保留了最基础的本地前端，而其他的前端都是完全由前端团队来支持实现的，算是对于前后端分离开发的一种经验模式。

现在随着业务接入，也发现存在一些明显的瓶颈，此外，现有的模式还能用，但是从技术栈上已经过期了，后续的升级维护几乎无从谈起，现在是一种无形的推动力需要我们提前思考和规划。我开始构建新版本的开发环境，打算从整体设计上能够有所侧重，同时对已有的开发体系进行认真梳理和复盘。

现在的技术栈情况如下：

操作系统 CentOS6.8

VirtualBox5.1

Pycharm 早期版本

Python 2.7.6

Django 1.7版本

MySQL 5.7

Redis 3

规划后打算采用的技术栈：

操作系统升级 CentOS7.8

VirtualBox升级至6.1

Pycharm 2021.3版本

Python 3.9最新版本 2021.6.28

Django 3.2版本

MySQL 8.0

Redis 5

目前的环境构建已基本完成，我对于相关依赖库更为看重，至少3.9在相当长的一个周期内是完全可用，而且更新度较高的。

具体一些的依赖库我更看重的则是和机器学习相关的，比如sklearn,numpy,pandas，tensorflow等，这些是后续考虑接入的重心。

此外在体系的设计上，原计划如果能和开源版本的OpsManage保持同步是相对代价最低的，但是现在这几件的沉淀，模块的建设和原本的OpsManage已经相差很大，所以从集成的角度来看，先集成最新的开源版本再迁移业务的模式是不大可行的。

整体的步调如下：

1）梳理现有Python 2.7技术栈的代码情况

2）第一次瘦身在现有Python 2.7的基础上完成，删除荣誉的代码模块和页面

3）完成新一版本的模型设计

4）新版本的模型设计在新环境中构建测试，

5）开发模块和后端API体系的重新规划

6）按照业务模块逐步迁移至新环境中

整体的工作量还是不小的，单纯构建环境已经感受到了满满的挑战了。

各大平台都可以找到我

• 微信公众号：杨建荣的学习笔记
• Github：@jeanron100
• CSDN：@jeanron100
• 知乎：@jeanron100
• 头条号：@杨建荣的学习笔记
• 网易号：@杨建荣的数据库笔记
• 大鱼号：@杨建荣的数据库笔记
• 腾讯云+社区：@杨建荣的学习笔记