gRPC vs NATS 或 Kafka 有意义吗？
Does gRPC vs NATS or Kafka make any sense?
一直以来，提到微服务架构，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？它取代了什么？
您的直觉是正确的，gRPC 无法与异步队列系统（如 kafka、Rabbit 等）相提并论
然而，它是同步服务器到服务器通信技术的替代品，通常通过 SOAP、RPC、REST 等实现，您希望从另一台服务器获得响应，而不是将消息发送到队列中，然后有效地执行忘记留言了。
gRPC 绝对是 real-time 通信的一个选项。如果您不流式传输到浏览器（不支持 gRPC），它可以替代套接字通信，查看双向流式传输支持。
关于替换 Kafka/Rabbit，gRPC 可以用作 PubSub 系统，因为它支持双向流，但我不推荐它。
我经常看到人们在一个关键方面错放了这些技术：public 身份验证。
例如，检查此图：
这是InvertedJson(https://github.com/lega911/ijson)的一个benchmark，比较了一些工具，比如iJson、RabbitMQ、Nats、0MQ等
请注意，Nats、ZeroMQ 和 iJson 并不打算用作 public 端点（例如，Nats 有 user/password、令牌和密钥，但它在开放环境中是无用的，例如网络浏览器，因为没有办法使密钥非 public).
另一方面，GRPC 与 JWT 和 Oauth2 一起工作得很好，使其对 public 端点完全安全（与任何其他 HTTP 端点一样安全），因为这些令牌是服务器签名的（所以，即使它们很坚硬 public，也无法锻造或回火）
所以，我想说的是：有些技术要面对 public，有些技术要将服务器和服务器内的进程粘合在一起（这是专用连接）。
GRPC 是 public，ZeroMQ 和 iJson 是完全私有的（例如，iJson，没有任何类型的身份验证）。 Nats 使用密钥或密码，因此，尽管它比 iJson 和 ZeroMQ“更安全”，但它并不意味着 public.
当你说 REST（我在这里假设 HTTP，因为 REST 只是一种架构），websocket/socket.io/signalR，你描述的是所有 public 接口。 GRPC 将在这里为您介绍（它与 REST 的 request/response 和 websocket/socket.io/signalR 相当，因为它支持半双工和全双工流（类似于套接字））。
另一方面，Nats、iJson、ZeroMQ 并不打算这样做。它们旨在服务之间进行通信。
所以，基本上，REST/websocket/socket.io/signalR = gRPC.
服务之间的内部通信（在相同或不同的服务器中）= NAT、iJSON、ZeroMQ。
（请注意，我什至没有考虑图中的其他技术，因为它们是产品，IMO，而不是您可以用来达到目的的简单库，例如 RabbitMQ、nginx 等。其他的我不够熟悉，无法发表意见（但我对该图中的 uvloop 感到惊讶）。
一直以来，提到微服务架构，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？它取代了什么？
您的直觉是正确的，gRPC 无法与异步队列系统（如 kafka、Rabbit 等）相提并论
然而，它是同步服务器到服务器通信技术的替代品，通常通过 SOAP、RPC、REST 等实现，您希望从另一台服务器获得响应，而不是将消息发送到队列中，然后有效地执行忘记留言了。
gRPC 绝对是 real-time 通信的一个选项。如果您不流式传输到浏览器（不支持 gRPC），它可以替代套接字通信，查看双向流式传输支持。
关于替换 Kafka/Rabbit，gRPC 可以用作 PubSub 系统，因为它支持双向流，但我不推荐它。
我经常看到人们在一个关键方面错放了这些技术：public 身份验证。
例如，检查此图：
这是InvertedJson(https://github.com/lega911/ijson)的一个benchmark，比较了一些工具，比如iJson、RabbitMQ、Nats、0MQ等
请注意，Nats、ZeroMQ 和 iJson 并不打算用作 public 端点（例如，Nats 有 user/password、令牌和密钥，但它在开放环境中是无用的，例如网络浏览器，因为没有办法使密钥非 public).
另一方面，GRPC 与 JWT 和 Oauth2 一起工作得很好，使其对 public 端点完全安全（与任何其他 HTTP 端点一样安全），因为这些令牌是服务器签名的（所以，即使它们很坚硬 public，也无法锻造或回火）
所以，我想说的是：有些技术要面对 public，有些技术要将服务器和服务器内的进程粘合在一起（这是专用连接）。
GRPC 是 public，ZeroMQ 和 iJson 是完全私有的（例如，iJson，没有任何类型的身份验证）。 Nats 使用密钥或密码，因此，尽管它比 iJson 和 ZeroMQ“更安全”，但它并不意味着 public.
当你说 REST（我在这里假设 HTTP，因为 REST 只是一种架构），websocket/socket.io/signalR，你描述的是所有 public 接口。 GRPC 将在这里为您介绍（它与 REST 的 request/response 和 websocket/socket.io/signalR 相当，因为它支持半双工和全双工流（类似于套接字））。
另一方面，Nats、iJson、ZeroMQ 并不打算这样做。它们旨在服务之间进行通信。
所以，基本上，REST/websocket/socket.io/signalR = gRPC.
服务之间的内部通信（在相同或不同的服务器中）= NAT、iJSON、ZeroMQ。
（请注意，我什至没有考虑图中的其他技术，因为它们是产品，IMO，而不是您可以用来达到目的的简单库，例如 RabbitMQ、nginx 等。其他的我不够熟悉，无法发表意见（但我对该图中的 uvloop 感到惊讶）。