【问题标题】:Databse design in Microservices微服务中的数据库设计
【发布时间】:2021-11-17 15:56:54
【问题描述】:

我计划将一个单体 ASP.Net MVC 应用程序迁移到微服务架构。

该应用程序在教育领域,下面是当前拥有的子模块,

系统管理员

学院管理员

候选人/学生门户

辅导员/教师门户

课程设置(可由辅导员或学院管理员完成)

考试门户

报告门户 [新]

视频会议门户 [新]

为了实现微服务架构,我如下图打破现有系统,为每个模块创建DB。

这里我遇到了一个问题,比如考试数据库目前与课程和主题等有一些关系。

Course 和 Subject 相关表移到另一个 DB 中,我该如何维护 Exam DB 中的关系和数据?

我是否应该在考试数据库中创建课程和主题表的副本,并在原始数据库中插入新数据时填充它们(使用事件 Que)?

或者是否有任何其他技术可以以最少的更改和努力实现这一目标。

还有我如何维护不同数据库之间的事务。

【问题讨论】:

标签: database microservices


【解决方案1】:

每个服务的数据库

  • 为每个服务使用一个数据库有以下好处:

有助于确保服务松散耦合。对一项服务的数据库的更改不会影响任何其他服务。

每个服务都可以使用最适合其需求的数据库类型。例如,进行文本搜索的服务可以使用 ElasticSearch。操纵社交图谱的服务可以使用 Neo4j。

  • 为每个服务使用一个数据库有以下缺点:

实现跨多个服务的业务事务并不简单。由于 CAP 定理,最好避免分布式事务。此外,许多现代 (NoSQL) 数据库不支持它们。

实现连接现在位于多个数据库中的数据的查询具有挑战性。

管理多个 SQL 和 NoSQL 数据库的复杂性

  • 实现跨服务的事务和查询有多种模式/解决方案:

  • 实现跨服务的事务:

使用 Saga 模式。

  • 实现跨服务的查询:

API 组合 - 应用程序执行连接而不是数据库。例如,服务(或 API 网关)可以通过首先从客户服务中检索客户,然后查询订单服务以返回客户的最新订单来检索客户及其订单。

命令查询职责分离 (CQRS) - 维护一个或多个包含来自多个服务的数据的物化视图。视图由订阅每个服务在更新其数据时发布的事件的服务保存。例如,在线商店可以实现一个查询,通过维护一个连接客户和订单的视图来查找特定地区的客户及其最近的订单。该视图由订阅客户和订单事件的服务更新。

阅读更多here

共享数据库

  • 这种模式的好处是:

开发人员使用熟悉且直接的 ACID 事务来强制数据一致性

单一数据库操作更简单

  • 这种模式的缺点是:

开发时间耦合 - 例如,开发 OrderService 的开发人员需要与访问相同表的其他服务的开发人员协调架构更改。这种耦合和额外的协调会减慢开发速度。

运行时耦合 - 因为所有服务都访问同一个数据库,所以它们可能会相互干扰。例如,如果长时间运行的 CustomerService 事务持有 ORDER 表的锁,那么 OrderService 将被阻塞。

单个数据库可能无法满足所有服务的数据存储和访问要求。

阅读更多here

附加必读:CQRS & API Composition

【讨论】:

  • "...由于 CAP 定理,最好避免分布式事务..." -- 不是必须的。仅当您需要极致性能时才适用。
猜你喜欢
  • 2016-12-13
  • 1970-01-01
  • 2019-10-08
  • 2017-09-11
  • 1970-01-01
  • 2018-02-27
  • 2019-08-11
  • 1970-01-01
相关资源
最近更新 更多