【发布时间】：2020-05-08 15:26:51
【问题描述】：
我有一个架构问题，很想听听您的经验。 在微服务环境中。当需要通过某种发布-订阅机制相互异步通信的 2 个 graphql API 微服务时。你会选择graphql订阅吗？或类似 kafka/rabitmq/etc 类型系统的东西。 我应该遵循什么架构规则吗？这种决定有什么标准吗？ 谢谢你们的cmets！
【问题讨论】：
标签： graphql graphql-subscriptions
【发布时间】：2020-05-08 15:26:51
【问题描述】：
GraphQL 不一定是服务间通信的糟糕选择，但这并不是 GraphQL 的设计和优化目标。特别是对于 pub-sub，Kafka 和 RabbitMQ 都是流行的选择。理论上，GraphQL 订阅可以通过 Kafka 等队列实现，但这与仅使用 Kafka 相比会增加一些复杂性。 GraphQL 规范没有太多说明订阅应该如何实现，而且开源支持远不如查询和突变那么完整。
service-service pub-sub 订阅的优点：
- GraphQL 为您提供了一个工具来指定消息的形状（这可以 也可以使用 Avro 或 Protobufs 等模式来完成。
- GraphQL 订阅允许订阅者自定义有效负载 他们收到
缺点：
- 与直接使用 Kafka 客户端相比，它增加了系统的复杂性
- 您将需要更多的工程周期
需要考虑的一些问题：
- 与使用现成代码相比，您希望花多少时间创建自己的解决方案？
- 您将从 GraphQL 的哪些方面受益？
【讨论】：
-
感谢您的详尽回复。具体来说，我使用的是内置订阅实现的 graphql-java 库。在这种情况下，我的 java 应用程序代码必须充当客户端，并将消息推送到 graphql-java 子实现或 kafka 集群中，所以在在这方面，kafka 就更没有意义了，因为它引入了一个我需要学习和照顾的新组件。我只是不确定是否像您提到的那样，graphql 中的订阅是为进程间通信而设计的，而是为浏览器客户端使用而设计的。希望我现在更清楚了。还是有点困惑:)
-
如果您可以从单个服务器实例运行，则可以仅使用 graphql-java 节点进行订阅，但如果您需要多节点设置，您通常会有某种分布式它背后的发布-订阅系统。如果您确实在 graphql 订阅方法上取得了成功，我很想听听它是如何进行的！