平台设计中脚本管理的示例分析

这篇文章将为大家详细讲解有关平台设计中脚本管理的示例分析，小编觉得挺实用的，因此分享给大家做个参考，希望大家阅读完这篇文章后可以有所收获。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

关于“平台设计中脚本管理的示例分析”这篇文章就分享到这里了，希望以上内容可以对大家有一定的帮助，使各位可以学到更多知识，如果觉得文章不错，请把它分享出去让更多的人看到。