春季HATEOAS：微服务架构可行吗？

问题描述

我知道已经问过这个问题，但找不到满意的答案。 我开始更深入地研究构建一个真正的静态API，并且我喜欢使用链接进行解耦的约束。因此，我建立了我的第一个服务（使用java / spring），并且运行良好（尽管我在寻找正确的格式时有些挣扎，但这是另一个问题）。第一步之后，我考虑了我的现实用例。 Micorservices。高度分离的单个服务。所以我做了我以前的情况，但遇到了一些问题或疑问。

场景：

我的设置包括一个反向代理（作为服务发现和api网关的Traefik）和2个微服务。此外，还有一个openid连接安全层。我的服务是播放器服务和团队服务。

因此，通过身份验证后，我获得了带有用户ID的访问令牌，并且可以调用player/userId来获取玩家信息，并可以调用teams?playerId=userId来获取玩家的所有队伍。

我认为，我会在两个回复中都链接相反的服务。 player/userId将链接到teams?playerId=userId，反之亦然。

问题：

除了通过硬编码url链接之外，我没有找到解决方案。但这带来了很多失败，我无法想象这是现实应用中使用的解决方案。我的意思是，想象一下您的api更高级，您必须链接到10个资源。如果有什么变化，您已经重构并重新部署了所有这些。 除了同步问题之外，在这种情况下如何处理状态。我的意思是，REST都是关于状态转移的。因此，如果球员不在球队中，我将不提供球员与球队服务的链接。当然，我可以将团队ID作为属性添加到玩家，以决定是否包括链接。但这又增加了服务之间的耦合。
我越潜越多，就会发现更多的障碍，而我将只留在我的春季休息文档上，而忽略了休息的核心，我对此感到遗憾。

解决方法

微服务架构可行吗？

Fielding,2000

REST接口被设计为对于大颗粒超媒体数据传输是高效的，针对Web的常见情况进行了优化，但是导致的接口对于其他形式的体系结构交互不是最佳的。

Fielding 2008

REST适用于跨多个组织的长期基于网络的应用程序。

我现在还不清楚“微服务”将落入“网络”的最佳位置。通常，我们不会尝试与另一家公司控制的微服务进行通信，我们通常不会从缓存，按需编码或其他架构限制中获得很多好处。我们可以使用通用组件在解决方案中的不同微服务之间交换信息对我们有多重要？等等。

如果有什么变化，您已经重构并重新部署了它们。

是；如果这对我们来说将是一个问题，那么我们需要预先投入更多的工作来定义两者之间的稳定接口。 （在这一点上，我们使用“链接”的事实并不特殊-如果这两件事要相互交流，那么它们将需要讲一种通用语言；如果该通用语言需要逐步发展，时间（可能），那么您需要在其中构建这些功能）。

如果您想随着时间的推移进行更改，那么您必须为之作计划。

如果要向后/向前兼容，则必须进行规划。

您的标识符不必是静态的-有许多可能的方法来推迟标识符的定义；最明显的是，您可以使用另一个标识符来查找所需的标识符，或用于计算该标识符的公式，或者任何其他方式。

考虑一下Google的工作方式-他们使用的链接一直在变化，但这并不重要，因为协议（刷新您加了书签的搜索表，在“该”字段中输入文本，然后单击按钮）还没有' t在20年内发生了变化。界面是稳定的（即使标识符的基础拼写不是很好），就足够了。