问题描述
在很长一段时间里，谈到微服务架构，NATS和Kafka是我想到的第一个选择。但是最近我在dotnet核心中找到了这个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 /兔子，gRPC可以用作PubSub系统，因为它支持双向流传输，但我不建议这样做。