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

时间:2012-05-08 20:10:26

标签: java c++ asynchronous messaging rpc

用例:一个带有一个或两个C ++进程的Java进程,始终在同一台机器上。需要双向,二进制,非持久通信。其中一个C ++进程负责实例化其他进程。

我已经浏览过,看过XML / JSON-RPC,Protocol Buffers,Thrift,zeromq等等。

如果可能,便携性会很好,但需要Windows XP / 7。

2 个答案:

答案 0 :(得分:10)

通常,您应该在设计中分离消息传输和消息解除/序列化,并使它们尽可能保持正交。简而言之,将数据(消息)流行为与消息内容分离。

  1. 有几个面向消息的传输框架,允许发送和接收中性有效负载数据(消息),用于客户端/服务器通信(请求/回复,发布/订阅,推/拉,......)的某些行为模式线程,进程和网络服务作为客户端和服务器实例。
  2. 有许多框架可以在传输中性中提供有效载荷(消息)数据的去序列化(例如,提供用于交换独立于机器字节序的本机整数数据的有线格式)。
  3. 您的特定用例的最佳组合选择取决于您对设计决策的一些要求和限制:

    • 作为线程,进程或服务器/进程的客户端/服务器处理单元的可伸缩性
    • 整体性能和消息延迟
    • 处理单位资源要求(例如堆内存或代码大小)
    • 网络资源影响(通过网络接口发送的内容)
    • 等。 ...
  4. 可能的解决方案:
    我认为ZMQ messaging framework结合Google Protobuf消息framwework可以为您的用例提供可行的解决方案。有的语言绑定(请参阅ZMQ Java binding),您将拥有进程间和线程间通信的优化实现。 ZMQ连接以类似套接字的方式设计,支持双向(请求/回复)通信模式以及单向(发布/订阅,推/拉)。

    如上所述,消息内容的格式取决于您,但Google Protobuf可能适用于内部定义的消息协议,C ++和Java语言绑定支持这些协议。 Google Protobuf还提供了定义RPC service interfaces的机制,但您必须为客户端/服务器实现提供具体的消息传输协议。我从来没有通过ZMQ传输实现这一点,但如果有必要,它应该是可能的。

    可以考虑将XML / JSON-RPC用于已发布(例如,通过REST服务)协议(使用ZMQ可以非常容易地进行桥接)。

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

    AFAIK ZMQ符合您对Windows XP / 7平台的可移植性限制。不确定,但Windows系统上的线程间通信可能存在限制。但这似乎并不适用于您所描述的情景。

    备用传输框架:

    1. ActiveMQ
    2. Boost asio(C ++包装的原生套接字,我不知道java方面可以随意增强此信息)
    3. 备用消息/解码框架:

      1. XML-RPC C++ / java(通常假定为HTTP传输)
      2. JSON

答案 1 :(得分:1)

根据问题评论中的信息,我认为协议缓冲区需要考虑 - 它具有二进制格式,具有简单的API,并且不提供任何冗余内容,例如持久性。