《分布式架构究竟给传统数据库运维带来的主要变化》由会员分享，可在线阅读，更多相关《分布式架构究竟给传统数据库运维带来的主要变化（25页珍藏版）》请在金锄头文库上搜索。
1、 并不简单！分布式架构究竟给传统数据库运维带来哪些变化？ 【摘要】分布式架构可能是近几年最火的话题。从集中式、 SOA 到分布式架构，本文回顾了这些年金融行业经历的架构演变；结合当下一些较典型的分布式数据库的实现原理，分析了分布式数据库的三个发展阶段。分布式数据库的应用解决了传统数据库性能扩展问题的同时，也给运维人员带来了挑战。那么，分布式数据库的管理究竟多了些什么？如何管理好？未来数据库和数据库运维又将去往何方？读过本文，你可以找到答案。金融行业这些年经历了怎样的架构演变？集中式架构分布式架构可能是近几年最火的话题，与之相对的则是集中式架构，后者是传统金融行业如银行最常见的部署架构。在“去I
2、OE”之前，各大银行的目标还停留在将集中式单点做强做大，不少银行采用IBM的主机系统就是鲜明的例子。数据库服务器更是如此，通常都是采用最好的机器。近几年，随着银行业务增长，互联网行业爆发，用户行为模式发生变化，集中式架构的系统面临很大的挑战。问题主要体现在扩展性和可用性这两方面：1.扩展性集中式架构的横向水平扩展能力非常低。面对性能不足，用户能做的就是加CPU、加内存、换存储、换机器等方式。2.可用性集中式架构的服务能力依赖高性能的主机。然而一旦主机出现故障，上面的服务就会受到影响。应对这个问题的方案就是搭建高可用架构。每一个环节都需要考虑冗余和HA。集中式架构下这几乎是最好的方式了。然而无论
3、哪个环节出故障，影响的都是全局服务。这种架构下的数据库也是通过做主备机冗余，HA服务自动管理切换满足高可用性。性能方面通常也是采用纵向扩容的方式。然而纵向扩容是有限制的。如果最强的主机都搞不定了怎么办？图 1. 集中式架构在集中式架构的数据库里面有一个例外，那就是MPP数据库。为了解决单节点数据库性能上限问题，某些数据库厂商开发出来MPP数据库。这种数据库算是一套集群，数据分布在这些集群的节点上，数据查询服务也能下推到这些节点完成。通过数据分发和功能分发，充分利用多节点的处理能力，这简直就是现在的分布式先驱。图 2. 集中式MPP架构图中协调节点CN并非是一个特殊组件，这可以是任何一个DN。不
4、过这类产品是面向OLAP的，是为了解决大查询问题，和现在分布式的方向并不一样。面向服务的架构（ SOA ）在互联网浪潮还没到来，分布式架构还未兴起的时候，为了解决单机性能瓶颈和全局服务可用性问题，最初的方案是业务拆分，也就是面向服务的架构（SOA）开始应用起来。纯粹的SOA其实是一个组件模型，它将应用程序的不同功能单元（称为服务）进行拆分，并通过这些服务之间定义良好的接口和协议联系起来。SOA架构曾经流行了一段时间，当然现在更火的是微服务模式。图 3. SOA 架构 当时有很多银行将自己的核心系统依照这个思路拆分，一个大系统拆成多个小系统或者是组件。优点是服务拆分之后实现了部分性能扩展。之所以
5、说是部分，是因为总有些核心服务是热点，没有办法做到拆分的。随之带来的缺点是系统调用链复杂程度增加了，数据在不同服务间的同步要求变多变复杂，然后系统和服务器的数量增多了。即便是采用了SOA的思路，还是没有彻底解决热点功能的性能问题和可用性问题：1. 没有实现核心功能的水平扩展，单个功能还是属于集中式架构部署。2. 没有实现数据水平拆分，解决不了大数据量的问题，反而带来了不同系统数据同步的复杂需求。分布式架构就在金融行业还在忙着为系统功能拆分改造，给新的小机打预算的同时，中国的互联网科技行业正在发生大的变革。大数据技术发展 ：第一大变革是各种分布式开源软件走向成熟并被充分利用。分布式存储、分布式计
6、算、分布式消息中间件引领大数据行业变革。这些分布式技术简单粗暴的解决了大数据量、高吞吐量和高可用性的难题。这些难题对业务系统和后台的数据库同样存在。看起来数据库走向分布式才是终极解决方案。然数据库行业的领先者们并没有像拥抱云技术那样去拥抱分布式数据库，反而给了众多初创数据库企业机会。互联网消费行为 ：另外一大变革是互联网行业改变了用户的消费行为。这几年网络运营商在提速降费，互联网移动设备出货量飙升，用户的消费习惯也大量从线下转移到线上。中国的人口红利在互联网产业发挥的 淋漓尽致 。对于金融行业来说，用户消费行为的变化带来的是对金融科技的挑战。交易量和数据量都在不停攀升高峰。尤其是网银，手机银行
7、等渠道类业务都将面临集中式架构性能瓶颈问题。其中最典型的就是阿里。阿里从2011年开始基于成本因素的考虑逐步去IOE，同时年年祭出了双十一成绩单。高帅富的小机替换成了PC机，Oracle数据库换成了开源 M y SQL 数据库，同时自研分布式中间件TDDL实现横向扩展。阿里通过堆砌廉价的PC机来支撑庞大的双十一促销业务，最终交出了交易量、峰值、金额等漂亮的成绩单。现在阿里的分布式中间件发展成了关系型数据库 DRDS。同时阿里还有面向金融领域全自研内核的OceanBase，主打云数据库存储计算分离架构的PolarDB。技术自主可控 ：这几年国际关系大环境也在发生变化，国内寻求自主可控的声音越来越
8、响。相应的国内也涌现出了很多主打数据库产品和服务的企业。尤其是分布式数据库技术，在国际数据库领头羊们还没有全力投入拿出作品的时候，国内很多企业借鉴开源分布式技术方案，研发出了自己的分布式数据库。因为没有作业可抄，所以大家做的作业也很不一样。综上所述，内有金融行业对于大数据量、高吞吐量和高可用性的迫切需求以及自主可控的需求，外有大数据分布式技术方案得到肯定，再加上互联网行业解决方案引领，金融行业对国内优秀的分布式数据库的需求持续走强。分布式数据库经历了哪几个发展阶段？分布式数据库是为了解决大数据量、高吞吐量和高可用性的问题，通过数据和计算分片的方式提供横向扩展能力。然而思路很明确，实现很复杂。为
9、了更清楚当前一些分布式数据库的实现原理，我们首先将要数据库分为三层来看待：解析层，计算层，存储层。而分布式的实现就是在解决这几层的实现问题。我把分布式数据库的发展分为三个阶段。读写分离为了解决集中式架构下的单节点计算性能问题，首先出现的方案是读写分离模式。当时 M y SQL 开源数据库比较流行。然而 M y SQL 单节点的处理性能很容易遇到瓶颈。 M y SQL 主从复制的架构下，主库可读写，然而备库建议只读。因此如果SQL解析层能够做到读写分离，那么主库的压力将会大大降低。图 4. 读写分离架构 这种架构曾经流行一段时间，这个阶段 M y SQL 发展势头也 很 迅猛，开始挑战商业数据库
10、的地位。商业数据库的用户也向IBM和Oracle等提出了相关的需求。这种架构下每个数据节点的数据是全量的。客户端或者是数据库中间件需要解决SQL的读写分发问题：如何保证数据一致性，如何设计SQL的隔离级别，如何解决锁问题等等。 解析层解析层需要实现读写分发。 计算层实现了从库接受读交易，一定程度分散了压力。 存储层单节点是全量数据。数据同步通过数据库的主从复制技术实现。如果存储计算分离，然后实现分布式存储。那么这种架构又可以进一步解决存储层的压力问题。现在最典型的是阿里云的polardb。图 5. 阿里云 polardb 分布式存储 阿里云的polardb实现远远比简单的读写分离要丰富的多。首
11、先这是个面向云的原生数据库，是属于软硬一体的解决方案。 解析层实现读写分离和负载均衡。 计算层纵向扩展单节点性能，横向扩展读性能。 存储层分布式存储，分片方式对应用透明。通过FPGA，RDMA等硬件技术加速性能。个人认为云数据库是未来的趋势，阿里polardb和腾讯tdsql会大放异彩。分布式中间件模式读写分离还是不能满足中国互联网庞大的用户体量。银行有几千万上亿的用户，互联网更多。但凡来个促销活动，运维人员就心惊肉跳。仅仅靠读写分离其实不能满足这种集中并发式的性能瓶颈。那么能不能将这些用户的交易数据分开放在不同的节点上，让这些用户只在对应的节点处理数据呢？这就是现在分布式的主流思路：数据分片
12、。图 6. 数据库中间件 图中的每个分片都可以是一套主从架构的数据库，不仅仅是一个物理节点。 解析层实现sql分发查询以及结果汇聚。数据分片的定义需要在这一层保存。对于跨节点的分布式事务支持能力很单薄。这个主要看分布式中间件的产品能力。 计算层通过底层数据的分片，计算层已经完全实现了负载分离。 存储层数据分片后，存储层的性能问题也完美解决。这种架构的典型代表是阿里最初的TDDL数据库中间件产品和开源数据库中间件 M ycat。阿里的TDDL数据库中间件已经演变成现在的DRDS集群。首先我们来看看 M ycat的解决方案。图 7. Mycat 数据库中间件Mycat数据库中间件架设在应用和底层数
13、据库之间。应用SQL会解析转化并路由到底层多个数据库主备集群里。这种方案不需要底层数据库做任何改动。然而支持复杂SQL的能力有限。使用这种架构要避免分布式事务。下面看看阿里云的DRDS解决方案。DRDS虽然是中间件模式，不过现在推出的解决方案更像是个完整的分布式集群数据库。DRDS是分布式中间件，底层是RDS数据库集群（mysql）。RDS数据库服务是阿里云提供的关系型数据库服务统称，主要是 MySQL 。DRDS通过两阶段提交来实现分布式事务。图 8. 阿里云 DRDS 如果存在分布式的事务，那么在这种架构下最好由应用层面去解决。这方面我觉得做的最好的是招商银行。招行一开始就将分布式事务和分
14、片的角色都放在业务应用开发层面，因此不需要依赖底层数据库来实现分库分表。分布式集群模式中间件模式其实还是和数据库引擎脱离的。分布式中间件如果将中间件和底层数据库揉在一起，当做一个产品去开发使用，这就是现在的分布式集群数据库。我观察了国内各家厂商分布式数据库的实现，基本浓缩成下面这张示意图。图 9. 分布式数据库集群 协调节点 ：这是分布式数据库接受用户请求和返回数据的处理节点，通常以多活的模式部署在多个物理节点上。协调节点之间的事务控制通过向全局管理节点请求，获取全局事务信息或者锁信息。协调节点的SQL会编译执行，调取对应的数据节点。数据节点 ：真正存放数据的地方。从协调节点导入的数据通过分片
15、或者复制的方式存放在数据节点里面。数据节点通常只需要响应协调节点的调取。数据节点通过一主多备的模式提高数据可用性。备节点一般不提供读取服务。全局管理节点 ：分布式数据库的核心，也是区别于分布式中间件方案的关键组件。全局管理节点用于全局事务控制 、 元数据管理等。这些需要全局控制的功能可能会被拆分成多个组件来部署，这也是不同分布式数据库集群的根本差异。集群管理节点 ：这是数据库集群高可用性的保证。用于全局监控数据库各项组件的状态，并且依据状态变化自动响应。集群管理节点控制着整个集群里组件的切换和维护。上述逻辑节点可以在物理节点上混部署，加上数据中心的概念。集群可以跨多中心部署实现数据中心级的容灾
16、。国内现在比较突出分布式数据库gaussT、TIDB、glodendb、sequoiadb、antdb等都是这类架构。下面看两个典型的国产化数据案例，与大部分分布式数据库的解决方案不一样的是，他们的数据库引擎不是基于 M y SQL 。第一个是华为的高斯数据库gaussT。图 10. 华为 gaussT 数据库 这是华为官方的高斯数据库。其中ETCD和CM是集群管理器，用来选择和操作整个集群。其中 ETCD 存放集群整体状态信息，基于paxos协议保证可用性。CN是接受用户请求的协调节点，负责数据和SQL的分发和汇总。CN多活，客户端通过负载均衡模式连接CN。GTS是全局事务管理节点，仅处理事务
