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

红太狼 2022-10-29 03:25 36阅读 0赞

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

**演讲概述**

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

**演讲实录**

![图片][22d4159f3af67e7400216ba0bef008ea.png]

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

**>>云化架构与微服务**

![图片][bac259c560966bd70732c430fe9e8f98.png]

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

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

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

![图片][02b419aacbfb0fd30bece826fb2b1ff8.png]

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

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

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

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

**>>分布式数据库**

![图片][f16ece2587a5fb7a16c8730bca9e80f9.png]

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

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

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

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

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

![图片][dd0323e2a96a4c7a0939ddde5f78fa51.png]

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

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

![图片][8b543df6a292efa7522d1a3b1b7c9568.png]

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

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

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

![图片][bbf20b1057f92b3280c7fca0f92ccb2e.png]

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

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

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

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

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

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

![图片][6627a19a05e3bca127dbf91c86c5bea6.png]

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

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

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

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

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

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

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

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

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

![图片][21dfcbbc13ee15dda03f08c32792a10f.png]

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

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

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

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

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

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

![图片][454ace70e76720296c655fc1bab11193.png]

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

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

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

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

![图片][7ac3eb4ef8c34ea96332f5f4b7f70234.png]

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

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

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

![图片][4d316b8f9506b5e62cd9c8f35cc1f485.png]

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

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

![图片][a78ddee5cc1b626a850c00d6ba3b1113.png]

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

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

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

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

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

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

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

![图片][29cd8a67fc5c8c68d77a121042e08e23.png]

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

![图片][ff5b3aefff377775283df7f367473d7b.png]

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

**关注巨杉数据库SequoiaDB公众号**

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

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1NlcXVvaWFEQl9PZmZpY2lhbA_size_16_color_FFFFFF_t_70][]

[Link 1]: https://v.qq.com/x/page/g0882k5oizs.html
[22d4159f3af67e7400216ba0bef008ea.png]: /images/20221024/97e8cea14985457ead496c6956a0e4c2.png
[bac259c560966bd70732c430fe9e8f98.png]: /images/20221024/78949c5a25fb4d979d10fb612d50f14e.png
[02b419aacbfb0fd30bece826fb2b1ff8.png]: /images/20221024/1d777490705e423fbd82233c6a174794.png
[f16ece2587a5fb7a16c8730bca9e80f9.png]: /images/20221024/efbe98c089b64f988c22e2bf3c0120a6.png
[dd0323e2a96a4c7a0939ddde5f78fa51.png]: /images/20221024/db96a72414fc4bfd9d8b5e66ceec420c.png
[8b543df6a292efa7522d1a3b1b7c9568.png]: /images/20221024/7189429ce07848f7a1710efd0c251bd5.png
[bbf20b1057f92b3280c7fca0f92ccb2e.png]: /images/20221024/503dd9f7b57244c3b4d54ff6a495fafc.png
[6627a19a05e3bca127dbf91c86c5bea6.png]: /images/20221024/38a397f655a54fbd854fafb0a8242bc3.png
[21dfcbbc13ee15dda03f08c32792a10f.png]: /images/20221024/c4b5b9bec39b4707a493f55640528e17.png
[454ace70e76720296c655fc1bab11193.png]: /images/20221024/1d315d9132d1493b91938dbe3e4c11ee.png
[7ac3eb4ef8c34ea96332f5f4b7f70234.png]: /images/20221024/827c1e45fdd64c248623ea721344202a.png
[4d316b8f9506b5e62cd9c8f35cc1f485.png]: /images/20221024/724a292595e44980be9d42260bb616db.png
[a78ddee5cc1b626a850c00d6ba3b1113.png]: /images/20221024/ecfdb12918ef455698f8081c74da6864.png
[29cd8a67fc5c8c68d77a121042e08e23.png]: /images/20221024/96116083558c49d8a7551f2d7338f65b.png
[ff5b3aefff377775283df7f367473d7b.png]: /images/20221024/0a802cfd953a49d88308cd65b0731a28.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1NlcXVvaWFEQl9PZmZpY2lhbA_size_16_color_FFFFFF_t_70]: /images/20221024/431bfedafd5c495a93d8ca0e90ff5931.png