gRPC 与 NATS 或 Kafka 是否有意义？答案

【问题标题】：Does gRPC vs NATS or Kafka make any sense?gRPC 与 NATS 或 Kafka 是否有意义？
【发布时间】：2020-12-04 16:19:33
【问题描述】：

一直以来，提到微服务架构，NATS 和 Kafka 是我最先想到的选择。但最近我在 dotnet core 中发现了这个 gRPC 模板，这引起了我的注意。我阅读了很多关于它的内容并观看了很多视频，但我认为其中任何一个都不能正确解决 gRPC，因为它们通常会在 gRPC 和消息代理或协议（如 REST）之间形成对比，尽管 SOAP 可能是相关的，但我认为这是非常不合适的这里。我的假设是 gRPC 是 SOAP 的现代版本，由于它的协议缓冲区，它具有更好的性能和更少的实现麻烦。而且我认为 gRPC 无法与 Kafka 或 NATS 相提并论。而且它不能像 SOAP 那样替代 RESTful 服务。

现在的问题是，我的假设在多大程度上是正确的？例如，在选择集群节点之间的通信桥时，我现在是否必须将 gPRC 放在我的选项中（NATS、Kafkam Rabbit 等），还是在创建 Web 代理以桥接外部请求时考虑到我的微服务？

最后，实时通信怎么样，gRPC可以完全替代websocket/socket.io/signalR吗？它取代了什么？

【问题讨论】：

标签： rest websocket apache-kafka grpc nats.io

【解决方案1】：

我经常看到人们在一个关键方面误用了这些技术：公共身份验证。

例如，检查这个图表：

这是一个Inverted Json (https://github.com/lega911/ijson)的benchmark，比较了一些工具，比如iJson、RabbitMQ、Nats、0MQ等。

请注意，Nats、ZeroMQ 和 iJson 并不打算用作公共端点（例如，Nats 具有用户/密码、令牌和密钥，但在 Web 浏览器等开放环境中是无用的，因为没有办法使密钥不公开）。

另一方面，GRPC 与 JWT 和 Oauth2 一起工作得很好，使其对公共端点完全安全（与任何其他 HTTP 端点一样安全），因为这些令牌是服务器签名的（因此，即使它们是公开的，它们不能被伪造或回火）

所以，我想说的是：有些技术旨在面向公众，有些技术旨在将服务器和服务器内的进程粘合在一起（它们是私有连接）。

GRPC 是公共的，ZeroMQ 和 iJson 是完全私有的（例如，iJson 没有任何类型的身份验证）。 Nats 使用密钥或密码，因此，虽然它比 iJson 和 ZeroMQ “更安全”，但它并不意味着公开。

当您说 REST（我在这里假设 HTTP，因为 REST 只是一种架构）时，websocket/socket.io/signalR，您正在描述所有公共接口。 GRPC 将在这里为您介绍（它与 REST 作为请求/响应和 websocket/socket.io/signalR 相当，因为它支持半双工和全双工流（类似于套接字）。

另一方面，Nats、iJson、ZeroMQ 并不打算这样做。它们用于在服务之间进行通信。

所以，基本上，REST/websocket/socket.io/signalR = gRPC。

服务之间的内部通信（在相同或不同的服务器中）= NATs、iJSON、ZeroMQ。

（请注意，我什至没有考虑图中的其他技术，因为它们是产品，IMO，而不是您可以用来达到目的的简单库，例如 RabbitMQ、nginx 等。其他的我'我不够熟悉，无法发表意见（但我对该图中的 uvloop 感到惊讶）。

【讨论】：

【解决方案2】：

gRPC 绝对是实时通信的一种选择。如果您不向浏览器流式传输（不支持 gRPC），它可以替代套接字通信，请查看双向流式传输支持。

关于替换 Kafka/Rabbit，gRPC 可以用作 PubSub 系统，因为它支持双向流，但我不推荐它。

【讨论】：

请注意，支持用于 Web 的 gRPC！我用过它，它运行良好，虽然不如其他 gRPC 库（Java、Python、Node 等）grpc.io/docs/languages/web/basics github.com/grpc/grpc-web
gRPC 不是为 Pub/Sub 构建的，它适用于没有代理的 RPC（不同的架构）截至 2020 年 9 月，没有使用 gRPC 制作的维护良好的开源 Pub/Sub 代理。
我的意思是浏览器不支持它。 Grpc-web 使用 Envoy 代理请求。这是我强烈不推荐的解决方法。您正在添加不必要的复杂性。
无论如何，你的答案是错误的，因为浏览器支持 gRPC，而且我已经在浏览器上完成了 gRPC 流式传输当然 CORS 和 HTTP/1.1 回退（安全性和兼容性）需要 Envoy
浏览器不支持 gRPC。如果没有 Envoy 将 HTTP 请求代理到 gRPC，它将无法工作。我建议你多研究一下。如果您说可以从浏览器执行 gRPC，请尝试删除 Envoy。作为项目负责人，我不想将 Envoy 添加到我的堆栈中。 grpc-web 的整个复杂性是不必要的。您可能想查看此项目以了解如何有效管理 gRPC API github.com/apssouza22/modern-api-management

【解决方案3】：

您的直觉是正确的，gRPC 无法与 kafka、Rabbit 等异步排队系统相提并论。

然而，它是同步服务器到服务器通信技术的替代品，这些技术通常通过 SOAP、RPC、REST 等实现消息。

【讨论】：