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.放下不管,).希望大家支持,踊跃参与.

评论

20 楼 linkerlin 2010-04-01  

推荐PHPRPC

19 楼 ahuaxuan 2010-04-01  

引用

如果这样考虑的话，那就是属于使用哪种以及哪层通信协议，以及使用哪种通信格式的问题了。
定好这点后，接下来才是由server提供端来提供jar来隐藏通信格式，还是提供一个doc，由用户自己来编写。
当然根据通信协议以及格式的不同，客户端用户编写的难易也有所不同，另外还要考虑服务器端愿不愿意暴露那么多东西。

其实这个问题讨论起来也很复杂，我不知道lz站在哪个角度，或者从一个什么场景下考虑这个问题，如果不限定些东西的话，好像无法得出结论。
如果这样考虑的话，那就是属于使用哪种以及哪层通信协议，以及使用哪种通信格式的问题了。
定好这点后，接下来才是由server提供端来提供jar来隐藏通信格式，还是提供一个doc，由用户自己来编写。
当然根据通信协议以及格式的不同，客户端用户编写的难易也有所不同，另外还要考虑服务器端愿不愿意暴露那么多东西。

其实这个问题讨论起来也很复杂，我不知道lz站在哪个角度，或者从一个什么场景下考虑这个问题，如果不限定些东西的话，好像无法得出结论。

如果提供doc让用户来编写,那我就觉得这个是非RPC方式了,因为用户看不到你的接口,所以客户端的开发人需要自己去搞序列化,自己按照文档的通信协议来开发了.


我的角度就是从架构整体的性能,可维护性,可扩展性以及成本.

18 楼 hatedance 2010-04-01  

本质是选择http协议还是rpc协议而已。
我看rpc协议更高级，更面向应用。用webservice，hession随便你。
何况业界通用的rpc协议出了bug也不需要你去提供更新包。

17 楼 weiqingfei 2010-04-01  

ahuaxuan 写道

weiqingfei 写道

我对RPC和noRPC之间的界线比较模糊，比如说我们现在的应用，实际上就是通过url提供参数调用，可是server端还是给提供了一个jar包，对调用进行wrap，也就是客户端直接使用方法接口就可以，你说这算是RPC还是noRPC？

根据lz所描述的优缺点，我觉得lz的根本问题是不是要用server提供端的jar包的问题，至于c/s间如何通讯，那是另外一个问题。

对于我来讲，我倾向于使用提供包，因为这种方式所带来的唯一风险，就是提供的jar包的bug问题，其实不管哪种方式都有个双方协议的问题，不管是方法，还是参数格式。从这方面来看，只要接口不变，即使jar包出现bug，客户端重启一次又能带来多大问题呢。另外，对于服务器端的功能最熟悉的还是服务器端开发者，我想这个jar包出现bug的概率，比起客户端自己去编写要低多了。

你可以根据下面两个问题来衡量:
1.你需要自己考虑你的对象这么转换成bytes吗
2.你需要自己实现应用层协议吗

如果这样考虑的话，那就是属于使用哪种以及哪层通信协议，以及使用哪种通信格式的问题了。
定好这点后，接下来才是由server提供端来提供jar来隐藏通信格式，还是提供一个doc，由用户自己来编写。
当然根据通信协议以及格式的不同，客户端用户编写的难易也有所不同，另外还要考虑服务器端愿不愿意暴露那么多东西。

其实这个问题讨论起来也很复杂，我不知道lz站在哪个角度，或者从一个什么场景下考虑这个问题，如果不限定些东西的话，好像无法得出结论。

16 楼 ahuaxuan 2010-04-01  

weiqingfei 写道

我对RPC和noRPC之间的界线比较模糊，比如说我们现在的应用，实际上就是通过url提供参数调用，可是server端还是给提供了一个jar包，对调用进行wrap，也就是客户端直接使用方法接口就可以，你说这算是RPC还是noRPC？

根据lz所描述的优缺点，我觉得lz的根本问题是不是要用server提供端的jar包的问题，至于c/s间如何通讯，那是另外一个问题。

对于我来讲，我倾向于使用提供包，因为这种方式所带来的唯一风险，就是提供的jar包的bug问题，其实不管哪种方式都有个双方协议的问题，不管是方法，还是参数格式。从这方面来看，只要接口不变，即使jar包出现bug，客户端重启一次又能带来多大问题呢。另外，对于服务器端的功能最熟悉的还是服务器端开发者，我想这个jar包出现bug的概率，比起客户端自己去编写要低多了。

你可以根据下面两个问题来衡量:
1.你需要自己考虑你的对象这么转换成bytes吗
2.你需要自己实现应用层协议吗

15 楼 weiqingfei 2010-04-01  

我对RPC和noRPC之间的界线比较模糊，比如说我们现在的应用，实际上就是通过url提供参数调用，可是server端还是给提供了一个jar包，对调用进行wrap，也就是客户端直接使用方法接口就可以，你说这算是RPC还是noRPC？

根据lz所描述的优缺点，我觉得lz的根本问题是不是要用server提供端的jar包的问题，至于c/s间如何通讯，那是另外一个问题。

对于我来讲，我倾向于使用提供包，因为这种方式所带来的唯一风险，就是提供的jar包的bug问题，其实不管哪种方式都有个双方协议的问题，不管是方法，还是参数格式。从这方面来看，只要接口不变，即使jar包出现bug，客户端重启一次又能带来多大问题呢。另外，对于服务器端的功能最熟悉的还是服务器端开发者，我想这个jar包出现bug的概率，比起客户端自己去编写要低多了。

14 楼 ahuaxuan 2010-04-01  

liu78778 写道

看看JE的风气, 这种讨论的帖子都被批成新手帖

继续投吧, 反正我是0

正是因为每个人的观点都不一样,也正是因为人的这种特征(这个特征显示在本帖的投票上,也显示在我们日常的技术决策中)所以我才发出了这个样帖子,寻求他人的答案来证明自己的对错.

所以我们要捍卫他们投票的权力,但是我希望在投票的同时能够讲一讲原因.我会洗耳恭听.

13 楼 ahuaxuan 2010-04-01  

skzr.org 写道

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

第一点，Z应用是提供者当然有责任解决bug了，而且多了25个使用者，可以很好的覆盖所有的功能，加速功能的进化（根据开闭原则，对外部开放接口，封闭内部的实现细节）
第二点，这个看你怎么实现了，一般rpc出bug也只是你的服务端吧！应该客户端的jar修改基本上比教少！如果接口发生变动是不是可以利用classloader来动态装载新的jar来热部署！
第三点，既然是企业内部，那还不好说，重复的劳动要不得阿！或者内部开放你的rpc源代码，有冲动的人提出修改申请来冲动下也可以的！
^ ^

非常同意你的观点.其实上面我提出的缺点我也不认为全部都是缺点,我只是站在不同的角度来预先考虑了一些其他观点.打个预防针,呵呵

12 楼 ahuaxuan 2010-04-01  

robbin 写道

需要很高的性能，模块之间耦合程度高就用RPC

不需要很高的性能，模块之间独立性强，就用REST

耦合程度的高低怎么衡量呢?
比如说建索引,或者查询,或者其他,这些功能都是这个架构中不可缺少的.更关键的是架构中一些数据的定义涉及到很多应用,所以这个应该是耦合高的一个标识了

11 楼 skzr.org 2010-04-01  

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

第一点，Z应用是提供者当然有责任解决bug了，而且多了25个使用者，可以很好的覆盖所有的功能，加速功能的进化（根据开闭原则，对外部开放接口，封闭内部的实现细节）
第二点，这个看你怎么实现了，一般rpc出bug也只是你的服务端吧！应该客户端的jar修改基本上比教少！如果接口发生变动是不是可以利用classloader来动态装载新的jar来热部署！
第三点，既然是企业内部，那还不好说，重复的劳动要不得阿！或者内部开放你的rpc源代码，有冲动的人提出修改申请来冲动下也可以的！
^ ^

10 楼 iday 2010-04-01  

哥哥，你的日子真超前。

9 楼 iday 2010-04-01  

非rpc的情况下a-y的client如果出现bug也有可能会导致z的服务停止。而且这样的bug如果出现就会非常麻烦。
如果client是未知的情况下我觉得还是rpc更好些。
谁知道你的客户会做些什么样的尝试。。。

8 楼 liu78778 2010-04-01  

看看JE的风气, 这种讨论的帖子都被批成新手帖

继续投吧, 反正我是0

7 楼 robbin 2010-04-01  

需要很高的性能，模块之间耦合程度高就用RPC

不需要很高的性能，模块之间独立性强，就用REST

6 楼 oakeye 2010-04-01  

我暂时试试rest方式返回json，不管js还是java写的客户端，都比较好解析
就是尝试，我们第三方公司的东西当然是这种rpc的，给函数，给传参，调用即可

5 楼 rain2005 2010-04-01  

我现在使用的是http query就是URL 参数的形式，不过我也给其他应用开发了调用代码。其实最烦恼的是怎么规范接口。

4 楼 ahuaxuan 2010-04-01  

to ls.
我发这个帖子的目的就是为了用这个帖子来协调架构中各个组的统一决定,否则我发这个帖子只能够被别人投新手贴了(我不会真的闲的无聊来让大家回答这个问题).

所以我在文章最后也特别注明"大家在发展的过程中都或多或少会遇到这样的问题",为什么我要说这句话呢,因为有事情不是技术能说了算的,需要案例或者投票.

==================


所以ls的观点是从整体角度出发+顺畅的沟通应该是选择RPC方式.

ps,部门之间(相关度不大的部门)或者公司之间,我也认为应该使用非RPC的方式,这一点我们也是一致的.

3 楼 xyz20003 2010-04-01  

如果我说：“根据实际情况选择”会不会感觉我是因为太懒，所以懒得去考虑这些所谓架构上的问题呢？

从我们现在的开发角度来讲，我倾向于RPC，理由如下：

接口明确，规则清晰，沟通顺畅。还可以加上主贴中说到的“减少工作量”的部分。

但是，确实有的情况下需要开辟以url+参数这种形式的协议调用，这还不仅仅是公司提供给外部的XXX API，我遇到过公司内部跨部门调用的时候，就不愿意为对方提供远程调用接口，据说是因为双方使用的语言不同，所以简单给了一个URL附带一大堆的参数规范就不管了。这种时候都不是技术选型的问题，而是部门之间协调的问题了，技术人员插不上嘴。

反之，如果各部门之间沟通顺畅，即便从另一个团队拿过来一个jar，调用一方也很容易搞清楚内部实现（或者说有足够的信任感），就不会出现重新造轮子的冲动了。

2 楼 ahuaxuan 2010-04-01  

这么快就有人投新手贴了.你还别以为这个是新手贴,这个选择狠重要,直接决定架构的方向和可维护性.我也很想听听投新手贴同学的高见.



to ls
jms不算请求应答模型.
附上我的投票,我选择RPC模式, 但是显然,在大公司里很多时候说话要看资历,所以我是来寻求帮助的,或者说如果我的选择不对,那么也得要大多数选择非RPC模式.

如果我的选择对了,我会把这个帖子贴给我们总架构师看一下.我只是想说服他或者他们.

1 楼 oakeye 2010-04-01  

之前碰到的是RPC方式，人家给几个jar包，感觉不是很透明，确实有想自己造轮子的感觉。因为其实方式就是jms
现在想可不可以通过rest的方式发布应用，就像je这种API，把它用到系统里面呢？