/**
* 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.放下不管,).希望大家支持,踊跃参与.
分享到:
相关推荐
jsonrpc是一个基于Java的高性能开源RPC框架
rpc服务属性按钮全部都是灰色的问题是很严重的问题,但可以解决。
本专题主要通过三个章节实现一个rpc通信的基础功能,来学习RPC服务中间件是如何开发和使用。章节内以源码加说明实战方式来讲解,请尽可能下载源码学习。 - 手写RPC框架第一章《自定义配置xml》 - 手写RPC框架第二章...
sofa-rpc,sofarpc是一个高性能、高扩展性、生产级的java rpc框架。.zip
JsonRpc-Cpp - JSON-RPC implementation. * Copyright (C) 2008-2011 Sebastien Vincent * * This program is free software: you can redistribute it and/or modify * it under the terms of the GNU Lesser ...
ONC RPC 协议实现,根据.x接口文档生成JAVA代码,实现不同语言间的RPC调用
JSON-RPC-Java是一个用Java来实现动态JSON-RPC的框架. 利用它内置的一个轻级量JSON-RPC JavaScripIt客户端,可以让你透明地在JavaScript中调用Java代码。JSON-RPC-Java可运行在Servlet容器中如Tomcat也可以运行在...
xml_rpc是什么
rpc远程过程调用的手写简单源码 学习rpc通信的可以下载下来看看 很有帮助 包括客户端和服务端的网络调用 通信 序列化....等等
此插件支持在jmeter中以rpc方式对dubbo接口进行调用、rpc方式调用dubbo,解压包后里面有两个文件,一个是支持rpc的插件,另一个赠送idea中对数据库访问的插件 插件名称:jmeter-plugins-dubbo-2.7.7-jar-with-...
sofa-rpc,SOFARPC是一种高性能、高扩展性、生产级的Java RPC框架。.zip
_win7_ 操作系统在运行磁盘管理时,可能会出现 "RPC 服务器不可用" 的错误提示,这个问题的解决方法将在下面进行详细的介绍。 RPC 服务器不可用的原因分析 在解决问题之前,需要了解问题的原因。从错误信息可以...
android-json-rpc是一个在android程序中使用的JSON-RPC客户端类库。它提供了一个简单的API来执行JSON-RPC服务调用
详细讲解RPC
这个一个rpc远程过程调用,根据网上资料搜集写的一个demo,仅供参考 !!
JSON-RPC-Java是一个用Java来实现动态JSON-RPC的框架. 利用它内置的一个轻级量JSON-RPC JavaScripIt客户端,可以让你透明地在JavaScript中调用Java代码。JSON-RPC-Java可运行在Servlet容器中如Tomcat也可以运行在...
RPC编程, RPC编程详解RPC编程, RPC编程详解RPC编程, RPC编程详解
高性能RPC框架 nfs-rpc
RPC 是一个高性能、开源、通用的 RPC 框架,面向移动和 HTTP/2 设计。GRPC 基于 HTTP/2 标准设计,带来诸如双向流、流控、头部压缩、单 TCP 连接上的多复用请求等特性。这些特性使得其在移动设备上表现更好,更省电...
jsonrpc-c-master 基于 json rpc 1.0 纯C开发的服务端代码和示例