分布式架构可能是近年来最热门的话题。从集中式、SOA到分布式架构，回顾了近几年金融行业经历的架构演进；结合一些典型的分布式数据库的实现原理，分析了分布式数据库的三个发展阶段。分布式数据库的应用解决了传统数据库的性能扩展问题的同时，也给运维人员带来了挑战。那么，分布式数据库的管理还有哪些呢？如何管理好它们？未来数据库和数据库运维将走向何方？看完这篇文章，你就能找到答案。1、金融行业近年来经历了怎样的架构演进？1.中心化架构分布式架构可能是近年来最热门的话题，相对于银行等传统金融行业最流行的中心化架构。通用部署架构。在“去IOE”之前，各大银行的目标依然是做强做大中心化单点。许多银行采用IBM的大型机系统就是一个生动的例子。对于数据库服务器尤其如此，它们通常是可用的最佳机器。近年来，随着银行业务的增长、互联网行业的爆发以及用户行为模式的改变，中心化架构系统面临着巨大的挑战。问题主要体现在可扩展性和可用性两个方面：1.集中式架构在水平扩展方面的可扩展性非常低。面对性能不足，用户能做的只有加CPU、加内存、换存储、换机器。2.可用性集中式架构的服务能力依赖于高性能的主机。但是，一旦主机出现故障，上述服务就会受到影响。这个问题的解决方案是构建一个高可用的架构。每个环节都需要考虑冗余和HA。这几乎是中心化架构下最好的方式。但是，无论是哪个环节出现故障，都会影响全局服务。该架构下的数据库也通过主备机的冗余，HA服务的自动管理和切换来实现高可用。在性能方面，通常采用垂直扩展。然而，垂直扩张是有限的。万一最强宿主扛不住怎么办？图1集中式架构集中式架构数据库有一个例外，那就是MPP数据库。为了解决单节点数据库的性能上限问题，一些数据库厂商开发了MPP数据库。这种数据库可以看作是一组集群，数据分布在这些集群的节点上，数据查询服务也可以下推到这些节点上完成。通过数据分发和功能分发，充分利用多个节点的处理能力，这简直是目前分发的先驱。图2集中式MPP架构图中的协调节点CN并不是一个特殊的组件，它可以是任意的DN。但是这类产品是面向OLAP解决大查询问题的，和现在的分布式方向不同。2、面向服务的架构（SOA）在互联网浪潮还没有到来，分布式架构还没有出现的时候，为了解决单机性能瓶颈和全局服务可用性问题，最初的解决方案是业务拆分，即面向服务的架构（SOA）开始应用。纯SOA实际上是一种组件模型，它将应用程序的不同功能单元（称为服务）进行拆分，并通过定义良好的接口和协议将它们连接起来。SOA架构已经流行了一段时间，当然现在微服务模型更流行了。图3.SOA架构当时很多银行都是按照这种思路拆分核心系统，将一个大系统拆分成多个小系统或组件。好处是服务拆分后实现部分性能扩展。之所以是一部分，是因为总有一些核心服务是热点，没办法拆分。由此带来的缺点是系统调用链的复杂度增加，不同服务之间的数据同步要求越来越复杂，系统和服务器数量增加。即使有了SOA的思想，热点功能的性能和可用性问题也没有得到彻底解决：1、核心功能的横向扩展没有实现，单一功能仍然集中部署在架构中。2、没有实现数据的水平拆分，不能解决数据量大的问题，反而带来了对不同系统数据同步的复杂需求。3.分布式架构当金融行业还在忙于拆分和改革系统功能，为新的小型机做预算时，中国的互联网科技行业正在发生重大变化。大数据技术发展：第一个重大变化是各种分布式开源软件的成熟和充分利用。分布式存储、分布式计算、分布式消息中间件引领大数据产业变革。这些分布式技术简单粗暴地解决了大数据量、高吞吐量和高可用性的问题。业务系统和后端数据库也存在这些挑战。看来数据库要分布式才是最终的解决方案。然而，数据库行业的领头羊并没有像拥抱云技术那样拥抱分布式数据库，反而给了很多初创的数据库公司机会。互联网消费行为：另一个重大变化是互联网行业改变了用户的消费行为。过去几年，网络运营商提速降费，互联网移动设备出货量猛增，用户的消费习惯也从线下转向线上。中国的人口红利在互联网行业得到充分发挥。对于金融行业而言，用户消费行为的变化给金融科技带来了挑战。交易量和数据量不断攀升至峰值。尤其是网银、手机银行等渠道业务，在中心化架构下将面临性能瓶颈。最典型的就是阿里。从2011年开始，阿里出于成本考虑，逐渐转向IOE，同时每年都拿出双十一的成绩单。高帅夫的小电脑换成了PC，Oracle数据库换成了开源的MySQL数据库。同时，自主研发的分布式中间件TDDL实现了水平扩展。阿里靠堆廉价PC撑起了庞大的双十一大促业务，最终交出了交易量、峰值、金额等漂亮的成绩单。现在阿里的分布式中间件发展成了关系型数据库DRDS。同时，阿里还有面向金融领域的完全自研内核OceanBase，以及专注于云数据库存储计算分离架构的PolarDB。技术自主可控：近年来，国际关系环境也发生了变化，国内寻求技术自主可控的声音越来越大。相应地，国内也出现了很多专注于数据库产品和服务的公司。尤其是分布式数据库技术，在国际数据库领导者还没有全力投入作品的时候，国内很多企业已经参考开源的分布式技术方案，开发了自己的分布式数据库。因为没有作业可以抄，所以每个人的作业都大不相同。综上所述，金融行业迫切需要大数据量、高吞吐量和高可用，以及自主可控的需求，而大数据分布式技术方案已经得到外界的肯定，再加上领先的互联网行业解决方案方面，金融行业对国内优秀分布式数据库的需求持续增长。2、分布式数据库经历了哪些发展阶段？分布式数据库旨在解决大数据量、高吞吐量和高可用性问题，通过数据和计算分片提供水平扩展能力。但是，思路很清晰，实现起来却很复杂。为了更好的理解目前一些分布式数据库的实现原理，我们先将数据库分为三层：分析层、计算层、存储层。分布式实现就是解决这些层的实现问题。我把分布式数据库的发展分为三个阶段。1.读写分离为了解决中心化架构下单节点的计算性能问题，第一个解决方案就是读写分离模式。当时比较流行的是MySQL开源数据库。但是单个MySQL节点的处理性能容易出现瓶颈。MySQL主从复制架构下，主库可以读写，备库建议只读。因此，如果SQL解析层能够实现读写分离，那么主库的压力就会大大降低。图4.读写分离架构。这种架构流行了一段时间。这一阶段，MySQL也得到了飞速发展，开始挑战商业数据库的地位。商业数据库的用户也向IBM和Oracle提出了相关需求。在这种架构下，每个数据节点的数据都是满的。客户端或数据库中间件需要解决SQL读写分发的问题：如何保证数据的一致性，如何设计SQL的隔离级别，如何解决锁问题等等。分析层分析层需要实现读写分布。计算层实现了从库读取事务的接受，一定程度上分散了压力。存储层单个节点就是全量数据。通过数据库的主从复制技术实现数据同步。如果存储和计算分离，那么就实现了分布式存储。那么这个架构可以进一步解决存储层的压力问题。现在最典型的就是阿里云的polardb。图5.阿里云polardb分布式存储阿里云的polardb实现远比简单的读写分离要丰富。首先，这是一个面向云的原生数据库，是一个软硬件一体化的解决方案。解析层实现读写分离和负载均衡。计算层扩展单节点性能和扩展读取性能。存储层为分布式存储，分片方式对应用透明。通过FPGA、RDMA和其他硬件技术加速性能。我个人认为云数据库是未来的趋势，阿里polardb和腾讯tdsql会大放异彩。2、分布式中间件模式的读写分离仍然不能满足中国互联网庞大的用户体量。银行有数千万用户，互联网更是如此。一有促销活动，运维人员就心惊肉跳。仅仅依靠读写分离是无法满足这种集中并发的性能瓶颈的。那么能否将这些用户的交易数据分开，放在不同的节点上，让这些用户只能在相应的节点处理数据呢？这就是目前分布式的主流思路：数据分片。图6.数据库中间件图中的每个分片都可以是一组主从数据库，而不仅仅是一个物理节点。解析层实现SQL分布查询和结果聚合。该层需要保存数据分片的定义。支持跨节点分布式事务的能力较弱。这主要取决于分布式中间件的产品能力。计算层通过底层数据的分片，完全实现了负载分离。存储层数据分片后，完美解决了存储层的性能问题。这种架构的典型代表是阿里独创的TDDL数据库中间件产品和开源的数据库中间件Mycat。阿里的TDDL数据库中间件已经演化为现在的DRDS集群。首先我们来看一下Mycat的解决方案。图7.Mycat数据库中间件Mycat数据库中间件设置在应用程序和底层数据库之间。应用SQL会被解析、转换并路由到底层多数据库主备集群。此解决方案不需要对底层数据库进行任何更改。但是，支持复杂SQL的能力有限。使用此体系结构可以避免分布式事务。我们来看看阿里云的DRDS解决方案。DRDS虽然是中间件模型，但是现在介绍的解决方案更像是一个完整的分布式集群数据库。DRDS是分布式中间件，底层是RDS数据库集群（mysql）。RDS数据库服务是阿里云提供的关系型数据库服务的统称，主要是MySQL。DRDS通过两阶段提交实现分布式事务。图8阿里云DRDS如果有分布式事务，这种架构下最好在应用层解决。在这方面，我认为最好的是招商银行。招商银行一开始就把分布式事务和分片的作用放在了业务应用开发层面，不需要依赖底层数据库，实现分库分表。3、分布式集群模式的中间件模式实际上是和数据库引擎分离的。分布式中间件如果把中间件和底层数据库结合起来，作为一个产品开发使用，这就是现在的分布式集群数据库。观察了国内各个厂商的分布式数据库的实现，基本浓缩成如下示意图。图9分布式数据库集群协调节点：这是分布式数据库接受用户请求和返回数据的处理节点，通常以全活方式部署在多个物理节点上。协调节点之间的事务控制通过请求全局管理节点来获取全局事务信息或锁信息。协调节点的SQL会被编译执行，并调用对应的数据节点。数据节点：实际存储数据的地方。从协调节点导入的数据通过分片或复制的方式存储在数据节点中。数据节点通常只需要响应来自协调节点的调用。数据节点通过一主多备的模式提高数据可用性。备节点一般不提供读服务。全局管理节点：分布式数据库的核心，是区别于分布式中间件解决方案的关键部件。全局管理节点用于全局事务控制、元数据管理等，这些需要全局控制的功能可能会拆分成多个组件进行部署，这也是不同分布式数据库集群的根本区别。集群管理节点：这是数据库集群高可用的保证。用于全局监控数据库各组件的状态，并根据状态变化自动响应。集群管理节点控制整个集群中组件的切换和维护。上述逻辑节点可以混合部署在物理节点上，再加上数据中心的概念。可以跨多个中心部署集群，实现数据中心级容灾。国内的分布式数据库gaussT、TIDB、glodendb、sequoiadb、antdb等都是这样的架构。我们来看两个典型的本地化数据案例。与大多数分布式数据库解决方案不同，它们的数据库引擎不基于MySQL。首先是华为的高斯数据库gaussT。图10.华为的gaussT数据库这是华为官方的Gaussian数据库。其中etcd和CM是集群管理器，用于选择和操作整个集群。其中，ETCD存储集群的整体状态信息，基于Paxos协议保证可用性。CN是接受用户请求的协调节点，负责数据和SQL的分发和聚合。CN是多活的，client通过负载均衡的方式连接到CN。GTS是全球交易管理节点，只处理交易号请求，有缓存机制，相对处理性能较高。DN是一个数据节点，一主多备的模式保证了高可用。集群内部建表有两种方式，一种是选择分布键的分片数据表，另一种是全局同步复制的复制表。从Gaussian数据库的架构上来说，它是典型传统关系型数据库的升华版：全面支持分布式事务，集群作为数据库的方式更加人性化。说到分布式数据库，还应该提到TIDB。TIDB是PingCAP推出的开源分布式数据库。在众多分布式数据库厂商中，TIDB是一个备选方案。它找到了一条新路，专注于先进的数据库架构和良好的开源生态。图11.TIDB数据库在TIDB的架构图中，TiDBCluster是协调节点，接受请求，用于SQL的解析和转发。TiKV是一个存储数据的数据节点。与其他分布式数据库不同，TIDB采用分布式KV存储引擎。TIDB的数据分布也不同于其他必须指定分区键分片规则的分布式数据库。它实现了基于Region级别的Raft复制，也可以根据负载情况进行合并和拆分。这个特性是其他分布式数据库无法实现的。PDCluster相当于一个全局事务管理器。图中没有标注集群管理器。其实里面的每一个集群都有对应的集群服务。三种分布式方案介绍的差不多了，最后来看看中兴Goldendb。图12.GoldenDB的三种部署形式ZTEGoldendb集成了所有三种部署形式。No-Sharding是单机部署，一主多备模式，提供读写分离负载方案。Sharding集群是一种中间件部署方式，计算节点做转发，不支持分布式事务。DistributeTransaction集群加入了GTM全局事务管理器来支持分布式事务。4、分布式数据库测试经验我们介绍了那么多分布式数据库架构，也测试了很多数据库产品。下面是银行测试分布式过程的一些经验：1.对于单点数据的增删改查，大家的表现都很好，极度瓶颈一般出现在全局事务管理的环节。因此，这部分的性能差异就在于对这个全局事务的处理。这也决定了分布式数据库的性能上限。2.对于需要跨节点访问数据的分布式事务，大家的表现都不是很好。事实上，分布式事务对于分布式数据库来说还是有很大挑战的。对于使用分布式数据库的业务，建议减少分布式事务，不要将分布式数据库作为混合负载使用。特别是对于具有不同分布键的大型表关联，需要几分钟才能关闭协调节点。这部分技术更适合面向数据仓库的MPP数据库。如果把MPP数据库的这部分能力集成到分布式数据库中，那么这个分布式数据库真的很强大，可以从容应对HTAP。3、使用分布式数据库时，一定要注意分布键。无论是sharding还是replication，都需要业务开发人员从自己的业务逻辑出发，合理设置。一旦选择不好，分布式数据库的性能还不如单节点的。4、分布式数据库数据再分布，即横向扩展，是一个痛点。基本上所有分布式数据库都存在问题，无论是在操作模式还是性能影响方面。也许使用自动分布式可伸缩存储引擎是最终的解决方案。5、分布式数据库集群组件较多，管理相对复杂。每个组件都有自己的日志，可能存在性能瓶颈。分布式数据库环境下运维管理成本相对较高。3、传统的数据库运维岗位面临哪些挑战？分布式数据库的应用解决了传统数据库的性能扩展问题的同时，也给运维人员带来了挑战。过去，一套标准就可以运维传统的数据库，设置参数和规则，做应急防护。现在分布式数据库多了，不仅仅是数据库产品多了这么简单，而是数据库的使用方式多了。1.分布式数据库管理还有什么？统一数据视图：分布式数据库数据碎片化后，运维人员需要解决数据透视问题。哪些表是分片表，哪些表是复制表？如果您需要将数据导出或同步到其他系统，您应该如何使用此解决方案？一张表分为多少部分，整体数据量是多少？如果选择分布式，成熟的数据库产品还可以，这些部分都有产品级的解决方案。中间件式的分发就更难了。对于用户来说，如果集群中的数据可以像数据库一样操作，那就再理想不过了。大量节点的管理：选择分布式就是选择水平扩展。相应的运维节点数量将出现爆发式增长。这运维力一下子就上去了。幸运的是，不会有太多的分布式系统。现在这些节点不仅需要单独监控和管理，还需要对节点的角色进行管理。容量管理：这里的容量管理包括性能和数据两个方面。在分布式环境中，我们必须注意负载分配的问题。因为从根本上说，分布式就是为解决性能负载而生的。运维人员需要检测负载是否均衡，是否符合预期。如果有问题，需要从数据分布和业务行为的角度去分析。这是比较复杂和困难的。另一方面，分布式数据库最怕数据倾斜。严重的数据倾斜会导致性能瓶颈和容量瓶颈。发生倾斜后如何重新分配数据也是一个难题。数据一致性：分布式数据库的数据一致性可能会被用户忽略。因为这种问题在中心化数据库中很少发生。但是分布式数据库中的分布式事务基本都是通过两阶段提交来实现的。如果出现问题，可能会有提交残留。因此，用户需要定期检查数据库中是否存在二阶段提交残留，并定期进行数据比对。变更管理：分布式环境中的变更问题也需要注意。节点多了，数据库拆了，变化有全局维度和单点维度。如何统一修改，保证集群内所有机器都完成，没有任何遗漏？所有节点都改变了吗？是否可以通过定时参数比对和点对点的方式提示不同参数的节点？容灾方案：分布式数据库的容灾方案应该怎么做？两地三中心用什么方法？异构数据库的数据同步方案有哪些？数据迁移解决方案如何？有许多成熟且经过验证的解决方案可用于单节点数据库的情况。但是在分布式环境下，只能说是和厂商一起成长。多租户管理：多租户管理是分布式数据库环境中需要解决的重要功能。运维人员需要使用相应的产品方案，在运维过程中关注租户的容量和性能需求，对数据库进行相应的调整。2、如何管理分布式数据库分布式数据库作为一种新技术，并不是从成熟的商业数据库中诞生的，所以还有很多粗糙的地方。金融行业的用户尤其被传统商业数据库“宠坏”了。当他们第一次接触新的数据库时，他们会有一种碰壁的感觉。可就算是硬骨头，也还是得啃。控制应用场景：分布式不是万能的，它是针对特殊场景的数据库产品。只有匹配的交易才能向上迁移。如果不想给自己添麻烦，那就别理会分布式数据库了。这就要求运维人员不仅要看产品，还要和业务人员、开发人员紧密合作。从业务分片的角度管理数据库。因此，使用分布式数据库必须定义一个使用场景规范。统一管理平台：分布式数据库数据分片后，运维人员需要了解数据的整体规划是什么样的，数据分片规则，复制方案，同步方案等。分布式数据库集群的用户可能有更容易的时间，因为这些产品可能有相应的生产级解决方案。但是，使用分布式中间件的用户，对于如何随时查询和透视数据表之间的关系，需要另辟蹊径。不管用什么方法，这些都是分布式数据库运维需要做好的事情。因此，运维人员需要建立数据管理平台。在平台上查看和操作分布式数据库集群状态，管理数据库用户、权限、分布规则、配置下发、配置对比、查看日志、分析等各项管理功能。最好还包括多租户管理。智能监控平台：引入分布式数据库后，运维人员需要监控分布式数据库节点的状态和各节点的性能。首先要解决的问题是将新数据库接入监控告警平台。原本适用于单机数据库的各种监控，需要适配集群数据库。那么，更进一步，运维人员还需要借助智能运维，实现对分布式数据库的细粒度监控。智能监控平台需要分析发现分布式数据库负载不均衡、异常节点行为等问题，然后智能显示受故障影响的链条。智能监控平台还可以分析预测性能和容量趋势，提前预警性能和容量告警。容量管理：这个主题单独列出，因为它非常重要。必须要有监控数据偏斜和负载偏斜的方法，需要在管理平台做好负载重分配和数据重分配功能。分布式数据库一般支持三种数据分片方式：hash、range、list。如果出现数据倾斜问题，运维人员需要排查造成倾斜的原因，并使用现有的方法尝试继续打散数据。因此，在容量管理方面，运维人员需要与业务、开发人员密切沟通，了解数据的业务信息，获取业务增长预期，才能做好性能和容量规划。变更发布：通过统一管理平台实现数据库的参数变更。但是，如果管理平台不具备集成功能，则还必须借助自动化发布平台进行更改。尤其是在多数据中心容灾的情况下，人为的改动很容易被遗漏。最好推出DevOps平台，将分布式数据库的变化整合到平台中。通过这些管理平台和工具的建立，数据库运维人员从忙于解决各种问题的困境中解脱出来，成长为数据架构师。DBA前向连接业务场景，后向选择合适的数据库技术，基于标准化、自动化的部署和维护方式保障业务的稳定运行。4、未来数据库和数据库运维将走向何方？我们正处在一个数据库技术爆炸的时代。近年来，NoSQL数据库、NewSQL数据库、时序数据库、图数据库、分布式数据库、超融合数据库等相关技术百花齐放，国产数据库也发展势头强劲。那么下一代主流数据库是什么样子的呢？运维模式未来会发生哪些变化？云数据库：系统上云成为近几年的热门话题。各大厂商也都推出了自己的云数据库。云数据库将成为未来的趋势。数据库服务将进一步标准化输出。无论是私有云还是公共云，用户使用数据库的方式都在发生变化。分布式数据库和超融合数据库的强大性能也适合云环境下的多租户使用。细分领域：数据库应用领域也会越来越细分。可能现在我们还是希望有一个全能的数据库，可以面对HTAP场景，但是未来数据库功能会更加差异化。尤其是通过数据库云，您可以轻松申请不同功能的数据库，解决各种业务场景。智能运维：由于数据库提供云部署云服务，数据库运维必须走向智能运维。通过机器学习智能算法监控系统运行状态，提供基于数据性能的决策、自动修复、自动扩容。最后想象一个场景，用户申请了一个云数据库，运行一段时间后，智能运维机器人告诉用户数据库最近发生了什么，一共进行了几次自动调优，几次异常自动修复等，总损失节省了多少时间。根据用户的使用场景，建议用户扩容或购买更合适的数据库服务，有助于提高一定比例的性能。以上是笔者认为近期会发生的变化。你怎么认为？【作者简介】孔再华，IBM认证高级DBA，SAP认证BASIS，具有丰富的数据库环境问题诊断和性能调优经验。有丰富的同城双活数据库、集群、多分区、分布式项目实施经验。目前就职于中国民生银行科技部，致力于数据库同城双活架构建设、数据库分布式架构建设和数据库智能运维（AIOps）。对于如何将AI技术应用到运维领域，他有着浓厚的兴趣和创新热情。
