将 Apollo Federation 与微服务结合使用真的有意义吗？

Question

我们最近将我们的技术堆栈从多个完全封装的微服务切换到 Apollo Federation。每个微服务都转换为子图，超级图由网关联合。

但最近感觉我们已经失去了使用微服务的一些主要优点——解耦部署、异步服务间通信、大量额外的布线以及花在协调开发上以保持超级图在多个环境中稳定的时间。

感觉我们已经回归到更加单一的工作方式，但拥有独立的团队和服务。

由于 Apollo 已经出现有一段时间了，并且是根据 GraphQL 规范开发的，该规范最初是为了加快 Facebook 在 Facebook 还只是一个庞然大物时的延迟问题，所以我不禁想知道它是否只是不在一个地方尚未完全支持微服务架构。我有时会想，同时做 Apollo Federation 和微服务是否有点矫枉过正。

TL;DR：

将 Apollo Federation 与微服务结合使用只是一项投资回报递减的前沿热门尝试还是具有实际意义？

在哪些用例（我想是少数）中这样做是有意义的？

我们如何保留在联邦范式中使用纯微服务的好处（即，不协调大量服务中的小变化）？

Answer 1

我们如何保留在联邦范式中使用纯微服务的好处（即，不同步协调大量服务中的小变化）？

我认为 Apollo Federation 之所以有用，主要是因为关注点分离的原则。这样，您就不需要同步协调大量服务中的小变更。例如，假设您有一个评论子图和一个用户子图。只要两个子图知道另一个实体的密钥，它们就可以使用它，而无需协调它们之间的更改。如果团队 A 实施仅与他们关心的事情相关的事情，那么理想情况下他们应该永远不必与另一个团队协调变更。

将 Apollo Federation 与微服务结合使用只是一项投资回报递减的前沿热门尝试还是具有实际意义？

如果您已经拥有彼此完全独立的微服务，那么使用 Apollo Federation 可能不是您想要使用的理想工具。还有其他开源解决方案可以帮助您将微服务组合在单个网关下（例如 GraphQL-mesh、Stepzen 等），并且这些解决方案不需要您的微服务支持联合。话虽如此，有些团队仍然坚持使用 Apollo Federation，因为它天生就有能力通过关注点所有权分离的概念，以相对干净的方式帮助分离子图。因此，肯定存在使用 Apollo Federation 产生影响的用例（即，当一个子图必须使用另一个子图拥有的实体时）。