本文介绍使用ICE(Internet Communications Engine)中间件实现网站服务间的高效通信。通过对比XML-RPC，ICE展现出更好的性能和易用性，尤其是在跨语言支持和服务扩展方面。
ICE(Internet Communications Engine)是ZeroC提供的一款高性能的中间件，基于ICE可以实现电信级的解决方案。前面我们提到过在设计网站架构的时候可以使用ICE实现对网站应用的基础对象操作，将基础对象操作和数据库操作封装在这一层，在业务逻辑层以及表现层(java,php,.net,python)进行更丰富的表现与操作，从而实现比较好的架构。基于ICE的数据层可以在未来方便的进行扩展。ICE支持分布式的部署管理，消息中间件，以及网格计算等等。
大道理讲完，言归正传，最近育儿网新增了不少新服务，服务间经常会需要相互调用数据，例如用户中心要取博客系统里的文章啊，论坛里发文后要在积分系统里增加用户积分啊。由于设计时这些服务仅仅基于统一的用户中心，服务间基本是独立的，所以要实现这些调用只能在每个服务上新增为其它服务提供服务的服务-_-!。这个时候有几个可选方案，我们开始选择了xml-rpc，基于http和xml的选程调用，用了一段时间，发现维护成本和访问性能都存在问题。
由于这些中间服务部署的时候是和各自所属的服务部署在一起的，对这些服务做整体的改动就非常困难，要维护起来就比较麻烦。另外由于是什么http和xml作为通信协议，由php实现业务逻辑，性能问题也很明显，而且这些http请求都会在http日志留下足迹，导致我们的日志分析很不精确。这个问题不是太大，但很郁闷，所以我们考虑使用ICE来解决这个问题，至于SOAP什么的就不考虑了，同样效率低下。
实现的过程还是比较顺利，花了三天的时间用c++实现了大部分常用的接口，服务端采用deamon的方式运行，错误日志记在syslog里(/var/log/messages)，客户端PHP，编译进去了IcePHP，调用的方法很简单。现在还存在一些问题，运行的时候会异常退出，还需要一段时间来解决，暂时加了只狗看着，一旦进程里没了就重新启动。
既然要跨平台通讯，就涉及对象描述，ICE使用Slice来对结构，类，方法等进行定义。完了以后服务器端，客户端都按这个来调用和实现。ICE内置的Linux 下后台Deamon实现方案非常简单，只需要从Ice::Service里派生出一个类来，实现run方法，在这个方法里创建adapter对象，并在adapter对象里添加Servants，然后激活这个adapter就可以了，网络层的通信都由ICE接管了。由于是基于tcp/ip的直接通信，比更高层的http通信效率要高很多。
在客户端实现时，我们也碰到了一些小麻烦。一个是内置的$ICE对象用的时候有时需要用global声明，否则可能会出错，另外由于默认情况下Slice中struct对应到php的类型是一个类的实例，而不是一个数组，所以在赋值给页面的时候，smarttemplate以及其它模板系统中可能都会存在问题，可以通过修改模板系统的数据赋值显示代码解决。
我们做了一些性能的测试，同样运行1千次请求，使用xml-rpc实现需要28秒左右，使用ICE实现，只需要3秒多，性能的差距还是很大的，同时在这个过程中没发现有内存泄露的情况，效果还比较理想。
最后感慨一下，ICE是适合人类使用的中间件！
yudunde 发表于 July 6, 2006 03:39 PM | Example
以往文章
ICE-高效的中间件平台，牛刀小试
评论
ICE是个好东西，我们的项目中也用过这个。方便，入门也容易。就是更深入的使用，就要花大力气去掌握了。
我们曾经碰到过，一个服务，很长时间没有调用，就不响应了。一直调用，反而就没有问题了。此问题一直没有解决。
Posted by: 非狐外传 at July 6, 2006 09:05 PM
ICE是个好东西，真的很不错。入门也容易，就是深入使用的话，还是需要花很多的时间去掌握。
Posted by: 非狐外传 at July 6, 2006 09:08 PM
大量测试表明 ICE在效率等多方面不如ACE
Posted by: t at July 6, 2006 09:42 PM
ACE实现起来还是比较复杂，ICE的学习曲线比较好。要比起性能来虽然没做过测试，但可以想象应该还是ACE更强一些，如果花那么大的力气好不容易coding出来效率还不高就太没天理了。
Posted by: Donald at July 7, 2006 12:14 AM
ICE的效率问题估计会成为新版本最重要的改动吧。
Posted by: sunxiunan at July 7, 2006 08:08 AM
效率可能是一个考虑，但开发语言和lib的支持，又是底层平台容易推广的一个重要因素。
ICE官方就带了php，python的支持，除了c++,java这两个铁定的外，还有C#，VB。使用起来很方便。我倒是非常期待一个perl的支持。
Posted by: 非狐外传 at July 7, 2006 10:23 PM
对了，问一下t，效率的差别大概有多少？
Posted by: 非狐外传 at July 7, 2006 10:37 PM
偶也想知道ACE与ICE的性能差距的具体数据，可有人给一下下
Posted by: Anonymous at November 9, 2006 12:41 PM
ACE和ICE不好比较吧。
Posted by: cuiyanfeng at December 2, 2006 05:12 PM
请教LZ，有用过IceGrid么？
能不能写一个简单的文档阿
我一直搞不定
多谢了
Posted by: pb at December 30, 2006 10:46 AM
ICE是远程对象的封装
ACE是通讯（如SOCKET）的封装
也就是说，ACE比ICE更底层，怎么比较？
听说ICE考虑过用ACE作底层，不过因为ACE过于复杂而放弃
Posted by: 电视人 at January 7, 2007 02:50 PM
楼上所言恰当。
ICE侧重于远程RPC解决方案，而ACE是通用网络编程框架。
在应用层面上，ACE所处位置比ICE要低。
基于ACE的CORBAR实现TAO和ICE倒是可以比较比较
Posted by: Robinson at January 18, 2007 05:10 PM
ICE是与CORBA，.NET Remoting,Web Service同层次的东西，ACE是个网络编程库，准确的说是个C++对Socket网络操作的封装。而ICE是个RPC与DO（分布式对象）的协定，与语言没有关系，这一点和CORBA，Web Service，.NET Remoting相同，但ICE更简单。需要注意的是，.NET Remoting只能由.NET支持的语言实现，也是非常棒的RPC解决方案。
大道理讲完，言归正传，最近育儿网新增了不少新服务，服务间经常会需要相互调用数据，例如用户中心要取博客系统里的文章啊，论坛里发文后要在积分系统里增加用户积分啊。由于设计时这些服务仅仅基于统一的用户中心，服务间基本是独立的，所以要实现这些调用只能在每个服务上新增为其它服务提供服务的服务-_-!。这个时候有几个可选方案，我们开始选择了xml-rpc，基于http和xml的选程调用，用了一段时间，发现维护成本和访问性能都存在问题。
由于这些中间服务部署的时候是和各自所属的服务部署在一起的，对这些服务做整体的改动就非常困难，要维护起来就比较麻烦。另外由于是什么http和xml作为通信协议，由php实现业务逻辑，性能问题也很明显，而且这些http请求都会在http日志留下足迹，导致我们的日志分析很不精确。这个问题不是太大，但很郁闷，所以我们考虑使用ICE来解决这个问题，至于SOAP什么的就不考虑了，同样效率低下。
实现的过程还是比较顺利，花了三天的时间用c++实现了大部分常用的接口，服务端采用deamon的方式运行，错误日志记在syslog里(/var/log/messages)，客户端PHP，编译进去了IcePHP，调用的方法很简单。现在还存在一些问题，运行的时候会异常退出，还需要一段时间来解决，暂时加了只狗看着，一旦进程里没了就重新启动。
既然要跨平台通讯，就涉及对象描述，ICE使用Slice来对结构，类，方法等进行定义。完了以后服务器端，客户端都按这个来调用和实现。ICE内置的Linux 下后台Deamon实现方案非常简单，只需要从Ice::Service里派生出一个类来，实现run方法，在这个方法里创建adapter对象，并在adapter对象里添加Servants，然后激活这个adapter就可以了，网络层的通信都由ICE接管了。由于是基于tcp/ip的直接通信，比更高层的http通信效率要高很多。
在客户端实现时，我们也碰到了一些小麻烦。一个是内置的$ICE对象用的时候有时需要用global声明，否则可能会出错，另外由于默认情况下Slice中struct对应到php的类型是一个类的实例，而不是一个数组，所以在赋值给页面的时候，smarttemplate以及其它模板系统中可能都会存在问题，可以通过修改模板系统的数据赋值显示代码解决。
我们做了一些性能的测试，同样运行1千次请求，使用xml-rpc实现需要28秒左右，使用ICE实现，只需要3秒多，性能的差距还是很大的，同时在这个过程中没发现有内存泄露的情况，效果还比较理想。
最后感慨一下，ICE是适合人类使用的中间件！
yudunde 发表于 July 6, 2006 03:39 PM | Example
以往文章
ICE-高效的中间件平台，牛刀小试
评论
ICE是个好东西，我们的项目中也用过这个。方便，入门也容易。就是更深入的使用，就要花大力气去掌握了。
我们曾经碰到过，一个服务，很长时间没有调用，就不响应了。一直调用，反而就没有问题了。此问题一直没有解决。
Posted by: 非狐外传 at July 6, 2006 09:05 PM
ICE是个好东西，真的很不错。入门也容易，就是深入使用的话，还是需要花很多的时间去掌握。
Posted by: 非狐外传 at July 6, 2006 09:08 PM
大量测试表明 ICE在效率等多方面不如ACE
Posted by: t at July 6, 2006 09:42 PM
ACE实现起来还是比较复杂，ICE的学习曲线比较好。要比起性能来虽然没做过测试，但可以想象应该还是ACE更强一些，如果花那么大的力气好不容易coding出来效率还不高就太没天理了。
Posted by: Donald at July 7, 2006 12:14 AM
ICE的效率问题估计会成为新版本最重要的改动吧。
Posted by: sunxiunan at July 7, 2006 08:08 AM
效率可能是一个考虑，但开发语言和lib的支持，又是底层平台容易推广的一个重要因素。
ICE官方就带了php，python的支持，除了c++,java这两个铁定的外，还有C#，VB。使用起来很方便。我倒是非常期待一个perl的支持。
Posted by: 非狐外传 at July 7, 2006 10:23 PM
对了，问一下t，效率的差别大概有多少？
Posted by: 非狐外传 at July 7, 2006 10:37 PM
偶也想知道ACE与ICE的性能差距的具体数据，可有人给一下下
Posted by: Anonymous at November 9, 2006 12:41 PM
ACE和ICE不好比较吧。
Posted by: cuiyanfeng at December 2, 2006 05:12 PM
请教LZ，有用过IceGrid么？
能不能写一个简单的文档阿
我一直搞不定
多谢了
Posted by: pb at December 30, 2006 10:46 AM
ICE是远程对象的封装
ACE是通讯（如SOCKET）的封装
也就是说，ACE比ICE更底层，怎么比较？
听说ICE考虑过用ACE作底层，不过因为ACE过于复杂而放弃
Posted by: 电视人 at January 7, 2007 02:50 PM
楼上所言恰当。
ICE侧重于远程RPC解决方案，而ACE是通用网络编程框架。
在应用层面上，ACE所处位置比ICE要低。
基于ACE的CORBAR实现TAO和ICE倒是可以比较比较
Posted by: Robinson at January 18, 2007 05:10 PM
ICE是与CORBA，.NET Remoting,Web Service同层次的东西，ACE是个网络编程库，准确的说是个C++对Socket网络操作的封装。而ICE是个RPC与DO（分布式对象）的协定，与语言没有关系，这一点和CORBA，Web Service，.NET Remoting相同，但ICE更简单。需要注意的是，.NET Remoting只能由.NET支持的语言实现，也是非常棒的RPC解决方案。
扫一扫
755
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
