ZeroC 的 ICE (www.zeroc.com) 看起来很有趣,我有兴趣查看它并将其与我们现有的使用 WCF 的软件进行比较。特别是,我们的 WCF 应用程序使用服务器回调(通过 HTTP)。
有谁比较过吗?进展如何?我对性能方面特别感兴趣,因为现在互操作性对我们来说并不是什么大问题。谢谢!
几年前我对 ICE 做了一个非常简短的回顾,虽然我之前没有直接比较过它们,但对 WCF 有合理的了解,我的想法可能有一些相关性。
首先,将 WCF 与 ICE 进行比较并不完全公平,因为 WCF 是一种特定的远程通信机制,而 WCF 是一个更高级别的远程通信框架。
虽然 WCF 通常被认为是实现 SOAP Web 服务,而这确实是它迄今为止的主要用途,但它也可以用于使用各种编码和传输通道来实现远程服务,这意味着它理论上可以用于高性能通信应用程序之间。
相比之下,ICE 是一种跨平台的远程通信机制,它使用二进制编码在应用程序之间进行高性能通信。它是 CORBA 的简化演变,更直接地与 CORBA、DCOM、.NET Remoting 和 JNI 相媲美。
但是,即使 ICE 和 WCF 之间没有直接对应关系,如果您需要 .NET 应用程序进行远程通信,那么它们都是竞争者。您可能需要考虑的一些决策点包括:
资源化。找到具有 WCF 经验的开发人员会比 ICE 经验更容易。
表现。如果您想要性能,那么 ICE 会执行得很快,但 WCF 也可以用于高性能配置。或者,.NET Remoting 可以提供非常好的性能,无论 MS 赞助的基准测试表明我已经看到它比 WCF 高 10%。
跨平台。如果您需要与非 Windows 应用程序通信,那么您可以使用的 WCF 选项会受到限制。此外,由于每个 SOAP 堆栈似乎都以不同的方式实现标准,因此创建真正通用的 Web 服务可能会很痛苦(尽管 WS-I 有帮助)
如果您从第一天起就不需要每一盎司的性能,那么我个人会从 WCF 开始,然后在性能变得至关重要时考虑使用 ICE。即使那样,扩展您的服务盒可能比迁移到 ICE 更便宜,如果您没有任何奇异的跨平台需求,那么您总是可以考虑重新配置 WCF 以进行二进制编码等
ZeroC 的 Michi Henning 最近发表 了一篇关于这个主题的白皮书——“选择中间件:为什么性能和可扩展性很重要(和不重要)”。它将 Ice、WCF(二进制和 SOAP)和 RMI 与各种性能指标、平台、语言等进行了比较。在Michi 的博客上有更多信息,但白皮书的可读性也很强,其中包含任何基准测试的所有标准警告。
免责声明:我广泛使用过 Ice 和 RMI,但从未使用过 WCF。
Apache Thrift是 ICE 和 WCF 的另一个竞争者。它由 Facebook 开发和开源。Apache Thrift在某些方面很好,因为它不仅在编码方面非常高效,而且还支持在不破坏所有客户端的情况下向结构添加字段(我们发现这对我们的项目非常有用)。
Google Protocol Buffers似乎不是真正的竞争者,因为它没有在主页上提到 .NET 支持。但是,一些社区插件支持 C#。此外,如果您使用现有服务, ICE还为 Google Protocol Buffers 提供仿真。
数据点:我们刚刚将一个回调多平台和多语言项目从 Ice 转换为 Thrift,效果非常好。Ice 为您做了很多工作,因此我们必须自己实现断开连接侦听器、连接事件等。在一个案例中,我们遇到了一个众所周知的大对象锁,Ice 让我们侥幸逃脱——这导致了 Thrift 服务器中的死锁,但通过在 C# 端的不那么懒惰的编码很容易修复它。
我刚刚完成了基准测试,在我们的应用程序中,任何推送大量数据的东西都比 Ice 快,或者与 Ice 相当。具有更多开销的较短消息(即,通过协议更新状态的“心跳”)有点慢。
最重要的一点是,为了正确实现回调服务,我们必须扩展 Thrift 接口并定义我们自己的协议,以及 Thrift“处理器”和回调客户端服务器。但我坦率地承认我们的应用程序是/非常/特别的。现有的协议和服务器应该足够了。但是扩展它们,甚至使用 .Net 中的多路复用套接字,也不是很困难。
我们正在使用 ICE 来集成用 C++、Java 和 C# 编写的模块。好处是我们的服务器也可以访问远程机器上的组件,所以如果我们需要更高的性能,我们可以将处理转移到不同的机器上。
我已经使用了 WCF 和 ICE,我想说 ICE 在实现方面更干净。ICE 也有非常详细和易读的文档。
ICE 支持一些 WCF 不能做的事情,包括负载平衡、自动远程客户端更新等。