开源产品评估报告（Inception & Yearning）

问题的提出

随着微服务项目越来越多，和数据库的交互越来越频繁，导致DDL（表的增删改）和DML（数据的增删改）数量持续增多。加上部署的数据库环境有很多，一个脚本没有运行，可能就导致部署失败或产品失效。这个问题最终体现为运维成本开始居高不下。

另外随意的提交DDL和DML，导致DBA无暇审核相关脚本，总是先执行了再说，既存在反复修改的可能性，又存在一定的数据风险。

目标

通过应用一定的管理手段，对DDL和DML请求进行管理，需要达到以下几个目标：

1. 对DDL和DML的自动审核。确定一些规则要求，通过系统执行检查，可以拒绝那些不符合要求的请求；
2. 审核通过后可自动执行到目标数据库；
3. DDL和DML操作可回滚；
4. 所有DDL和DML请求进行存档，方便查找和追溯；
5. 不会显著增加工作量。

产品选型

主评估产品

解决方案

解决方案是通过SQL审核平台管理所有的DDL&DML请求，由平台代理审核、执行的工作，替换掉人工操作，DBA只要点击审核或执行即可。底层原理是对接目标数据库，通过中间层做规则校验、审核或执行。上层的ui系统负责持久化和拒绝、接受、查询等流程性的工作。

产品介绍

由于SQL审核平台需要底层审核模块和上层系统模块两部分组成，所以主评估产品分别是Inception和Yearning。

Incpetion负责审核和执行SQL，是平台的主要功能所在。其实现了一个类似mysql的环境（中间件），实现规则制定，试运行和真实执行的代理。Inception是去哪网放出和使用的开源产品，目前没有更新。

github地址：https://github.com/mysql-inception/inception
文档地址：http://mysql-inception.github.io/inception-document/

Yearning是管理平台，负责提交、审核、执行DDL&DML请求。也可以通过这个平台进行查询，回滚等操作。更新较频繁。

github地址：https://github.com/cookieY/Yearning
文档地址：https://cookiey.github.io/Yearning-document/

其它同类产品

Inception目前没有发现同类产品。

Yearning作为上层的服务，有若干同类产品，即都是基于Inception实现SQL审核。archer是其中一个

github地址：https://github.com/jly8866/archer

对比依据及结论

archer没有经过评估，和Yearning比较，github上的star数偏少（270 vs 533），更新也不如后者频繁，所以重点评估Yearning。

产品评估详细过程

安装

安装过程有专门文档描述，详见https://www.jianshu.com/p/03e784106003

试用

试用地址：（恕不公开）

初始化
系统管理员首先需要初始化整个系统，主要包括

1. 创建可提工单的用户和可审核的高级用户，用户的权限可以细分，包括可选择的数据库以及可提交的DDL或DML请求；
2. 创建数据库连接，通过这些连接可以直接读取数据库schema，并做sql的检测。

工单操作
用户通过工单的方式提交请求，通过权限可以控制用户能够访问哪些数据库，支持手工的写sql或者从读取的schema上反向生成提交sql。

工单的请求会有检测环节，只有通过了检测才能提交给审核人审核。这里需要根据公司情况调节检查规则。

审核与执行
管理员可以对工单进行检测，如果不同意执行，则拒绝该提交，否则可以通过平台执行到目标数据库中。

通过设置备份库，可以使部分的DDL或DML进行回滚操作，保证安全性。

测试

暂无

相关人员评审结果

实际评估人

Inception & Yearning的组合可以实现SQL审核的功能，并管理这些提交到目标数据库的相关请求。主要关注的问题在于

1. 审核规则要定义好，默认规则大部分现有SQL语句都不能通过，降低实用性；
2. Yearning还未提供查询和tag功能，可能对管理这些sql产生一些困难；
3. 目标数据库要单独提工单，例如对uat和生产，同样的sql要提交2遍，当然这也是合理的，因为环境确实有可能不同，但总是增加了额外的工作量。

建议：继续跟踪Yearning的进展，多方确定是否上这个平台，如果要上的话，必须制定相关的管理规范。

开发团队

• Required: false
• Description: 如果需要的话

产品团队

• Required: false
• Description: 如果需要的话

运维团队

• Required: false
• Description: 如果需要的话

公司管理层

• Required: false
• Description: 如果需要的话

注：除实际评估人外，其它四个团队最少有一个要提出评审意见

最终结论

是否引入到公司产品体系的最终结论

• Required: true
• Description:
  1. 是否应用该被评估产品
  2. 应用后能否解决现有问题，能否达到预设目标

实施计划

• Required: true
• Description: 包括并不限于实施进程、实施结果和参与人等。