architecture - 我应该有多个 GraphQL 实例还是只有一个？

Question

我的公司运行一个微服务架构，该架构拥有 50 多个服务，这些服务由单个 GraphQL 端点提供支持，这些端点协调我们的服务之间的调用，为我们的最终用户支持我们的 Android 和 iOS 应用程序。

我们正在开发一种新产品，该产品不会被这些最终用户使用，而是用于通过我们的应用程序为我们的最终用户提供商品的公司。 TL;DR:例如通过我们的平台显示有关其销售的绩效数据。

由于这个新产品和我们的应用程序的数据需求几乎没有什么不同，我们正在讨论为这个产品创建一个新的 GraphQL 端点，因为我们害怕将原始 GraphQL 层变成一个整体例如，发生灾难时的单点故障。

查看 GraphQL 的网站、Facebook 帖子、Apollo 的 Principled Graphql 等，很容易在某处看到“单一端点”短语。我想知道直到这仍然有效。

任何人的推荐/意见，甚至是关于谁参与过这次讨论的推荐信，都值得赞赏。如果贵公司之前有过这种讨论，最终做出的决定是什么，考虑了什么？

Answer 1

我建议也许以不同的方式思考这个问题。
如果我正确理解这一点，您将遇到一些问题:

您即将首次向外部方公开内部 API - 或与您的内部 API 接近的内容

您担心其中一个对另一个的影响(例如，外部 DDoS 导致您的内部流程停止)

您不确定如何最好地构建 GraphQL 以在相关但可能不同的 API 之间共享相似的功能

这是一个很好的总结吗？
我建议您应该查看 API 网关来保护您的外部 API，无论您选择什么 API 实现。无论如何，您都需要身份验证和授权。
API 网关还让您可以控制如何路由 API 调用。如果您选择为内部和外部使用相同的 API，您可以拥有这些 API 实现的池以实现冗余，并且只允许 API 网关在其中的一个子集之间进行负载平衡。这意味着即使它们完全没有问题，您也应该有一些保留的能力来处理内部请求。 (如果负载实际上是在您的后端数据源上，那么这完全是另一个问题!)
如果您正在寻找构建完全独立运行但重用功能的单独 GraphQL API 的方法，您可以查看类似 Apollo 的内容。要做到这一点，但我不是 GraphQL 专家。
但是，正如我上面提到的，您对单点故障的担忧可能需要考虑您的后端。无论您如何隔离网关、代理、GraphQL 端点等，如果它们都访问同一个数据库，那么灾难可能会同时关闭您的内部和外部 API。
希望能让你深思。