1.介绍

Microservices体系结构是不断地增长.它带来了很多好处,特别是相对于过时的单一架构。另一方面,在开发使用微服务的项目时,会遇到多种挑战。最重要的问题之一是数据库设计。关于数据设计,有两个关键问题。如何组织数据,存储在哪里?

在本教程中,我们将尝试回答这些问题。

2.数据库/服务

使用MicroServices架构时,有两个主要选项用于组织数据库:

  1. 每项服务数据库
  2. 共享数据库

在本节中,我们将描述第一个。

2.1.基本面

根据定义,在开发和部署方面,微服务应该是松散耦合的、可伸缩的,并且是独立的.因此,每个服务使用数据库是一种首选方法,因为它完全满足了这些需求。让我们看看它是怎样的:

这个想法很简单。每个微服务都有自己的数据存储(整个模式或表)。其他服务无法访问不属于它们的数据存储。这样的解决方案带来了很多好处。

首先,对单个数据库的更改不会影响其他服务。因此,应用程序中不存在单点故障。可以说,应用程序更多有弹性的

其次,单个数据存储更容易扩展.此外,域的数据被封装在微服务中。因此,更容易理解服务及其数据作为一个整体。这对于开发团队的新成员尤其重要。这将使他们花更少的时间和精力来完全理解他们所负责的领域。

最后,通过每个服务的数据库,我们能够使用多语言持久性。这意味着我们可以为不同的微服务使用不同的数据库技术。因此,一个服务可能使用SQL数据库,另一个服务可能使用SQL数据库NoSQL数据库。该特性允许根据服务需求和功能使用最高效的数据库。

2.2.缺点

尽管所有这些好处都有,但对每个服务方法的数据库存在一些严重的缺点和挑战。正如我们之前提到的,每个微服务只能访问直接自己的数据存储。因此,服务需要一种通信方法来交换数据。因此,每个服务必须提供清除API。

因此,在通信失败的情况下,需要一个故障保护机制.假设我们向服务A发送支付请求到服务B.服务等待响应执行适当的动作基础。在此期间,服务B脱机。当B在线回来时,我们需要处理情况并告知服务A关于结果。金宝搏官网188be的断路器机制可以帮助这里。

下一个重要问题是交易.微野营服务的跨越事务可能会对一致性和原子性产生负面影响。类似的缺点与复杂的查询有关。在多个数据存储上执行连接查询并没有简单的方法。

最后,在出现任何问题时,跨微服务的数据相关操作可能很难调试。

3.共享数据库

共享数据库被视为反模式。虽然,这是值得不值得的。重点是使用共享数据库时,微服务会失去核心属性:可伸缩性,弹性和独立性.因此,微服务很少使用共享数据库。

当共享数据库似乎是微服务项目的最佳选择时,我们应该重新考虑是否真的需要微服务。也许巨石是更好的选择。让我们看看共享数据库方法是什么样子的:

在微服务中使用共享数据库的用例并不常见。例如,将整体迁移到微服务时的临时状态。与每个服务相比,共享数据库的主要好处是事务管理。不需要将事务跨越服务。

此外,数据是完全受限的,并保留了适当的辐射。随后,冗余度降低。我们可以很容易地使用连接执行复杂的查询。

另一件重要的事情是不需要在微服务之间交换存储的数据。因此,API得到了简化,即使通信失败,也不存在数据和状态的一致性问题。但也有一些严重的缺点。

具有共享数据库的微服务很难扩展.更重要的是,数据库将是一个单点故障。与数据库相关的更改可能会影响多个服务。此外,微服务在开发和部署方面不会是独立的,因为它们连接和操作同一个数据库。

这种模式可以考虑以下情况:

  • 应该保留现有的数据存储
  • 不应该改变现有的数据层代码库
  • 事务对应用程序至关重要

4.数据相关的模式

在微服务体系结构中,有各种用于管理数据的模式。在本节中,我们将简要介绍一些基本的方法。

4.1.传奇模式

我们前面提到,跨微服务跨事务可能会有问题。简单地说,只有所有相关服务都成功地执行了它们自己的部分,事务才会成功。如果一个服务出现故障,整个事务都应该失败。此外,在这种情况下,已经完成其部分的服务应该回滚更改。

一般来说,这就是传奇模式的作用。传奇模式是表示单个分布式事务的本地事务序列吗.每个服务执行一个本地事务。如果本地事务成功结束,则会发布一个事件或消息,触发序列中的下一个本地事务。在失败的情况下,saga提供了回滚更改的补偿事务。

有两种类型的实现SAGA模式:

  • 业务流程——中央控制器(协调器)管理微服务之间的所有交互
  • 编舞-分散的技术广播事件

4.2.CQRS

CQRS(命令查询责任隔离)有助于实现另一个重要特性:从多个数据存储查询相关数据。此外,它通过分离关注点简化了业务逻辑的复杂性。此外,它有助于微服务的可伸缩性。

这个想法很简单。我们将数据层与业务逻辑层分离。此外,类只能写入数据库(命令)或从数据库读取(查询)。因此,一个类不能同时做到这两点。这种方法有很多好处。代码更清晰,更易于维护或扩展。不同的组件可以分别进行优化和开发,尤其重要的是,可以进行缩放。

随后,部件松散地耦合,并且可以在开发人员或团队之间有效地分裂工作。最后,分为组件的应用更易于测试。没有一个正确的方法来实现CQRS模式。实现可以基于领域、需求、框架、项目的实际状态等。CQRS通常与事件的采购模式。我们来描述一下。

4.3.事件的采购

许多现代应用程序出于各种目的都依赖于事件。例如,正如我们前面提到的,saga序列中的服务自动更新数据库并发布事件或消息。事件溯源利用应用程序事件。

事件源是一种通过持久化改变状态的事件来表示状态的技术.每当业务实体发生更改时,事件就会持久化到事件存储中。

顾名思义,事件站点是一个事件数据库。它可以是SQL、NoSQL或任何适合项目的方式。此外,事件存储可以充当消息代理。所有感兴趣的组件都订阅它。当事件持久化时,事件存储将信息传递给所有订阅者。发布事件是单个原子操作。因此,它提供了跨微服务的数据库操作的可靠性和原子性。

而且,它会创建一个完整的审计日志。在出现任何问题或bug时,很容易研究状态更改并最终恢复有效状态。因此,调试不那么复杂。此外,事件采购可以避免面向对象和关系数据之间的阻抗不匹配.总之,事件源可以在微服务体系结构或任何事件驱动的应用程序。

5.如何选择数据库?

在microservices中规划数据库设计的第一步是选择模型.我们已经提到了每个服务的数据库和共享数据库模型。此外,我们还考虑了它们的优缺点和常用用例。

第二步是选择对项目或服务最有效的特定数据库技术(或技术)。为此,我们需要考虑一些属性。

第一个重要参数是读性能。读性能可以是每秒操作的次数,也可以是获取查询的速度。与电子商务、客户关系管理(CRM)、银行软件相关的应用程序或服务通常会包含要求快速、频繁地获取数据的功能。

第二个重要的属性是写性能。它和前一个很相似。只是,在这种情况下,我们写入数据库,而不是从它读取。如果服务需要持久化大量数据,甚至存储大的blob,这可以是一个核心参数。

下一个是延迟。它是用户操作和服务器响应之间的延迟。这在与用户体验相关的组件中尤其重要。实时流媒体应用或实时游戏就是很好的例子。

另一个重要属性是资源效率。通常,消耗的资源越少越好。它可能会导致更快的执行,降低主机负载,最终的成本取决于平台。

最后但并非最不重要的是,我们应该考虑提供效率。通常,数据库如何影响微操作的开发,部署和测试。正如我们之前提到的,那些术语中微服务的独立性非常重要。

5.1。SQL与NoSQL.

通常,项目或服务需要考虑两种技术:SQL和NoSQL。基本上,它更复杂,特别是当它涉及到NoSQL时。也就是说,有很多NoSQL数据库实现。不过,在本文中,我们不会详细说明数据库的底层实现。让我们比较一下SQL和NoSQL。

呈现由QuickLaTeX.com

6.结论

在本文中,我们详细介绍了微服务体系结构中的数据库设计。正如我们所看到的,这是一个非常复杂的任务。所有的元素都应该经过仔细的规划,并适合于项目的需要,以最大限度地提高其效率。

客人
0注释
内联反馈
查看所有评论