ZEROC究竟是何方神圣?

1362802538 发布于 2016/08/11 10:23
阅读 206
收藏 0
原文出自:http://www.roncoo.com/article/detail/124802
本文整理自《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.

加载中
返回顶部
顶部