ZEROC究竟是何方神圣？
本文整理自《ZeroC Ice权威指南》作者Leader-us针对网友提出的ZeroC 问题的解答。
1、RPC又是炒冷饭？？
Leader-us：
RPC的确是炒冷饭，但彼一时，此一时。 现在这个江湖早已不是过去那个江湖了。移动设备早已吞噬PC市场，原先为应付移动设备兼容而开发的网页模式的应用逐渐下架，App要界面好看，速度要快，要安全，要省流量，所以，RPC又重新引起大家的重视，现在90%的人都认为Rest没有技术含量，沦为大路货了，但90%的人都觉得Thrift是高大上的技术，在市场驱动下，RPC这个炒冷饭的技术，还真是一盘大餐！
2、Ice到底是个什么东东呢？有什么用处？
Leader-us：
分布式系统的通信，要么RPC，要么消息队列机制，而且RPC方式的代码通常要占到一半以上。 如果一个系统比较复杂，需要N个服务之间有调用关系，那么这就是一个通用的技术问题，简单的说，就是服务治理/服务总线平台，涉及到服务注册、负载均衡、故障处理、服务扩容、以及最后的RPC调用功能，这些能力都具备的，而且是开源的，目前基本只有Zeroc Ice与 阿里放弃的Duboo，而Zeroc Ice则有超过10年的历史，不断更新，不仅仅支持服务器端的RPC调用，也支持移动设备。 Ice的好处，可以用Java，C++，C#，Python等语言开发服务端，然后大家可以相互通信，最后这些服务组成一个系统，还能被7种语言写的客户端调用，包括PHP，Javascript，不仅仅是网页程序调用，还能移动设备上调用。对于互联网/App开发，节省了80%的工作量.
3、这个Zeroc Ice 与 Thrift 还有 Avro 相比 有什么优缺点?同时Thrift 还有 Avro 在大数据及互联网应用广泛且都有成熟案例，Zeroc Ice如何进入这个圈子？
Leader-us：
我们要看看究竟是谁进谁的圈子，这个问题需要弄明白。 RPC技术最早是由SUN引领并成为标准规范的，后来就产生了一个问题，不同厂家的硬件、软件、不同的开发语言之间如何能进行“标准化”的通信？ 当时微软有自己的DCOM技术，SUN 有自己的J2EE/RMI技术，这些都局限于一个小圈子里，于是COBRA成为第一个吃螃蟹的，一大群专家坐在一起，制定了一个跨语言、跨操作系统、跨硬件平台的“宏伟”目标。 但可惜最终这个宏大目标没能实现，由于规范过于庞大、开发中间件的厂商没有人能100%准确理解和遵循规范，导致各种兼容性问题，最终COBRA走向没落。 COBRA没落之时，出现两个分支，其中一个是COBRA领域的资深专家们，这里主要是技术派专家，而非吹水派专家，看到了COBRA失败的本质原因，也很痛心这个伟大尝试的失败，于是他们抱团，成立了 Zeroc公司，开始了破冰之旅，从而诞生了Ice这个跨平台、跨语言、高性能的RPC平台——他们称之为反叛之冰。 这里顺便说下COBRA的没落的一个重要原因：对于中间件和平台这样的技术，产品本身的质量和功能远远超过一纸规范，没有意识到这个问题而导致失败的例子很多，网景公司的JavaScript最终不低微软的JS，SUN的 J2ME最终也让位于谷歌的Android。 Zeroc公司就吸取了这个教训，他们自己实现ICE平台的各个语言的Runtime，包括Java版本的、C版本的、Python、PHP，而且十几年来一直不断完善，移动设备上，Android，IOS都提供Runtime包，因此，连SUN、Borland都倒下了，Zeroc公司仅靠Ice一个产品，屹立至今，试问IT界里，这样的技术型公司还有几个？ COBRA没落的同时，IBM主推的Webservice/SOA这条线发展下去了，他们也借鉴了COBRA的精华，比如WSDL其实就是IDL，但这个路也没能光大下去，很快被Rest/JSON替代，然后这里就没有平台的说法，都变成了API。 由于Zeroc Ice的存在，所以在多语言、高性能的RPC领域，一直没有什么其他产品和开源项目，直到最近，由于移动设备对远程通信性能和流量的要求提升，同时互联网开发中多语言协作的增多，于是RPC技术重新被大家重视，谷歌释放出开源的Protocol Buffers表明其RPC方面的领先性，Facebook则更开放的把Thrift这个框架开源出来，而Avro则是因为Hadoop之父（Avro是Hadoop里的一个组件演化而来的） 看不惯Thrift的思想而打造的一个框架，此框架目前仍然是“半成品”。 与Zeroc Ice相比，Thrift其实只能算作一个FrameWork，而Ice则是一个Platform，另外从成熟度、稳定性等方面来对比，都不是在一个层面上的，目前开源的唯一一个工业级的RPC平台，只有Ice， Ice的性能不用说，其稳定性更是有目共睹，因为最早很多电信级别的客户使用它。大名鼎鼎的Skype也是用它，国内也不少公司默默的使用。 以下是我对Avro的一个测试研究： •Apahce Avro框架简单，非接口编译的模式灵活度很高，用Json定义的RPC消息结构和方法简单并容易理解 •Http协议的编码和传输机制效率远远低于长连接的Socket模式，本机对比了Avro的Http协议与Netty实现的Socket协议，请求应答消息相同的情况下，HTTP的TPS是500左右，而Netty Socket模式则是1.5万左右，相差很悬殊，同样的接口，ICE的TPS则达到2.5万TPS！ •多语言客户端支持并不是那么容易的事情，Avro的Phyton客户端目前只实现了基本的Http协议，（Java的同时实现了Neety客户端协议），这种情况下，服务端只能也采用Http协议，从而导致并发性能问题.
4、有没有比较形象一点的比较呢，比如说在实际使用过程中会体现的一些优点，能有几个粗略的数据对比会更加清晰一些啊
Leader-us：
直观的几个好处举例如下： 以使用最多的语言Jar为例，Ice核心Jar包就一个，100多个类，总共几百K，不依赖任何其他第三方包，不容易引发包冲突，因为包很小，所以手机上的APP就能打包很小，快速下载，这很重要。 如果系统比较简单，只是几个服务的远程调用，除了业务代码，Ice相关的编码也就几十行，容易上手，不用注册中心的方式，比Java RMI还简单 常见的互联网应用，涉及到PHP、Java、C (ios)，一个Java开发的Ice服务，互联网Web，Android，苹果手机，都搞定了，成本和代价很小 如果涉及到安全问题，客户端从TCP改为SSL，则只要改Ice配置即可，不用改程序，而且一个Ice服务可以同时提供TCP和SSL两种访问端口，也只是配置就解决了。 最后，如果系统比较复杂，几十个上百个服务，涉及到复杂的服务调用，负载均衡问题，那么升级为IceGrid，定义一个XML文件，秒杀了服务的部署拓扑，只要用控制台命令发布即可， 不像Jboss这种系统，需要手工到每个Jboss下 起停等繁琐工作。 总之，可以很简单的使用，也开业很高大上的使用，这就是Zeroc Ice。网上有一个有趣的帖子，有个人说 他认为每个软件都有自己的缺陷，但是Ice，他一直没找到缺陷。
5、在接口调用方面，我用过webserivce SAP的RFC，效率和可移植性均不强。现在的平台太多了，而流量和效率是最需要考虑的方面，
1.RPC的效率应该是没的说，
2.有个问题，Ice的底层是不是也是对OS的API socket的封装？
Leader-us：
Ice 底层也是Socket通信，使用了NIO最佳模式，比Netty实现的Avro （Apache主席，Hadoop之父的新作） 高出近一倍，相同的接口，Http 接口实现的Avro RPC是 500 TPS，Netty 版的Avro 是1.5万TPS，Ice则高达2.5万。有人根据Ice权威指南里的例子，对比了Duboo，发现Ice比Duboo性能高4倍左右。 Ice对外宣传的是，高性能，多语言，跨平台，非常稳定。排在第一的是高性能，这是其十年来不断完善与进化的结果，如果你能10年磨一剑，那也是倚天剑了。
6、请问ACE和ICE有什么区别？从架构层面和设计方面，而不是代码（ACE的代码公认的烂，为设计模式而模式）
Leader-us：
ace是对c++基础开发接口和功能的封装，提高了程序的可移植性，并且提供了很好网络类； ice是分布式框架，提供了消息分发、对象定位、远程调用等功能的实现。 ACE 可以理解为是一个API，而且是面向C++ 的ICE可以理解为一个Platform，是多语言的RPC平台两者不是一个层面的东西另外，Ice又称之为反叛之冰，是当初参与COBRA的一帮资深大牛另起炉灶的产品，团队的实力和影响力都是只能仰望的高人，用流行的一个句话来比较，Ice完美秒杀ace.
