共计 5845 个字符，预计需要花费 15 分钟才能阅读完成。
为帮忙开发者更好地理解和学习前沿数据库技术，腾讯云数据库特推出 ”DB · TALK“ 系列技术分享会，聚焦干货赋能翻新，邀请数十位鹅厂资深数据库专家每月和您一起深入探讨云数据库的内核技术、性能、架构、治理运维和最佳实际等。
3 月 30 日第一期分享会“数据库治理与运维”专场已完结，错过直播的小伙伴也不要拍大腿，本期带来 腾讯云数据库产品经理陈昊分享《数据库对立纳管平台 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 同合作伙伴新数自研了这样一套自动化运维引擎，次要有以下特点：
作业编排 ：能够自由选择相应的原子化操作编排和公布新的作业流程。在讲作业编排的之前提两个外围概念，一个是作业，一个是工作。怎么了解这个作业？简略了解就是发动一个运维操作，从头到尾以这种后果导向；而工作就是实现作业的每一个步骤。
并行调度 : 同一个作业中的工作反对并行执行，在很多场景下能极大的缩短执行工夫。
断点执行 : 执行谬误的工作在修复谬误后能够继续执行，不须要从新执行整个作业。
工作回滚 : 遇到谬误，能够反对回滚作业中曾经执行过的工作，复原执行环境。
计算表达式 : 应用表达式动静的计算工作的参数值，可能极大的简化反复参数的输出以及简单参数的拼接。
动静参数 ：后面工作的输入作为后续工作的输出参数。
这是整体的流程图。
简略来说，咱们次要分为以下几层。
第一局部是交互性能，第二局部是引擎，第三局部是工作执行器和音讯核心。自动化运维引擎是整个作业系统的调度外围，决定工作什么时候开始执行，作业是否执行实现，启动工作执行器执行工作等。
上面咱们就从零碎架构，作业的实时运行状态以及编排逐渐进行介绍。零碎次要分为以下几层：
- 交互性能: 自动化运维引擎对用户提供原子操作公布、作业编排、治理、作业调度和运行状态查看等性能
- 作业引擎: 作业系统的调度外围，决定什么工作开始执行，作业是否执行实现，启动工作执行器执行工作，保护作业和工作的状态等
- 工作执行器: 执行工作的逻辑，针对多种场景扩大了不同的执行器，能够在一个作业流程中同时反对 JDBC 操作、执行脚本和执行 HTTP API 操作；因为执行器有各自的执行环境，人造反对多任务的高并发执行
- 音讯核心 : 工作执行完结后，通过音讯驱动作业引擎进行后续工作的调度，工作执行器不与作业引擎间接交互，升高了零碎的耦合度，且利于作业引擎的弹性扩容。
计算表达式为了实现参数的复用，DBhouse 引入了表达式的机制。目前，DBhouse 次要反对五种表达式，工作参数、全局参数、局部参数、工作组参数和工作后果。也包含前端计算和服务器端的运行计算，表达式包含前端计算和服务器端运行时计算: ${xxx} 在前端进行计算，#{xxx} 在服务器端任务调度的时候进行计算，表达式能够任意组合应用。除此之外，DBhouse 也更加简化了参数的输出模式，通过选择器的形式让用户去抉择，用户只须要点选就能够实现一个参数的输出。
下一部分是平安治理能力，包含两局部，一部分是怎么更好地匹配 SQL 语句，另一部分是做平安审批，最开始让机器去做审核，分别出一些高危和低效的操作，在最初审核通过了之后发动审批，由 DBA 或者主管部门去进行相干审批，审批通过之后再执行工作。执行工作之前 DBhouse 会去做数据备份，咱们能够抉择去主动备份或定时备份。执行过程中咱们能够反对定时执行或手动执行，所有操作实现之后，操作记录会造成一个日志供审计或复核。
家喻户晓，在做整个 SQL 审核过程中，较为简单的难点就在语法匹配能力上，如果通知机器你输出的 SQL 语句什么，如何去匹配审核规定。谈到 SQL 解析，就不得不谈一下文本辨认。文本辨认是依据给定的规定把输出文本的各个局部辨认进去，再依照特定的数据格式输入。以树形构造输入是最常见的形式，这就是通常所说的形象语法树。
DBhouse 在做解析的时候是通过词法解析 + 语法解析 + 分片上下文提取做到的。在词法解析下面，DBhouse 会通过本人的词法解析器将 SQL 拆分为一个个不可再分的词法单元（Token）。在 SQL 语法中，通常将词法单元拆分为关键字、标识符、字面量、运算符和分界符。
在做完词法解析之后再进行语法解析。这里的语法解析，咱们个别采纳的是 贪心匹配算法 。
在做完词法解析后，咱们随后会进行语法解析，这里语法解析咱们采纳的是贪心匹配算法，就是最长门路匹配形式，语法解析器每次从词法解析器中获取一个词法单元。如果满足规定，则持续下一个词法单元的提取和匹配，直至字符串完结；若不满足规定，便提醒谬误并完结本次解析。
语法解析难点在于规定的循环解决以及分支抉择，还有递归调用和简单的计算表达式等。
在抉择分支时，可能会呈现一个分支是另一个分支的子集。此时，当胜利匹配短门路时，须要进一步匹配长门路，在无奈匹配长门路时，再选取短门路，这称之为贪心匹配。如果不应用贪心匹配的算法，则最长的分支规定便永远不能被匹配了。
实现了 SQL 解析之后，最初一步便是对数据分片所需的上下文进行提取。它通过对 SQL 的了解，以拜访形象语法树的形式去提炼分片所需的上下文，并标记有可能须要改写的地位。最初返回到用户界面提醒须要改写这个 SQL 是高风险还是低危险的，可能须要改什么内容等。
四、经验总结
最初分享一些经验总结。第一个教训是在以往没有运维工具的场景下，咱们发现异常之后流程是比拟长的，通过 DBhouse 咱们能够尽最大水平去升高人与人之间的交互，升高沟通老本，通过这样便捷、易用、平安、窃密可追溯性最大水平地进步经营效率效率。
第二个教训就是可拓展性，因为 DBhouse 就是要帮忙用户治理数据库，提供运维和监控能力，保障平安，所以在整体设计的过程中，DBhouse 所有模块化性能都具备可拓展性的能力，可能自定义运维工具。
第三个教训是整体运维剖析能力，帮忙用户随时随地发现数据库存在的问题，通过可视化报表展示进去。
想获取更多数据库相干常识，能够关注【腾讯云数据库】微信公众号哦
