9月16日，Distributed Cloud|2021全球分布式云大会·上海站隆重召开。在全球分布式云大会不懈布道下，云计算行业对分布式云的关注度愈发高涨，以全球分布式云联盟成员为代表，涌现出了大量分布式云技术和实践成果，为分布式云计算发展夯实了基础。
2021全球分布式云大会为分布式云计算发展再添强大推力，本次大会共设有分布式云主题报告会、边缘云论坛、云原生专题论坛、分布式数据库论坛四大论坛，围绕分布式云、边缘算力、云原生、分布式架构等技术与实践展开。全球分布式云联盟联合阿里云、腾讯云、Google Cloud、中兴通讯、京东云、安迈云、网心科技等国内外分布式云顶尖技术服务商，共话分布式云创新新趋势，共谋云计算变革新未来，共享分布式云计算新红利！
在9月16日下午召开的分布式数据库论坛上，陆金所 bettle 产品架构师王剑发表了题为《平安集团数据库规范管理平台 bettle 最佳实践》的精彩演讲。
关于bettle
王剑首先介绍了金融领域使用数据库遇到的问题。使用数据库账号直接操作数据库，会带来无法溯源、线上数据遭篡改、错误操作导致数据清空、问题DDL导致数据库性能下降、DBA效率及流失、故障频发等风险。传统规则下，一旦用户量或应用数量提升，就会导致开发规模增加、变更频率加大、DBA审核遗漏、DBA瓶颈无法快速响应、无强力保障手段等问题。
针对上述行业痛点，平安集团推出了bettle，bettle是一款支撑数据变更完全生命周期的一站式数据规范变化平台，是建立在DBA开发和生产数据库之间的一道防火墙。得益于bettle，平安集团可以把一些问题，在产生之前拦截在测试或者开发阶段。
接入bettle能够带来很多的改善，比如DML变更为双备份，一旦出现问题，可以急速恢复；变更后采用无锁表结构，DDL变更不会锁表。Bellte的结构设计和研发流程，每个阶段都是可以通过低代码配置实现一些企业定制。
Bettle接管整个平安生态下业务系统数据库规范，经受6年的充分考验，接管了集团内部2000多个子系统，历经20万次的高频上线，在故障率减少了90%的同时，让DBA工程师效率提升约60%，团队规模却缩减了50%。
为了让bettle价值最大化，平安集团决定将其对外输出。在对整个bettle进行架构评审之后发现，之前1.0版本有很多问题，比如当时的数据规则直接代码里写死了，通过开关的启用/关闭；审核也和平安体系耦合比较深，如果要做技术输出，对接外部公司的流程以及规则，这个方案就没办法大面积推广。
陆金所对bettle核心的四个方向上进行了改造，做了基于低代码的方式、业务流程自定义的方式，整个bettle的全生命周期里，基本上五大主流程都可以做自定义，根据客户的需求做自定义的编排对接以及改造。这项工作不需要开发介入，售前工程师就可以完全编排出来。另外变更的对象也进一步扩展，之前有资源、索引的变更，2.0版本把触发器、序列、函数等也集成进来。同时设计了一套数据库扩展机制，对传统数据库做数据规则的集成，先把数据库的共性抽出，基于共性设计元规则引擎，一旦基于这个方式跑起来之后，一旦一个新的数据库想接入平台，不需要对它做规则开发，而是基于元规则引擎，直接把该数据库的规则配出来，这也是低代码模式下的一种能力。
从bettle2.0产品的架构图中可以看到，平安集团是从bettle最核心的功能元数据的变更入手，对整个数据库进行了接管，整个流程都是可配置、可扩展的，都是通过低代码能力配置出来的，非常灵活。
基于低代码的架构方案，包含两大主要引擎: 流程编排引擎、元规则驱动的规则引擎，规则引擎和一般意义上的规则引擎不同，它基于元规则驱动的规则，更加灵活。业务流程引擎，贯穿整个bettle流程，从变更单新建，到最终的业务上线，都是由流程引擎驱动。Bettle的低代码底层数据也是一套通用表引擎，整个bettle系统是只有一套表结构，这个表结构驱动了整个bettle的业务流转。
特色功能
王剑随后介绍了bettle2.0的核心的能力：
基于元规则的数据库支持扩展：基于可自定义的数据库元规则实现规则的自定义，动态支持多种数据库；
全生命周期业务流程自定义：整个变更生命周期（元数据导入、授权、变跟单、部署、发版...）等节点业务流程自定义；
字段级权限管控：基于动态OWNER的字段级数据权限管控，带给你协同变更的优质体验；
变更专家建议：基于知识库的SQL优化解决方案，通过特定领域的专家知识库沉淀提供优化建议；
标准的对外服务集成：提供页面维度、接口维度的可定制化集成方案。
王剑表示，五大核心能力中，前两点是重中之重。
规则方面，基于元规则做数据库的扩展支持，比如传统方式支持Oracle需要为Oracle定制一套规则，需要从0做起，因此平安集团打造了一套通用的规则引擎，通过元规则描述具体需要支持新数据库的规则，动态扩展出一系列的特定数据库规则，把扩展出的规则交给规则引擎驱动，之后做问题扫描和规则扫描。
解决
在整个bettle的生命周期里，贯通全流程里有一个通用的业务流程引擎，结合低代码平台服务编排核心能力，用户不需要了解过多的业务细节，只需要关注服务的配置，就能完成编排的能力。此外还会有字段级权限控制以及变更专家建议，变更SQL会提交到平安集团，根据知识库的规则以及建议方案，给客户提供优化建议，告知风险，告知风险解决办法，这是bettle的核心能力。
Bettle对外输出，还需要提供更多的与外部系统对接的方案，bettle本身有一套不固定的流程体系，可以对接外部公司大部分系统。比如用户的发版系统或者审核系统，都可以对接。因为全流程都是编排方式的，对接公司来无非就是流程节点里面的某一个节点，保证数据在整套系统里驱动起来之后，就可以做到无缝对接。
用元规则驱动是为了让数据库规则限制更标准化、通用化。在1.0版本时，业务方有扩展新数据库的需求，比如面对MySQL，需要对应编写。这样带来一个问题，一旦对外铺开，不同数据库、不同公司规则描述不一样，就需要维护很多不同数据库的不同规则，开发和人力成本将居高不下。使用元规则引擎描述数据库的规则，用自身的规则引擎基于描述出来的规则去审核SQL，从而实现标准化和通用化。
另外bettle规则支持分级，例如有些场景需要紧急上线一个SQL，但这个SQL可能和规则有冲突，无法被审核通过。这时候就需要绕开之前定义的规则扫描，分级就发挥了很大的作用，对每个规则进行一个评分，一旦分值达到设定的阈值，就可以忽略部分限制。
元规则引擎架构方案，底层是通用的SQL解析器，能够解析成一些类似元规则协议，它完整描述了例如一个表、一个SQL、一个索引或一个虚拟的触发器，用bettle的描述规则来完整地描述SQL。在SQL之上还会有一份描述，这是由于底层的SQL来自Oracle或Tidb，bettle定义了一套适配层，适配SQL和规则引擎的协议层，它来做协议的描述。之后针对表字段索引，支持数据库对象，做了元规则的定义。表里有命名名称的规则，只要基于Table-DSL，规则就可以跑起来。这套方案的目的就是为了减少为特定数据库编写特定规则的成本，增加SQL审计规则能力。
规则之后，整个bettle对外对接需要完成一个很重要的事情——业务流程的动态扩展。有的公司可能需要一个DDL语句发版流程，需要先到测试环境验证，之后才能发版；有的公司需要开发部署确认，才能到测试发版的流程；对bettle的表和字段都会有权限，也涉及是否有表的权限和权限的审批流程问题。动态扩展的好处，整个系统是灵活的，无论公司是用其他服务商还是自建，bettle的部署都可以通过节点的扩充完成我整个功能的扩展。
Bettle的变更单都有审批机制，审批的流程比较灵活，传统公司以线下或邮件的形式走审批；数据化程度比较高的公司，比如平安有一套EOA，其他厂商有自己的流程系统，bettle如果想要对接各种不同公司的流程系统，就需要一套比较灵活的流程方案，通过自建的流程体系，轻松做到和外部流程体系对接。不同的流程还涉及到一个问题，系统之间的流程流转和平安系统的上线流程是并行的，这里有一个节点拦截问题。比如说测试阶段通过了，下一个阶段到DBA审批，DBA如果到平安的系统做发版，会对它做拦截，告知前面的测试并没有在系统里面执行部署，没有做测试确认，最终上线就会被拦截下来。这种限制可以是强制性的，也可以是弹性的，特殊情况下也能够支持减少验证。
王剑展示了简单的流程图，基于低代码引擎和业务流程引擎驱动。流程节点可能会对接外部的公司，每个节点实现的功能可能是不一样的，这就是依靠低代码引擎编排出来的。编排出来的节点，具备了某种能力，比如部署到阿里云的一个节点，这个节点就具备了阿里云的部署能力，低代码会对一些技术功能做封装。封装完之后，业务流程引擎基于低代码引擎封装的模块或者节点，再做驱动，就相当于把整个生命流程，包括变更、审批，都做了一个可以动态变化，以及灵活配置的定义。
这套流程体系基本上落地到了bettle所有的生命周期里。以授权为例，传统的数据权限是直接添加。有的公司授权的时候，自动添加；有的公司授权需要做审批，这就是整个流程的灵活之处，授权可以选择审批，也可以选择不审批，在流程里面每个环节都可以做路由配置。
字段级权限控制也是比较重要的功能。Bettle是管控元数据、DML的，管控元数据时，可能表结构会有一些敏感字段，或者非权限字段，就会有字段级的权限管控机制，基于一个动态owner的解决方案灵活权限。比如说这个数据谁有权限能查看，就支持基于行数据的动态生成权限。动态owner机制就可以很轻松实现，团队在附属owner的基础上，建立了一套动态owner的修改，数据行里面字段要把那个owner、个人、组织加进去，在创建整个完整数据变更时，都会做校验。Owner授权会有时间限制，比如修改或者查看的权限设置为只有两个月，在这套机制中能实现授权的时间期限。
规则引擎现在改造成基于元规则的引擎，除了SQL之外，还可以做建议型的方案，匹配用户的SQL给出一些建议。比如说我是Oracle专家，但是我不是MySQL专家，我在做MySQL时给予我的知识不能把SQL的问题审查出来，这个规则就可以基于预制的规则匹配或系统去做规则的配置，筛查出来，一旦SQL命中了这条规则，就会建议如何修改或如何改造SQL。这是一个简单的架构，其实就是基于规则的推理机制，并没有一个很复杂的逻辑，根据定义的规则去匹配。
与很多不同需求的公司对接是bettle面临的一大痛点，有的公司需要把bettle直接集成到自己的系统里面，有的想把bettle作为一个独立系统部署，需要对接对方的子系统——用户系统；还有的只需要变更服务，不需要界面和底层功能；有的觉得变更流程太死板，想改造成符合自己公司的变更流程，这些方案要求基于两种方式，一是低代码模式去做服务编排，完成流程的对接，或和外部第三方系统做对接。另外我们一套标准服务，在bettle的服务生命周期里出一套标准的服务，里面包含了变更单的新增、查询，权限查询和权限授予，形成完整的配套流程。标准服务也是基于低代码引擎驱动的，这是预制的一些服务。如果业务公司A，发现变更单服务节点，和bettle的标准服务很像，但里面的某个节点可能有差异，可以从bettle的标准里面复制出来，因为bettle本身是基于低代码的，可以做微调，这是非常灵活的扩展的能力。
GDCC
