architecture - 将 gRPC 和/或 GraphQL 用于微服务架构

Question

在我的公司，我们即将建立一个新的微服务架构，但我们仍在尝试确定哪种协议(protocol)最适合我们的用例。
在我们的例子中，我们有一些服务在内部被其他服务调用，但也通过 GraphQL API 网关向我们的客户端公开。
选项 1:gRPC
gRPC 似乎因其性能和效率而成为微服务内部通信的流行选择。
但是，gRPC 使得查询关系数据变得更加困难，并且需要更多的工作来连接我们的 API 网关。
选项 2:GraphQL
另一种选择是让每个微服务实现自己的 GraphQL 模式，以便使用 API 网关中的 Apollo Federation 轻松地将它们拼接在一起。
这种方法将使查询更加灵活，但由于缺少 Protocol Buffer ，内部请求的性能会降低。
选项 3:两者都有？
也许另一种选择是通过在 gRPC 中实现突变和在 GraphQL 中实现查询来利用两全其美。或者只是创建两个 API，一个面向网关客户端，一个用于服务之间的通信。
问题

我们如何决定使用哪种方法？

我们应该考虑任何重要的(不利)优势吗？例如。在易用性、可维护性、可扩展性、性能等方面？

这个用例有更好的选择吗？

Answer 1

这取决于您正在实现的整体架构。
我建议同时使用 GraphQL 和 gRPC:

使用Apollo Federation作为边界节点，无缝处理来自使用 GraphQL 的前端的请求。

使用CQRS您的 API 和微服务上的模式，并严格区分读取模型和写入模型。

使用六边形架构(我公司使用Explicit Architecture)实现DDD - Domain-driven-design .

为了无缝集成 Apollo，您必须在所有后端服务的架构中实现 GraphQL 层。

在读取模型中，实现 GraphQL 层。您将从联邦中受益(来自多个微服务的数据的并行读取将在联邦引擎中“加入”，而无需您的 API 节点的任何参与)。

对于写入模型(突变)中后端服务之间的通信，请使用 gRPC .

gRPC 将使远程调用您的 CQRS 命令成为可能，就像它是本地的一样。

因此，您的远程微服务看起来就像您本地后端代码的一部分。

您还需要像 RabbitMQ 这样的消息代理或 Kafka通过事件和消息队列管理一些更复杂的状态变化。