database-design - 微服务架构和数据库设计

Question

我正在为一个解决方案设计一个微服务架构，该架构将跨越多个模块，这些模块可以单独工作，也可以根据采集进行插拔。我的架构/基础数据定义问题在于以下几点：仅作为示例（不是真正的解决方案），让我们将其视为具有以下模块的预订管理的完整解决方案：

酒店预订模块

娱乐预订模块（各种活动：剧院、音乐剧等）

车辆预约模块

机票销售模块

每个模块都有自己的域：域的集成、规则和数据库，我在此服务/存储建模中试图解决的问题是如何分离服务总线中的公共部分并将其重用于所有模块但不创建一个单一的数据模型，例如：在所有这些模块中，我将有一个用户群（会有其他共同点），有什么更好的方法来为每个服务模块的模型提供一个独特但独立的用户数据存储？

我考虑了以下选项：

1 - 有一个服务总线来管理公共数据库中的用户，每个模块都可以直接通过数据库在其模式中引用用户的 FK。使用这种方法https://www.akadia.com/services/ora_references_constraint.html 但是，例如在模式之间进行 JOIN 会产生什么影响？能让它变得不可能吗？

2 - 有一个服务总线来管理公共数据库中的用户，并通过每个模块的服务复制数据，每个模块都有自己的用户群。问题将是同一解决方案中的多个用户群。

每个模块都有自己的服务和数据模型，我不想为所有模块创建一个存储模型。它不是一个由多个部分组成的大型系统，它是一个具有多个独立但可插拔系统的解决方案。

第一个选项似乎更好，但我不喜欢考虑现代建筑。

你对这个架构有什么建议，NoSQL 解决方案会更合适？

欢迎任何提示。

标签： database-designarchitecture

Answer 1

如果您将酒店预订、娱乐预订、车辆预订模块和机票销售模块视为具有自己域的单个微服务，是否还有其他管理用户的微服务的空间？

如果是这样，那么选项 1 听起来是一个更好的选择，尽管您必须注意微服务之间的通信方法。如果处理不当，像 REST over HTTP 这样的同步调用会降低微服务的整体可用性。也许您可以考虑使用基于消息的异步通信方法来通过消息代理检索用户信息。

我认为 NoSQL 数据库在这里没有帮助，因为问题在于识别域的边界。