一直以来，提到微服务架构，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 等实现的同步服务器到服务器通信技术，在这种技术中，您期望从另一个服务器获得响应，而不是将消息发送到队列中，然后有效地忘记该消息。
我经常看到人们把这些技术放在一个关键方面：公共身份验证。
例如，检查此图：
这是 Inverted Json ( https://github.com/lega911/ijson ) 的基准测试，比较了一些工具，例如 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 感到惊讶））。
gRPC 绝对是实时通信的一种选择。如果您不向浏览器流式传输（不支持 gRPC），它可以替换套接字通信，请查看双向流式传输支持。
关于替换 Kafka/Rabbit，gRPC 可以用作 PubSub 系统，因为它支持双向流，但我不推荐它。