用户和身份验证的分布式数据库设计架构用例

Posted 2023-02-26

【中文标题】用户和身份验证的分布式数据库设计架构用例

【英文标题】：Distributed Database Design Architecture Use Case for Users & Authentication

【发布时间】：2018-09-10 02:19:15

【问题描述】：

我现在正在尝试以分布式方式为我的面向微服务的应用程序设计数据库。我的申请与大学管理有关。我有不同的大学说 A、B、C。每所大学都有单独的用户来使用他们的业务数据。现在我计划为不同的大学设计不同的数据库来存储他们的用户数据。因此，每所大学都有自己的数据库供用户使用，另外还有一个数据库来管理他们的申请表。如果我有 2 所大学，那么我有 2 个用户详细信息数据库和其他 2 个用于应用程序表的数据库。

我的困惑是，当我搜索数据库设计时，我只看到保留一个通用数据库来存储所有用户的方法（这里为所有大学的所有用户提供一个数据库）。所以每个用户都混合在一个数据库中。

如果我为每所大学遵循单独的数据库，是否可以支持分布式数据库架构模式和面向微服务的标准？或者我是否需要为所有用户保留一个数据库？

如何找出适合微服务/分布式数据库设计模式的方法？

【参考方案1】：

实际上可能有多种解决方案，没有一种解决方案是最好的，最好的解决方案是适合您产品要求的解决方案。

我认为最好为每个客户（大学）使用单独的数据库，以保持数据始终隔离，即使发生错误。此外，随着时间的推移，数据库可能会变得如此庞大，以至于在配置/管理单独的备份、清理单个客户端等方面可能会出现问题。

现在有了单独的数据库，管理跨数据库的分布式事务就会面临挑战，因为您不知道哪个部分会失败。为了管理它，您可能必须在所有微服务中实现消息/事件驱动机制并确保一致性。

关于消息/事件机制，这里是一个简单的用例场景，假设有两个服务“A”（用户注册）和“B”（电子邮件服务）

“A”临时注册用户，发布确认邮件发送事件。 消息发送到消息代理 消息被“B”接收。 确认电子邮件已发送给用户。 用户向“B”确认电子邮件 “B”向代理发布用户确认事件 “A”收到确认事件，流程完成。

以上是最好的情况，即使经纪人本身也可能在两者之间发生问题。 如果你认为你需要这个，你必须深入研究它。

一些可能有帮助的链接。

http://how-to-implement-a-microservice-event-driven-architecture-with-spring-cloud-stre

A Guide to Transactions Across Microservices

【讨论】：

好的..谢谢您的回复。我很高兴。你能说说你为什么说“所有微服务中的消息/事件驱动机制”吗？为此我需要探索什么？

没有问题。我的意思是，保持消息代理（例如活动 mq）保持在适当的位置，并确保消息传播到接收器服务，即使有什么东西坏了。请参阅我扩展的另一个答案，因为这里的评论太长了。

好的。谢谢。

【参考方案2】：

我不认为这是一个有效的设计，每个客户端使用一个数据库是一种多租户架构实践，而每个微服务的数据库是一种微服务架构实践。你把事情搞混了。

如果你将使用微服务架构，你最好将其设计为有界上下文，每个上下文都有自己的数据库来实现微服务的主要规则自治