平台设计中的脚本管理

前期揉入了一些功能,因为主要是面向基础功能,所以进度略慢,如果要想一下子有种井喷的效果,那就是脚本化和流程化大显身手的时候了。

如果尽可能减少开发和业务同学之间的技术代沟,使用脚本化和流程化我认为就是一个纽带。

这里所说的脚本化,其实严格来说是校本化,工具化的延伸。是相比于基础功能命令,SQL,接口的进一步抽象。

我来分别对脚本管理,流程管理做一个基本的解释,欢迎各位拍砖,拍得越狠越好,因为我希望听到有价值的建议。

脚本管理是在元数据构建的基础上的,比如对MySQL/Redis DBA来说,操作的基本粒度是数据库实例,那么我们就可以完全按照IP+端口来构建匹配到一个对应的实例,至于硬件,是否虚拟化,配置的明细,这些我们可以通过信息下钻得到更细维度的信息,但是对于我们的操作粒度来说,实例已经足够。

所以有了基础的元数据,要细化并且和管理工作结合起来,才有了充分条件。

我在构建基础平台的时候,随着基础功能的增加,越来约感觉到了复杂度和维度需要简化,细化。元数据的信息可以分为多个菜单,不同的功能之间有关联关系来指定,所以在MTV的Django框架中,我配置了不少的url来支持前期的工作,但是如果是MySQL细节的工作,这个事情要这么做起来,明显会有一个瓶颈,主要的感觉就是要配置一连串的功能,然后通过url和view把彼此连接起来。

比如MySQL方向,我写了30个脚本,那么在这种方式下我至少得配置30+的url信息,和一连串的逻辑实现。

其实对应用来说,就是脚本调用,这样的方式就有些笨重了。所以在脚本管理中,我期望做几件事情,能够改进。

为了能够快速平滑的接入,脚本管理中的脚本语言其实不是瓶颈,都应该全面支持,比如使用perl,使用shell,SQL等,如果脚本本身很稳定,那么完全可以接入进来,总之就是这个环节要开放,不一定要完全是python脚本。平台的开发功能是python,但是脚本管理不一定是python。

在脚本管理中,脚本和菜单如何映射,这是个关键,我们可以把脚本属性参数化,比如脚本名,脚本的类型等这些也是作为一种元数据来管理。这样就会是一个统一的接口的方式,至于具体的连接方式,比如树形结构或者其他可行的方式。

平台方向上可以提前规划,但是对于开发和业务同学来说,无需配置大量的url,就可完成一些基础或者复杂功能的扩展。

现有的基础架构和功能,脚本化对于它来说也是起到促进作用。需要提前规划和已有的基础功能是否有可衔接的地方。

脚本管理支持文件的上传和脚本内容编辑。这个就是偏具体技术的实现了,比如ACE编辑器。

脚本的参数管理,有的脚本是1个参数,有的是2个,其实对于后台来说,就是拿到脚本来处理,怎么做标识和匹配。

脚本管理中,有些脚本是通用的,如果希望能够持续使用,必须要提前规划好范围和类别。有些脚本是具体的一些业务场景需要的,需要明确需要的参数和权限。

脚本不光用通用和私有的范围,而且还需要细化到具体的作用域范围。

如果来说下流程管理。下面是我之前规划的饿一个数据库方向锁要做的事情和发力的方向,但是这样是通过流程的方式把这些贯穿起来,这个事情就好办多了。

比如备份恢复的工作,我们分为全量备份恢复,增量备份恢复,binlog备份恢复,这个工作如果和高可用方案连接起来就会更有意义了,就可以实现一个所谓的自动化流程。

我继续细化一下,画出一个流程图来说明一下。

  • 发表于:
  • 原文链接http://kuaibao.qq.com/s/20180212B17ZYU00?refer=cp_1026
  • 腾讯「腾讯云开发者社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 cloudcommunity@tencent.com 删除。

扫码关注腾讯云开发者

领取腾讯云代金券