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

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

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



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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

哥哥，你的日子真超前。