ZeroC Ice 暂记

摘自： http://weibo.com/p/1001603869896789339575

原文地址： http://www.oschina.net/question/865233_242146

 

吴治辉，@ mycat，拥有超过 15 年的软件研发经验，精通 Java 编程，专一于电信软件和云计算方面的软件研发，参与过众多与分布式、云计算相关的大型项目的架构设计和编程，具有丰富的大型项目架构设计经验，是业界少有的具有很强编程能力的S级资深架构师，目前就任于惠普。此外，他仍是 国内知名开源分布式数据库中间件  MyCat  的发起人。目前 MyCat 项目已经有超过 15 名活跃志愿者在参与和推动，其社区 QQ 群人数超过2000人，是当下热门的移动互联网和云计算项目必备基础中间件之一。

随着移动互联网的迅猛发展，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 作过一些项目