我有无法解决的概念/设计问题。我将尝试在体育术语的例子中解释它，但当然同样的问题也可以应用于电子商店或任何其他系统。
我想建立2"；独立的"；使用API执行所需操作的微服务。A队将负责球员管理，B队将负责球队管理。
在服务A中，我可以进行球员训练，购买球员物品，设置球员外观等。在服务B中，我可以设置团队策略，雇佣团队员工，设置团队外观(徽标、颜色)等。
我读过很多关于微服务的文章和主题，其中一篇文章写道："；。。。微服务最难的部分=你的数据">
我的问题来了。我应该如何以及在哪里存储玩家和团队之间的关系(将TeamPlayer表想象成一个简单的关系表，列为player_id、team_id)？所以这些是我的担忧：
- 表TeamPlayer应该是微服务A还是B的一部分？或者两个微服务应该共享同一个数据库
- 如果它将是独立的数据库，如果我决定微服务B将存储这种关系，我如何验证该播放器的存在？如果有人给我发错了玩家识别码怎么办？还是我需要关心？我需要验证播放器是否存在，或者这不是微服务B的问题吗？当然，微驱动程序B知道团队，所以当提供错误的团队标识符时，我可以返回错误。我不想从微服务B调用微服务A，因为那样我会把它们紧紧地绑在一起，并从微服务A依赖于微服务B
- 如果是独立数据库，我将如何读取数据？想象一下，在UI中，我想要团队中的球员名单。微服务商B知道团队和关系，微服务商A知道名称。我需要至少打两个电话来收集数据吗
- 如果是共享数据库，微服务B能直接从数据库中读取一些玩家的数据吗？我可以想象，在某些情况下，由于某些访问权限等原因，这不应该被允许，但所有这些业务逻辑都建立在微服务API中，该服务通常读取并返回有关播放器的数据
如何以最佳方式解决此问题？API网关是答案还是如何以最佳方式实现？
我希望能弄清楚我的担忧：)
通常，微服务的适当边界不会与您在由具有外键约束的关系数据库支持的单片应用程序中使用的规范化表很好地对齐。相反，我建议让每个服务维护自己执行任务所需的数据视图(我建议使用服务发布事件的持久日志，以更改其控制写入的状态)。可能存在多个"；有界上下文"；在您对服务A和B的概念中：为每个有界上下文提供一个微服务可能是有意义的。
考虑到这一点，什么是团队？从"；将球员分配给球队"；一个团队可能只是一组与某种独特ID相关联的玩家。战术和标志/颜色与该操作无关。它所需要的只是：
- 存在哪些玩家(可从管理创建新玩家的服务发布的事件中派生)
- 创建了哪些团队(该服务可能拥有这些团队，也可能源于管理创建团队的服务发布的事件)
- 哪些球员在哪些球队(该服务肯定会拥有这些数据)
请注意，这种方法确实带来了最终的一致性：直到一名球员被创建后的一段时间(可能很短，可能不到一秒钟)过去，该球员才能成功分配到一个团队。
考虑到您的问题涉及的广泛复杂问题，我将把我的回答重点放在主要的概念/设计问题上。考虑到这一点，我建议进行以下潜在的重新设计：
-
微服务A(玩家服务)：此服务专注于玩家相关功能，如玩家训练、购买玩家物品和修改玩家外观。它有自己的专用数据库，存储所有相关的玩家信息。
-
微服务B(团队服务)：该服务管理以团队为中心的活动，包括团队战术的设置、团队员工的雇佣以及更改团队外观(徽标、颜色)等功能。与球员服务一样，它也有自己的专用数据库，保存所有相关的球队数据。
-
微服务C(团队球员服务)：此服务的任务是维护球员和团队之间的关系。它在自己的独立数据库中包含一个TeamPlayer表。该表主要由player_id和team_id列组成。该服务可以提供API来管理玩家和团队之间的关联。
TeamPlayer服务还能够执行验证，以确保提供的player_id和team_id的合法性。它可以通过利用播放器和团队服务提供的API来实现这一点。
请注意，即使你需要将一名球员与多支球队联系起来，这种方法也很合适。
简而言之，table TeamPlayer应该是微服务A和B的一部分。
为了解释，我借用了李维斯的回答中的短语"；我建议让每个服务保持其自己的数据视图"；。这是设计微服务的正确方法。
您可能会对数据重复和数据一致性提出疑问。是的，会有数据复制，但这是设计、开发和维护微服务的架构权衡。在数据一致性方面，最终一致性应该是默认模式，以维护数据库状态，除非有特定的用例(例如银行)具有很强的一致性。
希望这个答案能让你对你的设计问题有一个清晰简洁的认识。