1

我有无法解决的概念/设计问题。我将尝试在体育术语示例中解释它，但当然同样的问题可以应用于电子商店或任何其他系统。

我想用 API 构建 2 个“独立”微服务来执行所需的操作。服务 A 将处理球员管理，服务 B 将处理球队管理。

在 Service AI 中，例如可以执行球员训练、购买球员物品、设置球员外观等。在 Service BI 中，例如可以设置团队战术、雇用团队工作人员、设置团队外观（徽标、颜色）等。

我已经阅读了许多关于微服务的文章和主题，并在一篇文章中写道：“......关于微服务最难的部分 = 你的数据......”

我的问题来了。我应该如何以及在哪里存储玩家和团队之间的关系（将 TeamPlayer 表想象为包含 player_id、team_id 列的简单关系表）？所以这些是我的担忧：

  1. 表 TeamPlayer 应该是微服务 A 还是 B 的一部分？或者两个微服务应该共享同一个数据库？
  2. 如果它将是独立数据库，并且如果我决定微服务 B 将存储此关系，我如何验证该播放器是否存在？如果有人给我发送了错误的玩家标识符怎么办？还是我需要关心？我是否需要验证玩家是否存在或者这不是微服务 B 的问题？当然，微服务 B 知道团队，所以当提供错误的团队标识符时我可以返回错误。我不想从微服务 B 调用微服务 A，因为那样我会将它们紧密结合在一起，并依赖从微服务 B 到微服务 A。
  3. 如果它将是独立数据库，我将如何读取数据？想象一下，在 UI 中，我想要团队中的球员姓名列表。微服务 B 知道团队，只是关系和微服务 A 知道名称。我是否需要至少拨打两次电话才能收集数据？
  4. 如果是共享数据库，微服务B可以直接从数据库中读取玩家的一些数据吗？我可以想象在某些情况下，由于某些访问权限等原因而不允许这样做，但是所有这些业务逻辑都构建在微服务 A API 中，该 API 通常读取并返回有关播放器的数据。

如何以最好的方式解决这个问题？API网关是答案还是如何以最佳方式做到这一点？

我希望能弄清楚我的担忧是什么:)

4

2 回答 2

0

通常，微服务的正确边界不会与您在由具有外键约束的关系数据库支持的单体应用程序中使用的规范化表很好地对齐。相反，我建议让每个服务维护自己的数据视图，以查看执行其任务所需的数据（让服务发布持久的事件日志以更改它们控制写入的状态是我推荐的机制）。在您的服务 A 和 B 的概念中可能存在多个“有界上下文”：为每个有界上下文拥有一个微服务可能是有意义的。

那么考虑到这一点，什么是团队？从“将球员分配到球队”操作的角度来看，球队可能只是与某种唯一 ID 相关联的一组球员。战术和标志/颜色与该操作无关。它所需要的只是：

  • 存在哪些玩家（可从管理创建新玩家的服务发布的事件中得出）
  • 创建了哪些团队（此服务可能拥有该团队，或者它可能源自管理创建团队的服务发布的事件）
  • 哪些球员在哪些球队（该服务肯定会拥有该数据）

请注意，这种方法确实带来了最终的一致性：直到从创建球员开始经过一段时间（可能很短，认为可能不到一秒）之后，才能将该球员分配到团队中成功。

于 2021-02-15T21:48:08.210 回答
0

简短的回答是 - 表 TeamPlayer 应该是微服务 A 和 B 的一部分。

为了解释，我从 Levi 的回答中借用了一句话“我建议让每个服务都维护自己的数据视图”。这是设计微服务的正确方法。

您可以提出有关数据重复和数据一致性的问题。是的，会有数据重复，但这是设计、开发和维护微服务的架构权衡。在数据一致性方面，最终一致性应该默认模式来维护数据库状态，除非有特定的用例（例如 - 银行）具有强一致性。

希望这个答案能让您清楚简洁地了解您的设计问题。

于 2021-02-20T08:16:50.857 回答