哪种rpc / messaging框架最适合这种情况？

Question

使用情景：一个Java进程和一个或两个C++进程，在同一台机器上，需要双向、二进制、非持久化的通信。其中一个C++进程负责实例化其他进程。

我已经看过一些东西，比如XML/JSON-RPC、Protocol Buffers、Thrift、zeromq等。

如果可能的话，可移植性会很好，但需要支持Windows XP/7。

- Rhangaun

---

取决于你要传输的数据类型（文本/二进制）、系统所需吞吐量以及你想使用的API类型（高级，例如SOAP或低级，例如协议缓冲区/zeromq）。 - Victor Sorokin

@Skeptic 另外，您的传输层是否需要持久性，还是持久性将由端点提供？如果是前者，您将需要类似 JMS 的东西。 - Victor Sorokin

Answer 1

通常情况下，在设计中应该区分消息传输和消息反序列化/序列化，并尽可能使它们正交。简而言之，将数据（消息）流行为与消息内容解耦。

以下是一些消息导向的传输框架，允许在客户端和服务器实例之间的线程、进程和网络服务之间发送和接收中立有效负载数据（消息），以支持某些客户端/服务器通信行为模式（请求/响应、发布/订阅、推送/拉取等）。

有多个框架提供了中立的de-/serialization功能，以一种传输中立的方式对有效负载（消息）数据进行de-/serialization（例如，提供一种针对交换原生整数数据的线路格式，独立于机器的字节顺序）。

对于您特定使用案例的最佳组合选择，取决于您对设计决策的一些要求和约束：

- 在客户端/服务器处理单元（例如线程、进程或服务器/进程）上的可扩展性 - 总体性能和消息延迟 - 处理单元资源需求（例如堆内存或代码大小） - 网络资源影响（通过网络接口发送了什么） - 等等...我认为结合ZMQ消息框架和Google Protobuf消息框架可以为您的用例提供可行的解决方案。有针对c++和Java的语言绑定（参见ZMQ Java绑定），并且您将拥有针对进程间和线程间通信进行优化的实现。ZMQ连接的设计方式类似于套接字，支持双向（请求/响应）通信模式以及单向（发布/订阅、推送/拉取）。

如上所述，消息内容的格式由您决定，但是对于内部定义的消息协议，Google Protobuf可能是适当的，因为它支持C++和Java语言绑定。Google Protobuf还提供了一种定义RPC服务接口的机制，但您必须为客户端/服务器实现提供具体的消息传输协议。我从未通过ZMQ传输实现过这一点，但如果必要，应该是可以实现的。

XML/JSON-RPC可以考虑用于发布的协议（例如通过REST服务），与ZMQ相结合时桥接相当容易。

考虑到您的要求，我猜测后面的协议格式选项可能不是必需的，但根据您打算与Java/C++参与者一起使用的框架，可能会很有用。

据我所知，ZMQ符合您关于Windows XP/7平台的可移植性约束。 不确定，但在Windows系统上进行线程间通信可能会有限制。 但这似乎不适用于您描述的场景。

备选传输框架：

1. ActiveMQ
2. Boost asio（C++封装的本地套接字，对于Java方面的信息我不太清楚，欢迎进行补充）

备选消息编解码框架：

1. XML-RPCC++/Java（通常假定使用HTTP传输）
2. JSON

- πάντα ῥεῖ

---

ZMQ Java绑定的“生产就绪”程度如何？GitHub页面乍一看并不令人信服。 - Rhangaun

我不太了解Java绑定的详细信息，但似乎有人在使用它（我经常阅读邮件列表）。 - πάντα ῥεῖ

当你说“不令人信服”时，你到底指的是什么？最新的添加已经有一段时间了，但是问题列表似乎并不是很长。我还在我的回答中放了一个链接到文档主页，也许这可以帮助你找到更多信息。 - πάντα ῥεῖ

@Skeptic 因为我知道它，而且我知道它与Google Protobuf很好地配合使用。ActiveMQ也适用于您的用例，您甚至可以使用本机套接字来完成。对我来说，ZMQ似乎比ActiveMQ轻一些，但这种印象可能是错误的... - πάντα ῥεῖ

顺便说一句，我认为主要的设计决策是首先将传输机制与协议内容的编码/解码分离，就像我之前提到的那样。具体使用哪些框架取决于您的需求以及可用（必要的）编程语言和操作系统环境。 - πάντα ῥεῖ

Answer 2

根据问题评论中的信息，我认为协议缓冲区是需要考虑的东西——它在传输时具有二进制格式，具有简单的API，并且不提供任何冗余的东西，例如持久性。

- Victor Sorokin