ZeroC Ice 暂记

Posted 2020-08-21

摘自： 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 做过一些项目