平台设计中的脚本管理

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

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

这里所说的脚本化，其实严格来说是校本化，工具化的延伸。是相比于基础功能命令，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备份恢复，这个工作如果和高可用方案连接起来就会更有意义了，就可以实现一个所谓的自动化流程。

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