有人比较过 WCF 和 ZeroC ICE 吗？

Question

ZeroC 的 ICE (www.zeroc.com) 看起来很有趣，我有兴趣查看它并将其与我们使用 WCF 的现有软件进行比较。特别是，我们的 WCF 应用程序使用服务器回调（通过 HTTP）。

有谁对比过吗？进展如何？我对性能方面特别感兴趣，因为目前我们不太关心互操作性。谢谢！

Answer 1

几年前，我对 ICE 进行了非常简洁的回顾，虽然我之前没有直接比较过它们，但对 WCF 有一定的了解，我的想法可能有一定的相关性。

首先，将 WCF 与 ICE 进行比较并不完全公平，因为 WCF 是一种特定的远程通信机制，而 WCF 是更高级别的远程通信框架。

虽然 WCF 通常被认为是实现 SOAP Web 服务，并且这确实是它迄今为止的主要用途，但它也可以用于使用各种编码和传输通道来实现远程服务，这意味着理论上它可以用于高性能通信应用程序之间。

相比之下，ICE 是一种跨平台远程通信机制，它使用二进制编码在应用程序之间进行高性能通信。它是 CORBA 的简化演变，与 CORBA、DCOM、.NET Remoting 和 JNI 更直接可比。

然而，即使 ICE 和 WCF 之间没有直接对应关系，如果您需要 .NET 应用程序进行远程通信，那么它们都是竞争者。您可能需要考虑的一些决策点包括：

• 资源配置。与 ICE 经验相比，找到具有 WCF 经验的开发人员会更容易。

• 表现。如果您想要性能，那么 ICE 执行速度很快，但 WCF 也可以在高性能配置中使用。或者，.NET Remoting 可以提供非常好的性能，无论 MS 赞助的基准测试如何，我都发现它的性能比 WCF 好 10%。

• 跨平台。如果您需要与非 Windows 应用程序通信，那么您可以使用的 WCF 选项将受到限制。此外，由于每个 SOAP 堆栈似乎以不同的方式实现标准，因此创建真正通用的 Web 服务可能会很痛苦（尽管 WS-I 有所帮助）

如果您不需要从第一天起就追求每一点性能，那么我个人会选择从 WCF 开始，然后在性能变得至关重要时再考虑 ICE。即使如此，扩展服务盒可能比迁移到 ICE 更便宜，并且如果您没有任何奇特的跨平台需求，那么您总是可以考虑重新配置 WCF 以进行二进制编码等

Answer 2

ZeroC 的 Michi Henning 最近 发表 一张白皮书 就这个主题——“选择中间件：为什么性能和可扩展性很重要（或不重要）”。它将 Ice、WCF（二进制和 SOAP）和 RMI 与各种性能指标、平台、语言等进行比较。还有更多信息关于 米奇的博客, ，但白皮书也非常具有可读性，其中包含任何基准的所有标准警告。

免责声明：我广泛使用过 Ice 和 RMI，但从未使用过 WCF。

Answer 3

阿帕奇节俭 是 ICE 和 WCF 的另一个竞争者。它由 Facebook 开发并开源。 阿帕奇节俭 在某些方面是很好的，因为它不仅在编码方面非常高效，而且还支持在不破坏所有客户端的情况下向结构添加字段（我们发现这对我们的项目非常有用）。

谷歌协议缓冲区 似乎不是一个真正的竞争者，因为它在主页上没有提到 .NET 支持。但是，一些社区插件支持 C#。此外， 冰 如果您正在使用现有服务，则为 Google Protocol Buffers 提供模拟。

Answer 4

数据点：我们刚刚将回调多平台和多语言项目从 Ice 转换为 Thrift，并取得了相当不错的结果。Ice 为您做了很多事情，因此我们必须实现断开连接侦听器、连接事件等。我们自己。在一种情况下，我们陷入了众所周知的大对象锁的困境，而 Ice 却让我们逃脱了惩罚——这导致了 Thrift 服务器中的死锁，但可以通过 C# 端不太懒惰的编码轻松修复。

我刚刚完成基准测试，在我们的应用程序中，任何推送大量数据的东西都比 Ice 更快或与之相当。具有更多开销（即通过协议更新状态的“心跳”）的较短消息会慢一些。

最重要的是，为了正确实现回调服务，我们必须扩展 Thrift 接口并定义我们自己的协议，以及 Thrift“处理器”和回调客户端-服务器。但我坦率地承认我们的应用程序/非常/特别。现有的协议和服务器应该足够了。但扩展它们，甚至使用 .Net 中的多路复用套接字，也不是非常困难。

Answer 5

我们使用 ICE 来集成用 C++、Java 和 C# 编写的模块。好处是我们的服务器也可以访问远程计算机上的组件，因此如果我们需要更高的性能，我们可以将处理转移到不同的计算机上。

我使用过 WCF 和 ICE，而且我想说 ICE 在实现方面更干净。ICE 也有非常详细且可读的文档。

ICE 支持一些 WCF 无法做到的事情，包括负载平衡、自动远程客户端更新等。