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这么反序列化成接口的返回值.

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