我应该使用 CORBA、MessagePack RPC 或 Thrift，还是完全使用其他东西？答案

【问题标题】：Should I use CORBA, MessagePack RPC or Thrift, or something else entirely?我应该使用 CORBA、MessagePack RPC 或 Thrift，还是完全使用其他东西？
【发布时间】：2011-04-03 06:30:53
【问题描述】：

我正在为新的硬件设备编写软件，我希望任何类型的新第三方应用程序都能够访问它。

该软件将是一个本机进程 (C++)，应该可以被想要支持硬件设备的第 3 方游戏和应用程序轮询。这些第 3 方应用程序还应该能够在订阅的基础上接收来自本机进程的事件。因此，除了本机进程之外，我还将为第 3 方开发人员提供“连接器”库，用于他们可能选择的所有平台/语言（Java、C++、Python 等）嵌入到他们的应用程序中，以便他们可以轻松连接到设备几乎不需要他们编写任何额外的代码。我想针对所有台式机/笔记本电脑操作系统平台，并且对我想要公开的功能有一个很好的了解，但理想情况下我不想太卡住（即我希望它可以从客户端和服务器优雅地扩展观点）。

我正在寻找未来的可靠性、性能、可维护性，以及跨平台/语言的灵活性，以及易于开发，按此顺序。

我应该使用什么？

CORBA、MessagePack-RPC、Thrift 还是其他？

（由于许可，我省略了 ICE）

【问题讨论】：

CORBA 是古老的。它也是重量级和过时的。几乎可以肯定有更好的解决方案。
skaffman，古代、重量级和过时的形容词根本不会让我失望。每个 ORB 的内存量只有几兆字节，这对于嵌入式来说可能很糟糕，但对于台式计算机来说绝对没问题，而且性能很快。我关心的是性能速度、跨平台灵活性、易于开发、可维护性和未来的可靠性。只要它在这些部门中总体上是最好的，其他人对此有何“想法”并不重要，也不必是“最新时尚”，它就会赢。我只是想知道这是否最适合我正在做的事情。
也感谢您的回答，我已经编辑了问题。谢谢。
这不是 stackoverflow 的真正问题。您可以使任何这些技术发挥作用。这个问题太主观了。对你最好的东西可能对其他人不是最好的。您需要做的是做一些功课并尝试其中的每一项，然后自己判断最适合您的应用程序的方法。

标签： cross-platform rpc corba thrift interprocess

【解决方案1】：

如果古代和重量级不让你失望，过时的绝对应该。无论如何，我可以告诉你我们最近在工作中一直在使用 Google Protocol Buffers，它们非常易于使用。

从开发人员的角度来看，您需要做的就是构建 GPB（这实际上并不难），然后它会为您生成源文件。最终结果是一个跨平台的二进制消息传输消息传递接口（想想 XML 和有限的 RMI，而不是类似 MPI 的功能）。

我们在 Windows 上使用它与运行相同软件的基于 Arm 的 Linux 系统（来自嵌入式 arm 的 TS-7200）通信。据我所知，它与多种语言兼容。

【讨论】：

这是消息吗？很有意思！鉴于灵活性，你会如何建议我在我的情况下使用 protobuf？我知道这是“随你喜欢”，但我希望我系统的每个新部分都与每个旧部分向后兼容。（这是展望未来 - 我还没有开始）。实现这一目标的最佳方法是什么？
如果你进行谷歌搜索，你可以在他们的 repo 中找到一些文档，其中包括一些最佳实践。这真的取决于你的具体情况。这不是严格意义上的消息传递。它是一种跨平台/跨系统的二进制序列化方法。如果您只希望它用于数据传输，您可以这样做。如果你想构建一个 RMI 框架，你可以这样做。

【解决方案2】：

CORBA 是目前唯一适用于我的系统的免费“RPC”东西，尽管它的扩展性非常糟糕。 Thrift 还不是 Windows 友好的。 MessagePack-RPC 还没有在所有语言和操作系统中可用，即使它仍在开发中。如果 CORBA 具有优雅的可扩展性，它可能根本就不会过时。

协议缓冲区和消息传递可以工作，我必须为每个平台/语言开发一个客户端和服务实现。它也将是非常可扩展的。我已经决定了。

【讨论】：

为什么您认为 CORBA“扩展性非常差”？当今有大量使用 CORBA 的大容量系统。
添加一个新属性，当人们在新服务器上使用旧客户端，或者在旧版本服务器上使用新客户端（在我的情况下两者都可能）时，这是否在 CORBA 中优雅地处理？我的印象是 CORBA 坏了。这很糟糕——它不必是这样的。如果 CORBA 能够无缝地处理附加和删除属性和函数，它就会征服世界。人们总是希望更新他们的架构：任何需要的版本控制、约束和处理都应该是 CORBA 之外的开发人员的工作。 RPC 本身应该是 100% 可扩展/可扩展的。
没有多少 RPC 系统可以无缝处理版本控制。原因之一是它会在每个 CORBA 调用上产生过多的开销。

【解决方案3】：

Thrift 或 Message Pack 是未来的最佳选择。两者都很时尚，重量轻，不会给您的流程增加太多延迟。它们支持大多数常用语言，并且处于主动开发中。在当前阶段，我个人更喜欢节俭，但消息包似乎确实承诺了很多功能。

Thought thrift 可能不像我们想要的那样对 Windows 友好，但人们正在 Windows 上使用它。这是 Windows 上节俭的入门指南。 http://wiki.apache.org/thrift/ThriftInstallationWin32 只有在 Windows 上安装和获取 Thrift 编译器会很麻烦。使用生成的文件取决于您选择的语言，并且许多语言都很好地支持通过导入 thrift 库来运行文件。（Java很简单，MAVEN神器）

RPC frameworks available? 上有关于 RPC 框架的讨论

在我看来，CORBA 很笨重，而且非常重量级。

【讨论】：

【解决方案4】：

我目前正在将 Apache Thrift 用于 Hospital Manager 项目。它在许多方面都优于 CORBA，更不用说它是轻量级的，而且更容易实现和理解。与 CORBA 相比，Thrift 的学习曲线绝对是微妙的，但 Thrift 的文档是最糟糕的。

我正在使用 Obj-C 和 Java 客户端连接的 Ruby Thrift 服务器。 Thrift 解析器或“编译器”可以很好地为您想要的语言生成源文件，尽管它过于冗长。如果我开始一个新项目，我肯定会考虑实施 Thrift 或 Google ProtoBuffs，因为 CORBA 确实已经过时，并且将来可能不会实施新技术，更不用说针对 CORBA 的许多漏洞和利用不会得到补丁，因为它不再处于开发阶段，这会给你的新项目带来一些严重的安全漏洞。

截至撰写本文时，Thrift 支持多种编程语言：C++、Java、Python、PHP、Ruby、Erlang、Perl、Haskell、C#、Objective-C、JavaScript、Node.js、Smalltalk、OCaml 和 Delphi。我认为，对于您的项目而言，支持多种语言是关键。

【讨论】：

我最终选择了 ZeroMQ。你可能想检查一下。这真的很酷，因为您可以随意扩展它（在添加/删除属性等方面）。