我正在为解决方案设计一个微服务架构，该架构将跨越多个模块，这些模块可以根据并购进行单独工作或可插拔。 我的体系结构/基础数据定义问题在于以下几点：作为一个示例（不是真正的解决方案），让我们考虑使用以下模块将其视为预订管理的完整解决方案：
酒店预订模块
娱乐预订模块（各种活动：剧院，音乐表演等）
车辆预订模块
机票销售模块
每个模块都有自己的域：域的集成，规则和数据库，我试图在此服务/存储模型中解决的问题是如何分离服务总线中的公共部分并将其重用于所有模块但不创建单个数据模型，例如： 在所有这些模块中，我都会有一个用户群（还有其他共同点），有什么更好的方法为每个服务模块的模型提供唯一但独立的用户数据存储？
我考虑了以下选项：
1-具有服务总线来管理公共数据库中的用户，并且每个模块将直接通过数据库在其架构中引用用户的FK。 使用这种方法https://www.akadia.com/services/ora_references_constraint.html 但是，例如，在模式之间进行JOIN有什么影响？可以做到吗？
2-具有服务总线来管理公共数据库中的用户，并且将通过每个模块的服务复制数据，每个模块都有自己的用户群。 问题可能是同一解决方案中有多个用户群。
每个模块都有自己的服务和数据模型，我不想为所有模块创建单个存储模型。它不是一个包含多个部分的大型系统，而是具有多个独立但可插拔的系统的解决方案。
第一种选择似乎更好，但是我对现代建筑不满意。
您对此构架有何建议，NoSQL解决方案会更合适？
欢迎任何提示。
答案 0 :(得分：0)
如果您将酒店预订，娱乐预订，车辆预订模块和机票销售模块视为具有各自域的单个微服务，那么也许还有空间可以管理其他微服务？
如果是这样，那么尽管您必须注意微服务之间的通信方法，但选项1听起来是更好的选择。如果执行不当，则诸如REST over HTTP之类的同步调用会降低微服务的整体可用性。也许您可以考虑使用一种基于消息的异步通信方法来通过消息代理检索用户信息。
我不认为NoSQL数据库在这里会有所帮助，因为问题在于确定域的边界。