摘自： http://weibo.com/p/1001603869896789339575
原文地址： http://www.oschina.net/question/865233_242146
随着移动互联网的迅猛发展，HTTP REST 这种曾经风靡一时的低效的远程通信技术已不再风光，而多语言支持的高性能 RPC 技术再次王者归来。Facebook Thrift 一经开源即引起轰动，Hadoop 父兼 Apache 主席的 Doug Cutting 也耐不住诱惑，开放了他在 Hadoop 里研发的创新性的 RPC 框架—— Avro。而作为唯一平台级的开源产品，此次话题的主角—— ZeroC Ice 正在低调地进军互联网领域。
精彩问答
@坚持住：ZeroC ICE 有什么用？
@mycat：ZeroC ICE 手机端开发也非常有用，Android/IOS都支持，一个Ice服务，不管是 Java 开发也好，C开发也好，Web 端、Android/IOS 都一样的调用方法，Ice是全栈工程师/架构师最好的搭档。
@lxitgto：我们4年前开始使用 Zeroc ICE，从 3.4 用到 3.5，期间也是掉过无数的坑。严重吐槽一下ICE的官方文档，感觉不是英文为母语的人写的。我很好奇国内还有哪些项目使用了 ICE？成功案例？
@mycat：Ice的官方文档总共大概1000多页，写的是很详细，但详细不代表着容易理解，这是因为几个原因，首先，它是开源的，所以依赖服务盈利，公开的文档要“闪烁其辞"，第二，Ice里面有很多概念和术语，需要理解这些术语，才能很好的掌握Ice，而绝大多数使用者一上来就急于编码写Demo，没有时间仔细学习和研究，导致后期发现很多”坑“，而Ice至今没有一本详细指导开发实践的书籍，这更增加了掌握它的难度。
Ice在国内，最早有腾讯、以及一些电信软件开发公司使用，后来有部分互联网企业用，据说有人人网等公司使用，接触过一些电信软件开发的相关人员，反馈是Ice非常稳定可靠，这与其经久考验的代码质量密切相关，其官网上，Skpye的案例不用说了，还列举了宝钢这个客户。
@nullptr：最近学习ICE几天了,有点疑惑,不知道问题是不是太低级了,但是现在确实卡在这里了,若能回复下,不胜感激:
1:在官方的demo中,ice 回调模式只有read/writer(proxy),但是proxy这个类貌似没有写入数据的地方,所以我像问下在callback模式中怎么去设置发送的数据呢?
2:在官方demo中Glacier2模式的callback中,有个这个文件:config.glacier2.(就是除了server,client配置之前的另一个配置文件,配置的)网上说启动这个文件,但是不知道如何启动(windows);
3:能不能推荐个这方面的网站,因为我除了官方的没见过其他的文档和论坛,资料太少了..
@mycat：Ice回调模式有两种，一种是传统的回调模式，你传递一个接口实现类，它来调用你；另外一个是你去探测异步调用是否完成，完成后获取返回结果，这个在书里貌似写了的，两种用法各自有其用武之地。 IceBox以及IceGrid是学习重点，也是Ice精华，建议先学这部分。
@Carvendy：性能测试 报告什么可以看看吗？和其他 工具性能差异，优势到底在哪里呢？
@mycat：Ice最早是即时通讯和在线游戏项目中所用，追求性能和稳定性是其重要目标，Hadoop作者看不惯Thrift而开发的新的RPC框架Avro也很不错，采用了Netty做通信，据说性能跟 Thrift有的一拼，但它只在Java里用了Netty，其他语言用HTTP通信，请求应答消息相同的情况下，HTTP方式的TPS是500左右，Netty模式是1.5万左右，Ice则是2.5万
@pj220：ICE 在嵌入式的windows CE系统下，目前仅支持ARM处理器，我想知道如何将ICE移植到MIPS处理器上？
@mycat：它的源码是开放的，另外，查询到一些资料，表明应该是可以在MIPS上编译和支持的：zeroc-ice (3.0.1-2) unstable; urgency=low * Patch for MIPS support was incomplete (Closes: #357899). * Added compilation fix for Alpha (Closes: #358488).
@leoxu：您好，请问开头介绍中为什么说“HTTP REST 这种曾经风靡一时的低效的远程通信技术已不再风光”，可以给我们大家分析分析吗，谢谢
@mycat：关于HTML5在移动设备上的被Native方式的App所替代，这个现象应该大家都有所耳闻，最著名的是Facebook事件，而引发Rest VS RPC通信的则是知名的印象笔记 这款APP，他们还写过一个架构说明，为什么用RPC，总结下来，原因有几个：高性能，传输数据量大幅压缩，安全，保持技术优势（RPC门槛高于REST），以及APP的安装包缩减
@Gogo58：我们公司现在都在用ice ，感觉ice的分布式的方式不是很难，我们是用javaweb的项目，感觉ice的.ice 文件配置不是很方便，端口号每次从svn下载要改好
@mycat：估计是没有用IceGrid，如果用这个，就不存在改端口的问题，而且部署更方便了
@风--：简单用过，最大的优势是支持多语言，很不错！！
@mycat：最简单的使用，只用Ice RPC，Java方面就一个Jar包，C方面就一个.so或dll运行库，很容易嵌入程序，没有复杂的第三方依赖。
@SimonYe：我们正在用 dubbo，我想请教的是： Avro 与 dubbo 同为 RPC 框架，有啥差别，应用场景有啥不同，谢谢。
@mycat：Avro目前算是一个API框架，dubbo算是一个PRC平台了，但由于只支持Java，以及是阿里内部一个项目，对比Ice，一个是公司级的，一个是世界级的，另外，dubbo被放弃了，而Ice 刚刚又推出了3.6版本，所以，选择哪个，就在自己了。
@chencliff：以前用过ice，后来发现复杂度实在是太高，项目组大部分成员都停留在入门阶段，很难转化为生产力。并且出错后查找错误所在也是一个考验。后来就转到其他技术上了。
@mycat：需要有一个人比较深入的掌握Ice，搭建框架和测试环境，其他人则不需太多了解，按照规范开发即可，可以节省很多工作量。
Ice的日志其实很详细，但很多人都不知道日志在哪里放着，怎么控制日志级别
@hakuyo：只说一点基本通信方面的理解吧，感觉在基本通信方面（不涉及穿防火墙等其他高级的功能），ice=poco+protobuf，有印象ice好像要支持protobuf
@mycat：说的不错，但Ice最强大的是IceGrid，动态伸缩，平滑扩容，方便部署和升级，目前的docker/Kubernate也借鉴了其思想
@Sub：ICE 现在又流行了？ 记得 05年的时候开始接触使用了1~2年，虽然比 CORBA 之类的跨语言RPC通讯好用很多，但是还是感觉繁琐，后来就弃用了。
@mycat：因为要跨语言，所以需要有一个中间接口，考虑到实际通信中为每个语言开发一个客户端的代价，因此这个步骤还是能接受。如果你只用RPC通信，而不用IceGrid的强大分布式网格，你会觉得他比Rest等方式要繁琐，有代价。它的精华在于，哪怕只有3个人的团队，也能依赖IceGrid，做一个App，一个Web，一个强大的分布式系统。
@wlyhqm2006：请问MyCat都使用了哪些ICE的技术
@mycat：Mycat本身是数据库中间件，没有用到Ice，但新的一个开源项目，Mycat开放电商架构平台，则是Zeroc Ice+Mycat+Zookeeper+MQ+ES，组成一个强大先进的电商平台。
@billow：腾讯MIG有个叫做 taf 的框架，貌似是基于ICE完全重新开发的一套框架
之前也看过一点ICE的东西，感觉在互联网方面的应用不多啊，反倒是thrift或者基于pb的rpc方式更加流行昵，"ZeroC Ice 正在低调地进军互联网领域"这句话能展开说说么？
@mycat：因为腾讯很早就用Ice的，所以模仿开发一个，是很正常的。RPC技术，特别是多语言，多平台（服务端、移动设备）支持的RPC技术，正在互联网应用中兴起，这个是不争的事实了，因为互联网应用里是最多遇到多语言开发，多平台支持的需求领域。REST等HTTP技术性能低、传输数据量大、安全性低，门槛低，这是其根本问题。
Thrift 目前也只能算是一个RPC框架，但服务治理这部分还缺乏，团队需要额外的很多开发投入，才能达到ICE平台的目前的功能。
@myw31415926：以前公司也用过一段时间的ACE，但是那个ACE太大了，调用比较复杂，入门感觉很有难度。请问ICE会有这样的问题吗，它与ACE比较，有哪些优势？对ICE的学习需要深入到源码级吗，还是只需要熟悉接口调用就可以了？谢谢您的回答！
@mycat：Ice RPC很简单，无需深入源码，IceGrid很强大，只要理解了其 术语、原理、模型即可熟练使用，整体上Ice很轻量级，团队有人搭建环境，其他人遵循规范开发即可。https://github.com/MyCATApache/Mycat-openEP 这个开源项目里做了一个IceGrid的Docker镜像，10分钟入门。
@test_30rl：请教一下如何使用 Ice 进行流式数据传输的支持哈，之前用protobuf的时候，发送二进制数据用的是 bytes 类型，但是不是基于流的，所以数据比较大的时候会有问题。
@mycat：TCP流式传输，都是把数据分成自定义协议报文的方式传输的，100G文件发送也没有问题，多看看RFC中TCP上的应用协议，就明白了。另外，Ice专门有文件传输的例子的，可以直接拿来用
@李烈火：ZeroC Ice 究竟是何方神圣？
@_zhanggx：分布式系统的通信，要么是RPC，要么是消息队列机制，而且RPC方式的代码通常要占到一半以上。如果一个系统比较复杂，需要N个服务之间有调用关系，那么这就是一个通用的技术问题，简单地说，就是服务治理/服务总线平台，涉及到服务注册、负载均衡、故障处理、服务扩容、以及最后的RPC调用功能。
这些能力都具备的，而且是开源的，目前基本只有Zeroc Ice与 阿里放弃的Duboo，而Zeroc Ice则有超过10年的历史，不断更新，不仅仅支持服务器端的RPC调用，也支持移动设备。
Ice的好处是，可以用Java、C++、C#、Python等语言开发服务端，然后大家可以相互通信，最后这些服务组成一个系统，还能被7种语言写的客户端调用，包括PHP、Javascript，不仅仅能被网页程序调用，还能在移动设备上调用。对于互联网/App开发来说，节省了80%的工作量。
这个是@mycat老师在其他活动中回答的哈，鄙人摘抄了过来
@茶哥强大：http://www.infoq.com/cn/articles/netty-high-performance/这篇文章中netty优化到10w tps，zeroC ice能做到吗，还有zeroC ice内部机制是不是nio，有没有压缩功能
@mycat：Netty并不代表着极限性能，Apahce Avro 是Hadoop之父的RPC开源新作，也是用了Netty，但我做过对比，同样的接口方法，Avro 性能为1.5万每秒，远远高于HTTP的，但Ice则是2.5万每秒。软件设计中：通用性是以牺牲性能为代价的。从这个方面也能解释 Zeroc Ice的NIO高于Avro 的原因。
@水母干：想知道下要多大规模的项目才会上ICE?之前一个项目一开始打算用ICE作为RPC框架的,到后面考虑到用户量并不会多到哪里去,而且文档实在是太难读了,就换Thrift了
@mycat：如果有5个以上服务是分布式的，而且有相互调用关系，并且会很快扩展增加新的服务或者扩容，那么就建议Ice，因为分布式系统中代价和工作量大的是扩容、负载均衡、容错机制，用Thrift的话，这些都要自己去开发，用IceGrid，这都是现成的功能。
@zhaoy168：RPC开发门槛高，降低开发成本和业务快速迭代是互联网最大的需求。
高高在上的RPC可能更适用于对性能细节要求非常高的场合，比如电信或银行的内部调用。
在移动端，REST还会是主流。在方便的RPC工具出现前，RPC在移动互联网的普及还有很长的路要走。
@mycat：RPC的门槛其实不高，特别对于调用者来说，比Rest方式还低的门槛，而服务开发方面，也只高了一点点，好处是更加面向服务接口，IDL/SLICE语言定义中立的服务接口，而不是随意的定义服务和服务接口，导致最后系统混乱到无法掌控，如果还认为Rest是一点端主流，就去看看印象笔记的公开的架构说明吧。
@Gogo58：我想问一下ice 都是使用了哪几种设计模式
@mycat：Proxy模式是RPC系统共用的最主要的设计模式之一，其他如Factory模式也比较常用。很多“工具类”则使用了单例模式，其他的模式则需要去代码中发掘了。
@Gogo58：ice在做分布式部署的实施的时候要注意什么
@mycat：服务粒度的问题，过大过小都不合适。服务接口要具有前瞻性，即考虑到可能增加的参数，尽量通用性服务之间的关联问题，非常频繁调用的服务，建议部署在一起（一个IceBox里）
@purely：icegrid -> node->server 和 icegrid -> node-> icebox 这2着有什么区别吗？
@mycat：这里的一个Server就是一个IceBox进程，逐一区别于Ice Servant（Server中的一个Ice服务）
@purely：servant是作为一个服务对象让客户端使用的，客户端获取一个servant（ice.object）的一个远程代理来调用。
那么servant的编写上，是否要遵循无状态或线程安全，才能够保证调用的线程安全？
@mycat：是的，Servant的编写需要遵循线程安全，无状态服务也是很久之前大家达成的共识，容易负载均衡、故障恢复。
@天天顺利：ZeroC Ice 相对于其他RPC架构有哪些优化？同时，ZeroC Ice的性能测试的关键参数有哪些？
@mycat：NIO 和字节顺序方面作了很精心的调整，其官方有关于Big-Endian与Little-Endian的讨论，这个问题几乎在其他地方找不到，说明其深入和细致程度。性能方面，主要有线程池大小、超时时间、连接缓存、“本地服务”之间相互调用的优化问题等。
@Gogo58：使用ice做秒杀之类的高并发的系统的设计有没有什么要注意的
@mycat：Ice PRC只是一个通信手段，秒杀之类的高并发的系统，需要好好利用和设计IceGrid，增加服务实例的数量和并发承受能力，并且确保每个服务的相应时间尽量缩短，才能抵抗高并发的请求压力，比较好的一个模式是Ice收到请求以后，简单处理后放入Redis/MQ等中间件，异步处理
@小M武毅：公司在使用Ice，对比过和thrift的性能，thrift在性能上有较高优势，但Ice在集群管理方面有较完善的机制。在使用IceGrid基本都是一点点试出来的，是否有针对互联网服务的详细使用说明
@mycat：这本书里有一个Android App 调用Ice服务的例子。客户端无论是App还是Web，调用起来都没有区别，区别在于App的TCP连接相对速度更低，需要注意数据量的传输问题，比如避免文本传输，而用压缩的二进制，另外，要快速返回结果，多用异步的交互模式。
@流沙河鱼：目前dubbo和dubbox在各大互联网公司使用的很普遍了，如何说服这些人从dubbo转移到ice上面来，可能还需要向这些技术人员说明ice的性能和可靠性以及其他方面的优势，并这些人认识到ice框架的好处和优势，很多人多这个框架和技术是比较陌生的
@mycat：老项目老办法，升级和新项目则迁移。架构师是起领头作用的，如果架构师都不懂，那么团队里推动就难了，不管怎样，先学会使用，以便决策的时候多一个选择，是比较靠谱的方法。
@杨延庆：之前在一个android的项目上用过的，用于android程序和java服务器之间进行通信，但是对于大数据量的发送处理不是很好，我24小时的采集程序，传给底层的ICE发送后，很容易造成阻塞，弄得我接收传感器信息后不敢存临时队列，必须直接发送，对于这块Java 的ICE调用，有没有什么好的建议呢
@mycat：RPC接收消息，如果涉及到复杂的消息处理，特别是耗时比较多，则可以放入合适的消息队列，消息队列的选择也影响很大，比如Kafka的性能通常是JMS消息队列的好几倍以上。 如果消息处理比较简单，不会耗时，则直接处理消息是比较好的办法。
@杨延庆：我的消息当时有普通的传感器消息和警告消息，最初的想法是先把要发送的普通消息放到一个队列里，由ICE统一发送，如果有警告消息要发送时，可以先停止普通消息的发送，放普通消息到消息队列里，先发警告消息，等警告消息发送完后再发，实际测试时发现ICE在发送消息队列里的数据时发的速度比我放的速度慢，有阻塞现象，导致消息队列越来越大，从而app内存溢出，最后还是收到传感器消息就发ICE消息，不放队列了，但...
你的意思是说android程序和server程序用jms交换消息，不用ICE么？
@mycat：App客户端直接Ice通信把消息给服务端，服务端根据消息处理的情况，考虑放入消息队列或者直接处理。App端资源有限，放入消息队列再发送，肯定速度赶不上。
@杨延庆：主要是ICE的Java版不能像C++版可以进行内存的手动分配和回收，所以只能像这样做了，能不能使用ICE Box或者ICE Grid呢？
@mycat：在于Android客户端的性能无法跟PC比，不管是CPU能力还是内存能力，所以要尽量的避免复杂Java对象的创建销毁等逻辑
@mycat：网上查到一个有趣的对比：zeromq 我在 mac lion 上试验一把，官方的案例 hwclient.c/hwserver.c 把发的包改成：包长度＋包内容（就是 Muti-part Message 方式），用 zmq_send/zmq_recv 和 zmq_msg_send/zmq_msg_recv，带ZMQ_SNDMORE/ZMQ_REVMORE 都有问题，把 ZMQ_REVMORE 去掉就 OK，zeromq 还有很多要完善的，bug report我都找不到提交的地方，只要直接从 man 中找到的 email 地址发邮件给他们，样例代码和文档都不太好用。我原来用 zeroc ice，这个开源系统这方面比 zeromq 做的好，至少我们已经用 zero ice 做过一些项目