数据库纳管平台DBhouse的技术路线与实践
大家好，我是陈昊，我的分享包括四个部分：产品建设背景，为什么要做DBhouse；产品架构，包括技术架构和产品功能；DBhouse的几个关键技术路径去分享；分享现阶段的投产经验。
一、DBhouse诞生记
在当前互联网时代背景下，运维的数据库种类呈现出急剧增长的态势，主要原因是数据类型不一样，有关系型的、非关系型例如文档型的等不同分类，另外在政策的影响下，国产数据库也应运而生，这就导致企业中使用的数据库种类和数量越来越多。随着业务的不断增长，上线变更也越来越频繁，对数据库性能和稳定性的需求也在持续增加，单个数据库服务器已经难以满足业务需要，必须考虑数据库集群和数据库架构的变化方式来提升性能。
而高性能数据库集群的第一种方式是读写分离，本质是把压力分散到集群的各个节点，但是并没有分散存储压力。第二种方式是分库分表，既可以分散访问压力，又可以分散存储压力。我们以MySQL为例，如果要去做一个MYSQL的高可用集群，首先要对mysql的库进行垂直拆，比如拆分成不同的逻辑库。每个逻辑库也可能会出现多个分片，每个分片采用一写多读的架构去保证节点的可用性。通常也会采用MHA的方式实现高可用，除此之外如果要去满足灾备能力，我们也要把不同的库放到不同的IDC机房里去满足灾备需求。
除此之外，我们也会用到proxy去做读写分离和分片，用LVS去做高可用和负载均衡，ZK去实现分片规则动态更新，通过选举机制来完成节点宕掉之后的主备切换。所以整体看下来，企业当前面临的问题是随着数据库种类的变多，用户量也在不断增多。对DBA的技术能力和架构设计能力也是一个挑战。这是我们遇到的第一个挑战，运维架构的复杂性带来的挑战。
第二个运维挑战是规范。不同的数据库类型会有不同规范，企业一般也会在通用的规范下个性化定制不同规范。整体规范我们大概可以区分为三类，开发规范、上线规范和运行规范。比如在开发规范中，会要求开发人员禁止使用视图，包括触发器和外键的这种情况。上线变更的时候，主库要开启慢同步模式；在运营规范中，比如连接数不允许超过1000等。其实规范是越来越多的，规范类型也不一样，针对不同类型的库规范也不一样。
但是数据库规范化是很有意义的，能尽可能减少数据冗余，并且降低数据插入异常的情况，但是数据变更规范如果全靠人工去维护的话，面临如此多的规范，其实是有一定难度的，我们更希望通过机器去规避这些风险，让机器先一步去做规范审核，所以后面我们也会讲到DBhouse的一大管理功能-SQL审核能力。
第三个挑战是开发和运维团队的交互成本很高。在企业中，一般都是一个DBA对应着很多应用人员，如果应用人员发现问题时再去反馈DBA，然后DBA再去怀疑数据库，进机房去看。整体看下来，传统的开发人员和DBA的交互模式管理起来是比较复杂的。
总结来看，其实就分为两大痛点，一个是数据库运维问题，一个是我们流程管理的复杂度。
那怎么理解自身的复杂度？就是说当开源数据库和传统数据库同时使用的时候就会导致数据库的数量和种类越来越多，并且运行环境也越来越复杂，架构也越来越丰富，互联网上线的变更也变得越来越频繁，流程管理的复杂度也日益增加。
以往的数据库管理方式主要是以需求驱动，运营团队一般是被动去为产品和开发部门提供运维操作，如建库和扩容升级等，比较简单重复，但又消耗大量工作精力。所以我们就在思考，如何去简化这样操作，提升运维效率。
传统管理方式的另一个特点是属于事件驱动型的，团队一般会有一定的事件防御和检查机制，但是又不是很全面。当一个数据库事件发生之后，很多时候都是通过业务部门或者开发部门反馈后运维团队再介入进来，效率就很难提高。另外，传统运营模式下对运维人员的技能要求也比较高， DBA的需求量在不断增加的同时技术门槛也变得越来越高了。
因此，DBhouse应运而生。
简言之，DBhouse是数据库统一纳管平台，帮助企业实现数据库运维自动化、自助化和流程化。有三大功能：
监控能力。我们会去做一些数据库探活，包括数据采集，采集完的数据会定义告警。能力包括常用的数据库巡检，支持导出巡检报表； 安全能力。包括制定规范、客户审核、权限管理、完善审批流程链路、支持审计等。 运维能力。DBhouse最大的特点是帮助运维人员提高运维效率，通过JDBC和脚本的方式能够帮助用户去做很多运维操作，快速处理故障，比如说去做扩缩容。在交付场景上也能去实现自助化、标准化和自动化。
二、DBhouse架构
在讲架构之前，跟大家简单介绍一下的DBhouse目前已经支持的数据库类型。商业数据库主要支持Oracle、DB2还有SQL Server；开源型关系数据库主要支持MySQL和PG；非关系型数据主要支持是MongoDB、Redis；国产数据库目前支持的是腾讯云国产数据库TDSQL，其他数据库在进一步规划中。
下面这张图是整体技术架构，采用的是微服务架构，去实现模块化和层次化，对平台中的所有的功能分层和分模块设计。提供三大服务，基础服务、交互服务和集成服务。
首先看基础服务。基础服务最核心的点在于监控引擎。通过JDBC的方式周期性地从目标库调用数据，最后把数据存储到存储库中，然后通过CMDB服务、监控数据服务，还有分析引擎来去做数据处理。
交互服务主要是去向用户提供的具体功能，包括监控告警能力、问题分析能力、配置用户管理权限等。
集成服务主要是指可拓展性，将DBhouse数据库管理平台的微服务架构支持与客户已有的IT运维资产进行无缝集成，可以集成的服务包括单点登录、工单系统、统一告警平台等。这是整体的一个技术架构。
功能层面主要是分为几层，从下至上是数据层、基础服务层、交互服务和集成服务。
数据层负责存储和管理平台所有数据，包括配置、监控数据。
基础服务层主要起到数据桥梁的作用。底层数据会有很多数据存储，通过基础服务层给上层的功能层去提供各种基础服务， API可以按照需求开放给其他用户使用。主要包括思考执行、监控引擎等。
再往上层是功能层和展现层，功能层展现层主要提供各个数据库的管理功能，包括技能管理、容量管理、问题管理和自动化运维等。
三、DBhouse的关键技术路径
第三部分我会挑上面讲的DBhouse的三个主要功能，对监控能力、自动化运维能力和SQL审核能力的技术路径做一些解释。
首先是监控和告警能力，DBhouse本身提供了大量的数据库运行状态指标，如数据库性能指标、容量分析指标，然后我们会按照固定频率去采集监控数据，从而提供实时查询功能，并且以图形化的方式呈现给使用者，可以将故障分析能力从平均的30分钟缩短到5分钟内。
那我们的数据监控主要是怎么去做的？传统的采集方式一般是采用agent的模式，而DBhouse采用的实际上是一种无agent的模式。那什么是agent的部署模式？所谓agent的模式，顾名思义就是在主机上去部署代理软件，通过代理软件去完成这样主机监控。有agent和我们这种采用JDBC无agent的两种取数方式可以理解为一个是推送数据，一个是拉取数据。在场景上面来看，因为DBhouse的定位本身在于纳管企业的全部数据库，所以会面临着大量的需要监控的数据库，如果采用agent模式，会遇到诸多问题，比如部署周期长，需要在每一台服务器上部署，资源占用性强，并且有可能面临着兼容性风险。
总结来看，agent的模式一是侵入性强，相当于要占用服务器一部分资源，并不是每个客户都可以接受；二是面对监控规模比较大的客户，agent的维护与调度成本也相对较高一些。因此我们采用了一种通过jdbc的无agent模式，通过设置定时任务，周期性地从目标数据库拉取监控指标，而我们也都知道，数据库的不同指标因为其属性不同、监控力度不同，所以我们设置了一个规则引擎，面对不同的指标数据，通过不同的算法进行定时任务拉取。该引擎负责持续对采集到的监控数据进行智能分析，从多个维度、多种规则进行计算，采用了基于基线的智能化算法，从大量的监控数据中筛选出可能影响数据库性能与可用性的问题条目，并持续对已有的问题进行跟踪管理并向用户发起推送。推送时以邮件接口为主，支持不同接口类型及自动发送问题、手动发送问题等多种方式，同时可以进行定制化，与客户的统一监控、ITIL等系统进行无缝整合。
那么DBhouse如何实现自动化运维？我们基于ansible同合作伙伴新数自研了这样一套自动化运维引擎，主要有以下特点：
作业编排：可以自由选择相应的原子化操作编排和发布新的作业流程。在讲作业编排的之前提两个核心概念，一个是作业，一个是任务。怎么理解这个作业？简单理解就是发起一个运维操作，从头到尾以这种结果导向；而任务就是完成作业的每一个步骤。 并行调度: 同一个作业中的任务支持并行执行，在很多场景下能极大的缩短执行时间 断点执行: 执行错误的任务在修复错误后可以继续执行，不需要重新执行整个作业 任务回滚: 遇到错误，可以支持回滚作业中已经执行过的任务，恢复执行环境 计算表达式: 使用表达式动态的计算任务的参数值，能够极大的简化重复参数的输入以及复杂参数的拼接 动态参数：前面任务的输出作为后续任务的输入参数
这是整体的流程图。
简单来说，我们主要分为这样几个层。
第一部分是交互功能，第二部分是引擎，第三部分是任务执行器和消息中心。自动化运维引擎是整个作业系统的调度核心，决定任务什么时候开始执行，作业是否执行完成，启动任务执行器执行任务等。
下面我们就从系统架构，作业的实时运行状态以及编排逐步进行介绍。系统主要分为以下几层：
1. 交互功能: 自动化运维引擎对用户提供原子操作发布、作业编排、管理、作业调度和运行状态查看等功能
2. 作业引擎: 作业系统的调度核心，决定什么任务开始执行，作业是否执行完成，启动任务执行器执行任务，维护作业和任务的状态等
3. 任务执行器: 执行任务的逻辑，针对多种场景扩展了不同的执行器，可以在一个作业流程中同时支持JDBC操作、执行脚本和执行HTTP API操作；由于执行器有各自的执行环境，天然支持多任务的高并发执行
4. 消息中心: 任务执行结束后，通过消息驱动作业引擎进行后续任务的调度，任务执行器不与作业引擎直接交互，降低了系统的耦合度，且利于作业引擎的弹性扩容。
计算表达式为了实现参数的复用，DBhouse引入了表达式的机制。目前，DBhouse主要支持五种表达式，任务参数、全局参数、部分参数、任务组参数和任务结果。也包括前端计算和服务器端的运行计算，表达式包括前端计算和服务器端运行时计算: ${xxx} 在前端进行计算，#{xxx} 在服务器端任务调度的时候进行计算，表达式可以任意组合使用。除此之外，DBhouse也更加简化了参数的输入模式，通过选择器的方式让用户去选择，用户只需要点选就可以完成一个参数的输入。
下一部分是安全管理能力，包括两部分，一部分是怎么更好地匹配SQL语句，另一部分是做安全审批，最开始让机器去做审核，辨别出一些高危和低效的操作，在最后审核通过了之后发起审批，由DBA或者主管部门去进行相关审批，审批通过之后再执行任务。执行任务之前DBhouse会去做数据备份，我们可以选择去自动备份或定时备份。执行过程中我们可以支持定时执行或手动执行，所有操作完成之后，操作记录会形成一个日志供审计或复核。
众所周知，在做整个SQL审核过程中，较为复杂的难点就在语法匹配能力上，如果告诉机器你输入的SQL语句什么，如何去匹配审核规则。谈到SQL解析，就不得不谈一下文本识别。文本识别是根据给定的规则把输入文本的各个部分识别出来，再按照特定的数据格式输出。以树形结构输出是最常见的方式，这就是通常所说的抽象语法树。
DBhouse在做解析的时候是通过词法解析+语法解析+分片上下文提取做到的。在词法解析上面，DBhouse会通过自己的词法解析器将SQL拆分为一个个不可再分的词法单元（Token）。在SQL语法中，通常将词法单元拆分为关键字、标识符、字面量、运算符和分界符。
在做完词法解析之后再进行语法解析。这里的语法解析，我们一般采用的是贪婪匹配算法。
在做完词法解析后，我们随后会进行语法解析，这里语法解析我们采用的是贪婪匹配算法，就是最长路径匹配方式，语法解析器每次从词法解析器中获取一个词法单元。如果满足规则，则继续下一个词法单元的提取和匹配，直至字符串结束；若不满足规则，便提示错误并结束本次解析。
语法解析难点在于规则的循环处理以及分支选择，还有递归调用和复杂的计算表达式等。
在选择分支时，可能会出现一个分支是另一个分支的子集。此时，当成功匹配短路径时，需要进一步匹配长路径，在无法匹配长路径时，再选取短路径，这称之为贪婪匹配。如果不使用贪婪匹配的算法，则最长的分支规则便永远不能被匹配了。
完成了SQL解析之后，最后一步便是对数据分片所需的上下文进行提取。它通过对SQL的理解，以访问抽象语法树的方式去提炼分片所需的上下文，并标记有可能需要改写的位置。最后返回到用户界面提示需要改写这个SQL是高风险还是低风险的，可能需要改什么内容等。
四、经验总结
最后分享一些经验总结。第一个经验是在以往没有运维工具的场景下，我们发现异常之后流程是比较长的，通过DBhouse我们可以尽最大程度去降低人与人之间的交互，降低沟通成本，通过这样便捷、易用、安全、保密可追溯性最大程度地提高运营效率效率。第二个经验就是可拓展性，因为DBhouse就是要帮助用户管理数据库，提供运维和监控能力，保证安全，所以在整体设计的过程中，DBhouse所有模块化功能都具备可拓展性的能力，能够自定义运维工具。
第三个经验是整体运维分析能力，帮助用户随时随地发现数据库存在的问题，通过可视化报表展现出来。
﹀
﹀
﹀
↓↓点击阅读原文，了解更多优惠