微服务架构概念问题——微服务数据与边界

Question

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

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

在服务 A 中，我可以进行球员训练、购买球员物品、设置球员外观等。 例如，在服务 B 中，我可以设置团队策略、雇用团队人员、设置团队外观（徽标、颜色）等。

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

我的问题来了。我应该如何以及在哪里存储玩家和团队之间的关系（将表 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 网关是答案还是如何以最佳方式做到这一点？

我希望能说明我的顾虑:)

Answer 1

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

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

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

请注意，这种方法确实会带来最终的一致性：在创建玩家之后的一段时间（可能很短，认为可能不到一秒）之后，将该玩家分配给团队的任务才会成功.

Answer 2

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

为了解释，我借用了李维斯回答中的短语“我建议让每个服务保持自己的数据视图”。这是设计微服务的正确方式。

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

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