飞道的博客

巨杉TechDay回顾 | 微服务下的分布式数据库架构演进与实践

285人阅读  评论(0)

内容整理自2019年6月2日巨杉TechDay技术沙龙活动。

演讲概述

当前,微服务架构已经成为应用架构转型的主流方向。本次分享,将深入解析在应用架构微服务化的趋势下,底层数据架构如何演进,分布式数据库如何适应微服务需求等。同时,还将介绍分布式数据库在金融行业的架构升级实践。点击链接获取演讲视频

演讲实录

 

大家好,我是Danny,首先简单的介绍一下我自己,我本人有近20年的数据库引擎开发经验,现在在巨杉数据库北美研发实验室。今天我们的分享分四个议题,第一个是云架构与微服务,然后包括分布式数据库整个的发展历程。接下来我们介绍一下在支持微服务架构下,如何构建数据平台的通用实践,最后会跟大家分享一下巨杉数据平台是如何实践的。

>>云化架构与微服务

 

首先,我的理解中,云架构基本的要素是通过共享与抽象来提供服务。那么,共享的这个概念,是指通过平台来降低应用成本和使用成本。为什么会达到这个效果呢?首先是从各种不同的资源来进行共享的,因为大家知道,不管是怎么应用计算的时候,它不是100%使用所有的资源,这些资源包括机器资源、场地资源、应用中心等各种资源,对于云架构来说,各种应用在使用共享资源的时候,有的时候只有30%,有的时候有50%,所以总体来说是降低成本的。

第二个是加快个人使用的部署周期,数据平台、各种平台的构建时间,通过使用的情况看,可以加快部署的周期。

第三点可以通过接口避免重复工作,云平台有各种各样的接口,不用再重复的造车、造轮子,这样可以极大的减少部署的时间和开发资源。

 

今天的分享,我们主要关注在微服务架构下,如何提供数据服务。

谈到微服务,大家都有不同的定义和理解,但我的理解是,微服务会在设计方面将大应用拆分成多个小应用(也就是微服务)。这些微服务互相之间是独立的,通过服务接口对上下层实现交互集成,在功能上非常轻量,还可以通过标准的接口,实现功能扩展,提供对外服务的支持。

在部署方面,应用微服务的体系,更加强调高敏捷和弹性伸缩。

此外,每一个微服务都有自己的访问,这也意味着每个微服务可以继续拓展,并且相互之间的资源是隔离的,这样也可以最大程度保证数据的安全和可靠。

 

>>分布式数据库

 

在微服务的驱动下,数据管理方式将发生巨大的变化,这时候分布式数据库就成为了支撑微服务的重要基础了。

关于,分布式数据库的发展历程。

· 数据库最先开始发展是从上世纪60年代开始,是最简单的传统层次型文件数据库。

· 数据库管理系统大规模开始商用是在上世纪80年代,IBM出现了之后。然而当整个数据库系统越来越大的时候,对性能的要求也越来越高,厂商只能从单机上面进行优化,来提高整体的性能。

· 后来大家发现,性能提升所需要的成本越来越高,这是一个趋势,只能从架构上去入手解决。到了2010年,分布式数据库出现了,这方面的产品也越来越多,这就是数据库的进化史。

我们先看看传统数据库的架构图。它有几个关键的组件,通常会有一个客户端连接层,会有一个解析层,会根据数据库查询产生访问计划,并下发这些访问。在上层的分布式交易这块,实际上也并不只是存储,还有日志的分析,中间这三个层面被统称为存储层。

在右边是一些共享的架构,包括loading等等,会通过一些API进行访问。可以看到在传统数据库架构中,很多组件都是强耦合的,也就是说大家更希望这些组件能加强在性能上的优势。

对比传统关系型数据库,我们来看看分布式数据库的架构。

在过去20年当中,数据库在有两种通用的设计思路,shared nothing和shared everything,Shared Everything:更加关注持久化的共享,会在系统里挂上一些共享盘,把DGSS和DATA放在一块,通过高速网络相连,给上面的系统提供数据服务。它上面的各个单元保存的数据是相同的,好处是实现起来更为简单。

Shared Nothing:另一种Shared nothing的架构,会将所有数据打散,分布在不同的节点里,每一个节点拥有的只是部分的数据,并通过协调节点将所有数据协调起来,进行数据分发和汇总,为上层提供数据服务,这就是通常的分布式数据库的架构。

 

接下来我们看看如何将微服务和数据平台的构建整合起来。在说微服务之前,我想先提一下数据平台。数据架构,发展到现在,数据库已经不仅仅是一个数据库,而是一个上升到平台层面的数据服务平台。

· 不管是传统数据库还是新一代数据库平台,它都需要提供高效的数据访问,而且数据要保持一致性,也要24小时提供不间断的数据服务。也就是提供持久、高效、安全和数据一致性保证,这几个是新一代数据库平台必不可缺的共同特点。

· 新一代数据库平台通常能提供结构化、半结构化和非结构化数据的服务。这也是当前新一代数据库常提到的“多模”(multimodel)的能力。

· 从成本上来说,新一代数据库平台只需要通用的硬件,它没有硬件的要求,非常适合部署在云平台上。

· 从应用层面来说,数据平台可以让应用更为灵活地使用数据,因为它本身的数据也是一个灵活的部署。这是数据服务平台和传统数据库的区别。

 

>>微服务与分布式数据库的关系

微服务本身就提出了几个要求,

首先数据库的设计理念需要迎合微服务,包括提供弹性scaling的能力,以及对服务的解耦。

其次数据平台本身需要适合部署在云上或者通用的环境上,摆脱对特定硬件的依赖,并且通过通用的接口进行访问。

同时还有一个最大的特点,数据库平台需要满足多应用的需求,包括新应用和已有应用的兼容,以及不同用户的使用习惯、不同技术生态的需求。

在架构方面,第一点是存储和计算分离,计算层采用实例化的架构,存储层采用分布式架构,这样可以同时实现计算和存储能力的弹性扩展。

第二个特点是数据处理的多模,什么叫数据多模? 格式多样,指的是数据库可以支持字符串、BSON、JSON以及文件甚至Image、video等等类型的数据存储。

处理方式的多模,指的是数据库平台可以使用多种方式访问数据,包括SQL,Spark以及其他API等方式访问。

第三,微服务对数据库的性能监控和拓展都提出了很高的要求,甚至还要求数据库本身具有自行修复故障,自行维护拓展的能力。

这些都是为微服务构建的数据平台,在设计之初需要考虑的问题。

那么数据平台如何对接微服务架构呢?

第一,平台需要提供适配不同的应用的接口,包括多种类型的驱动和连接器。

第二,对接微应用,提供数据层面的持久化和弹性扩展能力。持久化是为了数据不丢失,而弹性扩展则是为了适应应用快速增长的需求。

最后一点就是,数据平台本身也是一个抽象的数据层,会屏蔽下层,而对上层是一个解耦的过程。因此,用户不需要关心顶层存储如何共走,他只需要看到访问接口就可以将应用接入。

在架构上,微服务的架构需要支持数据的安全和持久,注重动态弹性扩展,无单点故障,能够提供24小时不间断的访问。

 

>>巨杉数据库的架构实践

 

一直以来,数据库方面在针对大数据量情况出现了多种解决方案,而巨杉数据库采用的自然是原生分布式引擎的这一路线。

对比多种应用-数据对接的方式,在垂直分库方式下,每个引用都会带有一个自建的数据库,好处是实现起来很方便,而坏处就是数据互相之间没有关联能力,必须通过应用的二次加工,效率很低,管理起来也很复杂。

另一种常见的处理方式就是“分库分表”,分库分表方式通常通过中间件进行用户ID的路由分发,保证用户的一类操作设计的表在一个节点上完成,避免分布式事务的出现,所有跨节点操作只能通过中间件来保证一致性,这样给性能带来了瓶颈。

最后是近几年原生分布式的数据库,包括阿里和华为,它的原理是把数据表分散到不同的节点上面,减轻数据库的压力,数据库节点之间分担数据的承载压力。而分布式的引擎原生支持分布式的事务,这样就不存在中间件在分布过多节点之后的性能瓶颈。

 

我们接下来看看巨杉数据平台的整体架构,可以看到,第一个就是分布式的存储和处理,还有计算和存储的线下分离。计算存储分离,存储层可以实现弹性扩展,而计算层的各个SQL访问节点,不仅可以同时支持多种SQL访问方式,还可以实现计算实例的弹性扩展。

我们来看各个功能,最下层左边这些蓝色的节点,我们叫做数据存储区,是各个数据节点。如何实现数据的安全可靠?我们推荐每一个数据至少有2~3个副本,甚至更多,来保证数据不会丢失,并通过多分区将数据打散在不同的数据节点上。到了存储区这里,协调节点的作用是将数据打散,分散在各个数据节点上。

协调节点通过访问编目节点,就能知道哪些数据在哪一个分区,哪一些是读,哪一些是写。协调节点是完全独立的,能够承担所有的任务,可以单独地承担数据的访问分发和数据处理。

分布式数据库中,一个数据复制组(replica group),通常是采用“一主-多备”的高可用方式,那么在主节点进行读写操作的情况下,备节点可以同时支撑更大的读的访问,这样可以避免读和写的冲突,实现读写的分离。

而巨杉数据库在分布式集群中,还可以采用逻辑“域”的概念。举个例子,冷热数据的分离,冷数据通常是一年以上的,它对数据的访问会相对的较低,所以我们放到慢一点的存储设备上面,可以达到成本更低的目的。对某些实时的强一制性交易场景,我们通常把它放在高速存储设备上,能够实现动态数据更新,这里也是实现了OLAP和OLTP场景的相结合。我们可以把数据进行分组来实现存储的方式。

 

这里我们可以通过一个样例,来介绍一下在双活环境下的数据一致性的保证,

· 微服务程序优先连接本机房Nginx服务,只有当本机房Nginx无法提供服务后,再去连接同城机房Nginx服务;

· Nginx服务只连接本机房MySQL服务,一个机房拥有多个MySQL服务,确保SQL服务高可用;

· 如果一个机房所有MySQL服务均停止服务,则该机房Nginx服务也会停止,微服务程序自动选择同城机房Nginx服务进行连接;

· MySQL优先连接本机房协调节点,避免请求在同城机房中交叉访问;

· 协调节点在执行写入操作时,自动路由数据库分区的主节点,执行操作;

· 协调节点在执行查询操作时,优先选择本机房数据节点进行访问,避免请求在同城机房中交叉访问;

 

数据库和数据平台监控是十分重要的工具组件,对于巨杉数据库,我们提供了丰富的可视化操作界面,同时也有完整的集群监控、数据库监控工具。在未来的版本中,我们会统一各个平台的监控,进行全面优化升级以满足客户的需求。

最后,我们做一个结束语,非常感谢大家来参加这次活动。巨杉数据库本身也吸引了国内外众多的数据库老司机的参与,我们愿意去倾听客户的声音,愿意去拥抱社区的各种活动。我们的宗旨是坚持自主研发,自己掌控未来。

关注巨杉数据库SequoiaDB公众号

回复“0602”即可下载完整PPT


转载:https://blog.csdn.net/SequoiaDB_Official/article/details/113753633
查看评论
* 以上用户言论只代表其个人观点,不代表本网站的观点或立场