grpc 和 zeromq 比较答案

【问题标题】：grpc and zeromq comparsiongrpc 和 zeromq 比较
【发布时间】：2017-01-14 00:14:41
【问题描述】：

我想以某种方式比较 grpc 与 zeromq 的功能及其模式：并且我想创建一些比较（功能集）-不知何故-0mq 是“更好”的套接字-但无论如何-如果我应用 0mq模式 - 我认为我得到了可比较的“框架” - 这里 0mq 似乎更加灵活......

主要要求是：

节点之间的异步请求/资源通信（inproc 或远程）
灵活的消息路由
负载平衡支持
有据可查

有什么想法吗？

谢谢！

【问题讨论】：

我不是 100% 相信这是 StackOverflow 的一个好问题，正如所写的那样。它本质上是在征求意见。
一个是消息队列，另一个是远程过程调用服务器。使用消息队列，可以肯定地实现 RPC。但是如果你需要 RPC，我会说去 gRPC。要在 zmq 上使用 RPC，您需要在其上构建自己的适配器。 ZeroRPC 就是一个这样的库。

标签： zeromq messaging grpc

【解决方案1】：

节点之间的异步请求/资源通信（inproc 或远程）

这两个库都允许同步或异步通信，具体取决于如何实现通信。有关 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) 中，这将允许您将消息“路由”到“发布-订阅”连接可以从中提取的队列中。

负载平衡支持

gRPC 支持健康检查 (https://github.com/grpc/grpc/blob/master/doc/health-checking.md)，但因为它是 HTTP/2，所以您必须有一个 HTTP/2 负载平衡器来支持健康检查。然而，这并不是什么大问题，因为您可以将运行状况检查与负载均衡器调用的 HTTP/1.1 服务联系起来。 0mq 是一个 tcp 连接，这意味着负载均衡器可能会检查 tcpmode 中的“套接字连接”以验证连接。这有效，但它不是那么好。同样，您可以使用负载均衡器从中读取的 HTTP/1.1 网络服务器获得 0mq 服务的流畅和前端。

有据可查

两者都有很好的记录。必须阅读 0mq 的文档才能彻底了解该技术，并且更多的是更高的提升。

这是最大的区别：

0mq 是 tcp 协议，而 gRPC 是带有二进制负载的 HTTP。
0mq 要求您设计一个成帧协议（frame 1 = verison，frame 2 = payload 等），而大部分工作在 gRPC 中为您完成
gRPC 被透明地转换为 REST (https://github.com/grpc-ecosystem/grpc-gateway)，而 0mq 需要一个中间件应用程序才能与它通信。
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 消息并将服务导入到您的代码中。

【讨论】：

【解决方案2】：

不太一样。 gRPC 主要用于异构服务互操作性，ZeroMQ (ZMQ/0MQ/ØMQ) 是一个较低级别的消息传递框架。 ØMQ 没有指定除了传递二进制 blob 之外的有效负载序列化，而 gRPC 默认选择协议缓冲区。 ØMQ 几乎停留在数据中心/云之间的同一台机器或机器上，而 gRPC 也可能在真实客户端上工作（即移动或 Web，它已经支持 iOS）。与 http2 请求/响应链的开销、延迟和复杂性相比，使用 ØMQ 的 gRPC 对于云/数据中心服务可能更快、更高效。我不确定 gRPC TLS security 如何（或什至）是否足以满足公共云和移动/Web 使用，但始终可以在路由器/控制器级别注入端到端安全要求（即 libsodium） app/app 框架并以纯文本模式运行（这也将消除 OpenSSL fork BoringSSL 因上游缺陷而引起的维护难题）。

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

奖励（题外话）：如果 gRPC 有像 ØMQ（它本身也支持 UNIX 套接字、TCP、PGM 和 inproc）这样的替代可插入传输，那就太好了，因为 HTTP/2 在所有语言中都不是稳定的，而且它比ØMQ慢。而且，值得关注 nanomsg（尤其是在 HFT 领域），因为它可以通过 RDMA/SDP/MPI 进行扩展，并实现了疯狂的低延迟/零复制/Infiniband-ready。

【讨论】：

我设法在 iOS 和 Android 上构建了 zmq，并在我的应用程序中使用了它。