微服务数据库设计问题答案

【问题标题】：Microservices db design issues微服务数据库设计问题
【发布时间】：2018-10-14 22:49:57
【问题描述】：

我刚刚开始将我的项目拆分为小型微服务。我有一个处理 API 授权的微服务（检查 API 请求中提供的 apiKey 是否有效），因此为此，我有一个用于 API 授权的单独数据库，其中包含具有以下架构的下表：

API 密钥： ApiKey (VARCHAR, PK) 租户 ID（INT、FK）

租户：租户 ID (INT, PK) 名称（VARCHAR）

如您所见，APIKey 表已链接到租户表。

我有另一个微服务，这个微服务负责为租户存储错误，因此需要引用租户表，但由于租户表位于单独的数据库中，我们实际上无法使用它。

我考虑过创建一个租户服务并为租户创建一个数据库，但这会导致其他微服务出现数据完整性问题，需要对租户进行一些引用，所以我不确定我应该怎么做。

谁能建议应该怎么做？

【问题讨论】：

【解决方案1】：

租户错误的微服务似乎是一个纳米服务。听起来您实际上是在使用它进行监视。有更多的监控解决方案，例如 Splunk 和 ELK，可以进行更通用的日志记录。如果您有其他微服务，它们也可以将错误记录到它们。

如果您使用监控解决方案，则不需要租户错误微服务，也不需要您建议的租户微服务。但是，如果您想继续使用单个服务，您可以将错误事件和租户事件发布到从 API 授权服务到租户微服务或租户错误服务的队列中。因此，您将复制数据，并且需要制定策略以保持数据的一致性。

可以说，由于您决定将其拆分为相应的微服务，这会导致更多的复杂性。另一方面，共享架构可以解决您的问题，但同时可以耦合您的架构。微服务存在的原因本质上是为了摆脱耦合，所以我建议回去评估是否决定为服务定义这些界限，看看你可以将什么结合在一起以消除或最小化复杂性。

【讨论】：

如果在这种情况下我不想使用第三方监控工具，应该怎么做？你是说我应该将数据复制到其他微服务上吗？因此，如果租户存在于一个微服务中，那么所有其他需要租户的微服务都应该被告知，因此租户也应该被复制到其他服务上？
通过发布的权利复制，如第二段第二句所示。
@KTOV，为复制数据集添加了更多颜色和替代方案，但最终还是建议重新评估服务边界的方向。