RPC or noRPC,这是个问题
/**
* author:ahuaxuan
* date:2010-04-21
*/
很多公司都会遇到应用集成的一些问题,其中一项就是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,然后直接调用接口.
很多人偏向RPC方式,也有人偏向非PRC方式.那么ahuaxuan先来阐述一下他们的优缺点:
非RPC方式:
优点:
1.A-Y的代码功能相同,但是实现方式不一样,一个出现bug,不会影响其他24个应用.其他24个应用不需要重启以导入新的jar包
2.A-Y的代码不需要引入Z应用的Jar包.
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的修改都可能造成这样的浪费.
再说说RPC方式:
优点:
1.A-Y个应用不需要开发这个功能,直接引入jar包,调用接口,2分钟完成这部分工作.
2.Z应用对外的接口在Z的新版本开发时不修改老接口,只增加新接口.达到一定的兼容性.
缺点:
1.Z应用的开发者需要承担责任,如果client的Jar在线上出现bug,他们难辞其咎.(但这对A-Y的开发者来说是个优点)
2.如果jar包线上出bug,那么A-Y个应用都需要重启,并引入新的jar包.
3.不能满足一些人自以为是的欲望,因为有一些人一直觉得自己的代码是最好的,所以他们宁可重复造轮子.
接下来请各位同学做一道选择题:
请站在非A-Z应用的开发者角度来选择这些企业内部应用集成的方式:
A. RPC方式
B. 非RPC方式
如果你有除了我上面列出的其他优缺点,可以在你选择的答案后面列出来.
虽然这不是一个纯技术贴,但是我想大家在发展的过程中都或多或少会遇到这样的问题.希望大家支持,踊跃参与.
建议继续学习:
- hadoop rpc机制 && 将avro引入hadoop rpc机制初探 (阅读:5097)
- Thrift简析 (阅读:4840)
- Linux下的NFS (阅读:3173)
- Java跨语言调用实现方案 (阅读:2733)
- Skynet 集群及 RPC (阅读:1972)
- Erlang集群RPC通道拥塞问题及解决方案 (阅读:1895)
- 深入浅出jcr之16 该死的RMI,我们需要HTTP+简单RPC协议 (阅读:1832)
扫一扫订阅我的微信号:IT技术博客大学习
- 作者:ahuaxuan 来源: ahuaxuan
- 标签: RPC
- 发布时间:2010-04-01 08:49:49
- [68] 如何拿下简短的域名
- [68] Go Reflect 性能
- [64] Oracle MTS模式下 进程地址与会话信
- [61] 图书馆的世界纪录
- [60] 【社会化设计】自我(self)部分――欢迎区
- [60] IOS安全–浅谈关于IOS加固的几种方法
- [58] android 开发入门
- [53] 视觉调整-设计师 vs. 逻辑
- [48] 读书笔记-壹百度:百度十年千倍的29条法则
- [47] 界面设计速成