RPC or noRPC,这是个问题

/**

   * author:ahuaxuan

   * date:2010-04-21

   */

修改,避免引起混淆,特别说明本文中的非RPC方式其本质也是RPC,只是非RPC由服务器端定义好序列化规则和协议,然后让调用者自己去实现,而本文中的RPC指服务提供者提供Jar,客户端可以直接调用接口.不需要考虑到网络,协议,序列化算法.

 

很多公司都会遇到应用集成的一些问题,其中一项就是RPC的问题.


企业内部应用集成(请求应答模式)的通信一般有方式,一种是RPC方式,另外一个是非RPC方式.
先说说非RPC方式的实现:比如说A-Y这25个应用依赖于Z这个应用,那么Z应用将丢一个开发文档给A-Y个应用的开发人员,告诉他们说,
照着文档开发吧,A-Y个应用的开发人员打开文档,看到一个URL, 然后就是URL中需要的参数.

于是A-Y个应用开始开发各自和Z应用通信的程序.

RPC方式实现:
Z应用直接提供一个jar包给A-Y个应用,然后A-Y应用导入这个jar,然后直接调用接口.具体的实现可以参考hessian RPC.

使用RPC的好处是你不需要考虑对象这么序列化成bytes传到server,也不需要考虑从server过来的bytes这么反序列化成接口的返回值.

这些内部的实现A-Y的开发者完全不需要考虑.

很多人偏向RPC方式,也有人偏向非PRC方式.那么ahuaxuan先来阐述一下他们的优缺点:

非RPC方式:
优点:
1.A-Y的代码功能相同,但是实现方式不一样,一个出现bug,不会影响其他24个应用.其他24个应用不需要重启以导入新的jar包
2.A-Y的代码不需要引入Z应用的J <script src="/javascripts/tinymce/themes/advanced/langs/zh.js" type="text/javascript"></script><script src="/javascripts/tinymce/plugins/javaeye/langs/zh.js" type="text/javascript"></script> ar包.
3.Z应用的开发者由于不需要提供client的jar包,所以不需要承担bug带来的责任.

缺点:
1.A-Y的开发者重复造轮子,25次.
2.A-Y的测试者重复测试.
3.如果一个client的实现+单元测试+ 集成测试和调试需要4 manday,那么24次多余的劳动会带来96个manday的浪费
4.重复的测试达到24次,每次是2个manday,那么又48个manday的浪费,总共的浪费高达96+48=144manday.
5.每次Z的修改都可能造成这样的浪费.

6.文档中要定义接口的错误状态码.然后客户端需要关心这些状态码的实现.


再说说RPC方式:
优点:
1.A-Y个应用不需要开发这个功能,直接引入jar包,调用接口,2分钟完成这部分工作.
2.Z应用对外的接口在Z的新版本开发时不修改老接口,只增加新接口.达到一定的兼容性.

3.不需要考虑对象这么序列化成bytes传到server,也不需要考虑从server过来的bytes这么反序列化成接口的返回值.

这些内部的实现A-Y的开发者完全不需要考虑.

4.不需要考虑序列化完成之后的bytes怎么传输,是http,还是直接基于TCP, 是nio还是bio等等

5.异常可以直接序列化到客户端,客户端调用者不需要去研究什么状态码,只要看一下异常的种类就行了.

6.客户端可以直接验证输入参数的合法性,无需到服务器上验证, 提供接口的人更清楚他们接受什么样的参数

缺点:
1.Z应用的开发者需要承担责任,如果client的Jar在线上出现bug,他们难辞其咎.(但这对A-Y的开发者来说是个优点)
2.如果jar包线上出bug,那么A-Y个应用都需要重启,并引入新的jar包.
3.不能满足一些人自以为是的欲望,因为有一些人一直觉得自己的代码是最好的,所以他们宁可重复造轮子.




接下来请各位同学做一道选择题:

请站在非A-Z应用的开发者角度(请站在对整个架构有利的角度)来选择这些企业内部应用集成的方式:

 

A. RPC方式
B. 非RPC方式
如果你有除了我上面列出的其他优缺点,可以在你选择的答案后面列出来.


虽然这不是一个纯技术贴,但是我想大家在发展的过程中都或多或少会遇到这样的问题(这个问题是:很多时候你坚信是正确的事情但是却得不到上面的执行和认可,所以我们只有两个选择,1.曲线救国,2.放下不管,).希望大家支持,踊跃参与.

评论

80 楼 vb2005xu 2011-10-17  

我觉得非rpc实现最好 最能节省公司成本 对接方自己实现可能更优化 更能与现有系统集成

79 楼 helloworldwyn 2010-12-08  

提不提供客户端包，个人认为主要是个成本问题。
如果你是卖服务的，你当然要提供，而且要提供各种方式客户端包方便客户。
如果是合作，对方出钱就做，因为这些代码维护和升级都需要钱。
如果是一个企业内部多个系统，建议改改设计，如果确实要这么设计，两种做法：
1、基于信任的做法，分清责任和成本，可选择提供或不提供
2、基于不信任的做法，分清责任和成本，都不提供，只提供标准服务

78 楼 andot 2010-05-10  

C_J 写道

**但是我想设计那些xml传输格式的委员会不会不懂吧？
所以我觉得WebService设计的协议应该是有他的渊源的，“存在即合理”嘛
不知道andot学长有没有了解过那些渊源呢？不妨给大家讲讲吧。

一不小心，写得太多了，单独开了个帖子：SOAP和WebService那些事

77 楼 C_J 2010-05-09  

andot 写道

在我看来”好的数据结构“+”差的算法“要远远好于”差的数据结构“+”好的算法“，为何这样说呢？

因为前者的算法还可以优化，只要数据结构不变，算法的优化在不会影响协议正常工作的情况下，可以让协议实现变得更优更好，直至达到“好的数据结构“+“好的算法“这样一个境界。

而WebServices就是后者，WebServices的数据结构已经注定了它的低效，专家们在实现它的算法上也已经竭尽所能达到了它能达到的最高性能，再继续进步的可能性已经不大了。

所以只有重新开创一个新的从数据结构上就设计为最优的协议，才能保证日后能够进化为“好的数据结构“+“好的算法“这样一个实现。在WebService上改良是没有这个可能的啦。

**你说的很有道理，我赞同你对“好的数据结构”的观点。

**但是我想设计那些xml传输格式的委员会不会不懂吧？
所以我觉得WebService设计的协议应该是有他的渊源的，“存在即合理”嘛
不知道andot学长有没有了解过那些渊源呢？不妨给大家讲讲吧。


我在google WS历史的时候，无意中看到一段颇富哲理的话：

引用

看看那些曾经的泡沫——死了一个CORBA，可以再有一个EJB，Without EJB了我们可以有Web服务，可以有SOA，可以有ESB……莫不感叹其舆论之顽强啊。还记得Rod Johnson在谈到远程服务技术（Hession、Burlap）时曾坦言“标准化抑制创新”。事实也正是如此，“标准化”让人们或主动或被动的得接受它。而“标准化”是谁在制定呢？是大厂商，实现标准的相应软件工具是谁在做，谁在买，谁在赚大钱呢？是大厂商。问题的根子就在这里。立法与司法兼于一人，没了三权分离，那么公平、民主、创新又从何谈起。这个类比是牵强，但核心之所在即大厂商缺乏技术层面的监督。它们就好比那些金融寡头肆意创造基于垃圾债券的金融衍生产品。不同的是，无限的金融衍生产品可以卷住大量货币，使其游离于实物商品市场之外，达到控制通货膨胀，掩人耳目于货币大量增发之事实。而技术行业（这个以复杂性为生的行业）的泡沫，圈走的除了企业的金钱财富，还有一代程序员宝贵的时间财富。

76 楼 andot 2010-05-09  

C_J 写道

学习phprpc中，有没有想过优化WebServices，而不是开创一个新的协议呢？推广的成本很高啊，www.phprpc.org还是中文版的，- -！！

协议实现跟普通程序本质上是一样的，都是“数据结构”+“算法”。

“好的数据结构“+“好的算法“肯定比“差的数据结构“+“差的算法“要好，这一点无庸置疑。

但是如果是”好的数据结构“+”差的算法“和”差的数据结构“+”好的算法“比起来，孰优孰劣呢？

在我看来”好的数据结构“+”差的算法“要远远好于”差的数据结构“+”好的算法“，为何这样说呢？

因为前者的算法还可以优化，只要数据结构不变，算法的优化在不会影响协议正常工作的情况下，可以让协议实现变得更优更好，直至达到“好的数据结构“+“好的算法“这样一个境界。

而后者在算法上已经没有改进的余地了，要想优化就需要修改数据结构，但数据结构一改，那协议也就变了，所以说后者已经达到了极限，已经没有可以继续进化的可能了。

而WebServices就是后者，WebServices的数据结构已经注定了它的低效，专家们在实现它的算法上也已经竭尽所能达到了它能达到的最高性能，再继续进步的可能性已经不大了。

所以只有重新开创一个新的从数据结构上就设计为最优的协议，才能保证日后能够进化为“好的数据结构“+“好的算法“这样一个实现。在WebService上改良是没有这个可能的啦。

当然这里我并没有说PHPRPC就是一个从数据结构上就是一个设计最优的协议，如果是这样的话，也就不会有现在的商业版的Hprose存在的必要了。

75 楼 C_J 2010-05-09  

ahuaxuan 写道

补充,rpc的方式,还有一个好处,参数的校验可以在client端完成, 在开发时期,这个优点可以节约很多沟通的成本,在运行时期,这个优点可以避免无谓的远程开销.

如果外部系统的dev偷懒怎么办？
Server不做参数校验是不是完全把命运托付给别人了？
我觉得这个问题不是大问题，Server还是得做校验。
LZ的标题确实是有点歧义吧

学习phprpc中，有没有想过优化WebServices，而不是开创一个新的协议呢？推广的成本很高啊，www.phprpc.org还是中文版的，- -！！

74 楼 Arden 2010-05-09  

用Aｃｔｏｒ

73 楼 ahuaxuan 2010-05-07  

补充,rpc的方式,还有一个好处,参数的校验可以在client端完成, 在开发时期,这个优点可以节约很多沟通的成本,在运行时期,这个优点可以避免无谓的远程开销.

72 楼 yin_bp 2010-04-22  

sniffer123 写道

这个。。弱弱地说一句 要是A-Y个应用 不全是用JAVA开发的 怎么办？还有数据的大端小端问题，包装成一个jar，不同CPU上并不能保证一致

webservice是个不错的选择，因为webservice是一个开放的事实标准

71 楼 andot 2010-04-21  

sniffer123 写道

这个。。弱弱地说一句 要是A-Y个应用 不全是用JAVA开发的 怎么办？还有数据的大端小端问题，包装成一个jar，不同CPU上并不能保证一致

这个用跨平台的RPC解决方案就可以啊，比如Hprose。

70 楼 sniffer123 2010-04-21  

这个。。弱弱地说一句 要是A-Y个应用 不全是用JAVA开发的 怎么办？还有数据的大端小端问题，包装成一个jar，不同CPU上并不能保证一致

69 楼 andot 2010-04-08  

seele 写道

我举个场景：
A项目中要应用到一个B项目组开发的一个组件，比如叫通用查询，可以用数据库和HTML动态组装和查询数据，来实现业务。那么A项目获取到一个JAR，和对应的部署配置方式，附加到A项目中进行开发应用。
这样的话，JAR不单B需要进行维护，而且B对JAR升级或者修改，还需要考虑A是否能够正确运行，工作量加大。这个就是强耦合了。

还有一个场景：
C项目需要和银行D之间进行扣款，那么就是采用webservice的方式。
银行D给出的接口是不能变化的，C或者其他的项目F，G等都可以进行对应功能开发。
这个是弱耦合

第一个场景的问题不是RPC本身的问题，是应用接口改变的问题。这个你用Rest也一样，你Rest的接口改了，对方一样没法对接。你传输纯XML也一样，你的XML数据格式都改了，一样没法对接。所以，在开发分布式应用时，需要保证的就是对外公开的接口不要改变，这时，你不管采用WebService也好，其他RPC也好，Rest也好，传输纯XML也好，都不是问题。

第二个场景同第一个场景，跟具体采用什么调用方式无关，只跟对外接口是否变化有关。

弱耦合还是强耦合不是看是WebServic还是其他RPC技术，而是看你对外的接口是否是固定的。

68 楼 ahuaxuan 2010-04-08  

seele 写道

我举个场景：
A项目中要应用到一个B项目组开发的一个组件，比如叫通用查询，可以用数据库和HTML动态组装和查询数据，来实现业务。那么A项目获取到一个JAR，和对应的部署配置方式，附加到A项目中进行开发应用。
这样的话，JAR不单B需要进行维护，而且B对JAR升级或者修改，还需要考虑A是否能够正确运行，工作量加大。这个就是强耦合了。

还有一个场景：
C项目需要和银行D之间进行扣款，那么就是采用webservice的方式。
银行D给出的接口是不能变化的，C或者其他的项目F，G等都可以进行对应功能开发。
这个是弱耦合

你的第一个场景其实也不是问题,我前面已经回帖说明过了.如果第一场景中提供的是一个平台服务,那么你升级jar包的时候完全可以做到对修改封闭,对扩展开发,而且你只要看一下apache上的开源项目,你会发现所有的开源项目都是以提供jar的方式来提供服务.所以做到后面,你会发现,真正的耦合其实并不是来自于是否是接口(就算你用restful或者自己根据协议开发,如果别人升级,难道你还指望自己不用改,绝大多数情况你都需要跟着改).而是来自于数据.数据的耦合往往上是应用集成的大忌.

第二个场景我也认为是应该是用webservice,我一直认为不同组织之间的沟通,一般上应该选择webservice.

67 楼 seele 2010-04-08  

我举个场景：
A项目中要应用到一个B项目组开发的一个组件，比如叫通用查询，可以用数据库和HTML动态组装和查询数据，来实现业务。那么A项目获取到一个JAR，和对应的部署配置方式，附加到A项目中进行开发应用。
这样的话，JAR不单B需要进行维护，而且B对JAR升级或者修改，还需要考虑A是否能够正确运行，工作量加大。这个就是强耦合了。

还有一个场景：
C项目需要和银行D之间进行扣款，那么就是采用webservice的方式。
银行D给出的接口是不能变化的，C或者其他的项目F，G等都可以进行对应功能开发。
这个是弱耦合

66 楼 oakeye 2010-04-08  

那本restful web services里面介绍的好多都是混合模式  非rcp就是restful
然后加上rcp  不过里面的都是ruby实现的  现在spring3的MVC液有自己的rest实现了 不错

65 楼 oakeye 2010-04-08  

那就混合模式，好像很多都是这么干的。。。

64 楼 andot 2010-04-07  

oakeye 写道

REST结构简单的系统用，设计上简单，功能就是普遍的东西，伸缩性也强，
RPC那就复杂的系统用

嗯，REST适合于典型的Web系统（例如门户前台、新闻网站前台、论坛、留言板等等），RPC则适合于Web应用系统、企业应用系统、网络游戏等。
上面的划分也不是绝对的，大部分时候，这两者还是可以结合使用的。例如在典型的Web系统中可以使用RPC来完成Ajax效果，前端和后端之间的通讯也可以借助RPC来完成。
适合用REST的系统不一定就是简单的，RPC也不是一定要复杂的系统才可以用。

63 楼 oakeye 2010-04-07  

REST结构简单的系统用，设计上简单，功能就是普遍的东西，伸缩性也强，
RPC那就复杂的系统用

62 楼 oakeye 2010-04-07  

ls的意思是  我们改讨论RPC和REST好了

61 楼 melin 2010-04-04  

在企业应用当中，只要提到接口，大部分人想到的就web service，而传的参数还是xml字符串，一点web service好处也没有用到。还不如使用原始socket和http get or post