gRPC和ZeroMQ的比较

Question

我希望能够比较grpc和zeromq及其模式的功能，我想要创建一些比较（功能集）- 以某种方式-0mq是更好的套接字，但无论如何，如果我应用0mq模式，我认为我可以得到可比较的“框架” - 在这里，0mq似乎更加灵活...

主要需求：

- 节点之间异步请求/响应通信（本地或远程） - 灵活的消息路由 - 负载均衡支持 - 有良好的文档记录

有什么建议吗？

谢谢！

- user3169252

---

我不完全确定这个问题适合放在StackOverflow上，就其原本的写法而言。它基本上是在寻求意见。 - Vatine

一个是消息队列，另一个是远程过程调用服务器。使用消息队列，当然可以实现RPC。但如果需要RPC，我建议选择gRPC。要在zmq上使用RPC，您需要在其之上构建自己的适配器。ZeroRPC就是这样的库。 - Shiplu Mokaddim

Answer 1

• 节点之间可以进行异步的请求/响应通信（本地进程或远程），具体实现取决于如何实现通信。有关gRPC，请参见此页面：http://www.grpc.io/docs/guides/concepts.html。基本上，gRPC允许进行典型的HTTP同步请求/响应或类似于'websocket'的双向流式传输。对于0mq，您可以设置一个简单的REQ-REP连接，这基本上是一条同步通信路径，或者您可以创建异步的ROUTER-DEALER类型拓扑。

• 灵活的消息路由

“路由”本质上意味着一条消息通过某个代理从A到B。在0mq中，这很容易实现，并且有几种支持这种功能的拓扑结构（http://zguide.zeromq.org/page:all#Basic-Reliable-Queuing-Simple-Pirate-Pattern）。在gRPC中，可以通过流式pub-sub连接创建相同类型的拓扑结构。gRPC支持将元数据放入消息中（https://github.com/grpc/grpc-go/blob/master/Documentation/grpc-metadata.md），这将允许您将消息'路由'到一个'pub-sub'连接可以提取的队列中。

• 负载均衡支持

gRPC支持健康检查 (https://github.com/grpc/grpc/blob/master/doc/health-checking.md) 但因为它是HTTP/2，所以需要一个HTTP/2负载均衡器来支持健康检查。不过这并不是个大问题，因为你可以将健康检查与一个HTTP/1.1服务绑定，然后由负载均衡器调用。0mq是一个tcp连接，这意味着负载均衡器可能会在tcp模式下检查“socket connect”以验证连接。虽然这样也能正常工作，但不太理想。同样地，你可以通过在0mq服务前端添加一个HTTP/1.1 web服务器来使负载均衡器从中读取。

• 文档完善

两者的文档都很完善。要深入了解0mq技术必须仔细阅读其文档，这需要更多的学习成本。

以下是它们之间的主要区别：

1. 0mq是一个tcp协议，而gRPC是带有二进制有效载荷的HTTP。
2. 0mq需要设计一个帧协议（帧1 = 版本，帧2 = 载荷，等等），而gRPC已经为你完成了很多这样的工作。
3. gRPC会自动转换为REST (https://github.com/grpc-ecosystem/grpc-gateway)，而如果要与0mq通信，则需要一个中间件应用程序。
4. gRPC使用标准的tls x509证书（类似网站），而0mq使用自定义的加密/认证协议 (http://curvezmq.org/)。在4.x之前，0mq没有加密支持，如果你真的想要它，你必须深入研究这些东西：https://wiki.openssl.org/index.php/BIO。（相信我不要这么做）

0mq可以创建一些非常强大的拓扑结构（https://github.com/zeromq/majordomo）（https://rfc.zeromq.org/spec:7/MDP/），而gRPC基本上是客户端/服务器

0mq需要更多的时间来构建和运行，而gRPC基本上是编译protobuf消息并将服务导入您的代码。

- ascotan

Answer 2

并不完全相同。gRPC主要用于异构服务互操作性，ZeroMQ（ZMQ/0MQ/ØMQ）是一个更低级别的消息框架。ØMQ除了传递二进制块之外，并没有指定有效载荷序列化，而gRPC默认选择Protocol Buffers。ØMQ几乎只能在同一台机器或数据中心/云之间工作，而gRPC也可以在真正的客户端上工作（例如移动设备或Web，它已经支持iOS）。对于云内/数据中心服务来说，gRPC使用ØMQ可能比http2请求/响应链的开销、延迟和复杂性更快、更高效。我不确定gRPC TLS安全是否足够适用于公共云和移动/Web使用，但人们总是可以在应用程序/应用程序框架的路由器/控制器级别注入端到端的安全需求（例如libsodium），并以明文模式运行（这也将消除OpenSSL分支BoringSSL因上游缺陷而导致的维护问题）。

对于非常高的延迟/低带宽服务（例如火星任务），人们会考虑使用像SMTP（例如Active Directory备用复制）或MQTT（例如Facebook Messenger、ZigBee、SCADA）这样的传输方式进行RPC。

奖励（离题）：如果gRPC有像ØMQ这样的可替换传输方式就好了（ØMQ本身也支持UNIX套接字、TCP、PGM和inproc），因为HTTP/2在所有语言中都不稳定，而且比ØMQ慢。此外，在HFT领域，值得关注nanomsg，因为它可以扩展RDMA/SDP/MPI，并实现超低延迟/零拷贝/Infiniband准备。

- user246672

---

我成功地在iOS和Android上构建了zmq，并在我的应用程序中使用它。 - kakyo

Zmq现在在传输层上支持Websockets。与移动浏览器兼容良好。 - Alex

Zmq现在在传输层支持Websockets。与移动浏览器兼容良好。 - undefined