|
锁定老帖子 主题：RPC or noRPC,这是个问题
该帖已经被评为良好帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2010-04-02
非RPC方式:
优点: 1.A-Y的代码功能相同,但是实现方式不一样,一个出现bug,不会影响其他24个应用.其他24个应用不需要重启以导入新的jar包 2.A-Y的代码不需要引入Z应用的Jar包. 3.Z应用的开发者由于不需要提供client的jar包,所以不需要承担bug带来的责任. 这三点再仔细想想，能出在非RPC的优点里吗？ |
| 返回顶楼 | |
|
发表时间：2010-04-02
最后修改：2010-04-02
robbin 写道 需要很高的性能，模块之间耦合程度高就用RPC
不需要很高的性能，模块之间独立性强，就用REST 感兴趣的朋友可以参考一下bbossgroups中的RPC框架，目前支持多种协议jms，jgroups，mina，webservice，restful，而且协议可扩展，提供强有力的安全管理插件（可插拔的认证、鉴权、数据包加/解密插件）目前bbossgroups发布的版本是1.0，我将在1.0rc版本中增加对jboss netty协议框架的支持，呵呵 bbossgroups rpc框架包含在子项目bboss aop框架中，下载地址： http://sourceforge.net/projects/bboss/files/bbossgroups-1.0/bbossaop.zip/download 文档下载地址： http://sourceforge.net/projects/bboss/files/bbossgroups-1.0/bbossgroups%20document.zip/download |
| 返回顶楼 | |
|
发表时间：2010-04-02
RPC怎么定义的？一定是使用RPC协议才算么？HTTP算不算呢？
有些东西也看api的提供者了，也得看部署方式，以及客户需要 我前些日子做个短信发送，很简单的东西而已 ，就要支持MAS机 网关 短信modem方式，这个问题也类似吧，全做了让客户或者实施人员去选吧。 另外说说非RPC的方式的缺点，我觉得这个缺点都不算什么，你说的缺点后4条都是测试上的问题，基本可以算是一个问题，分4条说显得问题扩大了，而且A-Y的测试是必须的，也不见得是为了测试Z而测试A-Y吧？如果Z有问题，也许A就已经测试出来了，B-Y可以坐等，如果Z有修改，出了问题也是Z的事情。对于问题1，我觉得RPC方式也会存在吧 让我选用哪个方式，我还真不知道怎么选了，也得看你的项目大不大吧，有没有外部系统和遗留系统，就做个宣传用的小网站的话，几个静态页面就够了吧。 我们现在做都是对外提供个ws接口，而别人对我们是什么接口，我们主宰不了 另：to robbin 能简单解释一下你在第一页的回帖么？我感觉有歧义，你说的耦合性是指一个大系统内部，还是指多个系统之间 |
| 返回顶楼 | |
|
发表时间：2010-04-02
看来绝大多数人都选择RPC。如果是我，我的选择取决于，我对Z这个系统开发者的水平的评估，如果他们靠得住，并且和我关系很好，那么我选择RPC。否则，我宁可选择noRPC。
理由很简单 引用 缺点:
1.Z应用的开发者需要承担责任,如果client的Jar在线上出现bug,他们难辞其咎.(但这对A-Y的开发者来说是个优点) 2.如果jar包线上出bug,那么A-Y个应用都需要重启,并引入新的jar包. 3.不能满足一些人自以为是的欲望,因为有一些人一直觉得自己的代码是最好的,所以他们宁可重复造轮子. 1) jar有bug，固然是Z的开发者，但是对我的系统功能，也有重大影响，如果Z的开发者靠不住，那么这个问题会被无限放大，影响所有的A-Y。 2) 第二个问题很致命，没的说，这个工作还要借助于A-Y的部署人员和QA参与。你能确保这jar包的功能那么靠得住？还得一个一个系统去看下。 3) 不做评论了 |
| 返回顶楼 | |
|
发表时间：2010-04-02
huzhenyu 写道 非RPC方式:
优点: 1.A-Y的代码功能相同,但是实现方式不一样,一个出现bug,不会影响其他24个应用.其他24个应用不需要重启以导入新的jar包 2.A-Y的代码不需要引入Z应用的Jar包. 3.Z应用的开发者由于不需要提供client的jar包,所以不需要承担bug带来的责任. 这三点再仔细想想，能出在非RPC的优点里吗？ 显然你没有看我前面的回帖,为了节省你查找的时间我贴到下面: ahuaxuan 写道 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源代码，有冲动的人提出修改申请来冲动下也可以的！ ^ ^ 非常同意你的观点.其实上面我提出的缺点我也不认为全部都是缺点,我只是站在不同的角度来预先考虑了一些其他观点.打个预防针,呵呵 |
| 返回顶楼 | |
|
发表时间：2010-04-02
downpour 写道 看来绝大多数人都选择RPC。如果是我，我的选择取决于，我对Z这个系统开发者的水平的评估，如果他们靠得住，并且和我关系很好，那么我选择RPC。否则，我宁可选择noRPC。
理由很简单 引用 缺点:
1.Z应用的开发者需要承担责任,如果client的Jar在线上出现bug,他们难辞其咎.(但这对A-Y的开发者来说是个优点) 2.如果jar包线上出bug,那么A-Y个应用都需要重启,并引入新的jar包. 3.不能满足一些人自以为是的欲望,因为有一些人一直觉得自己的代码是最好的,所以他们宁可重复造轮子. 1) jar有bug，固然是Z的开发者，但是对我的系统功能，也有重大影响，如果Z的开发者靠不住，那么这个问题会被无限放大，影响所有的A-Y。 2) 第二个问题很致命，没的说，这个工作还要借助于A-Y的部署人员和QA参与。你能确保这jar包的功能那么靠得住？还得一个一个系统去看下。 3) 不做评论了 也就是说downpour兄的选择是取决于Z的client的开发者的水平,对吧 |
| 返回顶楼 | |
|
发表时间：2010-04-02
最后修改：2010-04-02
你这里谈的非RPC，仍然是普通意义上的RPC，这里我认为你想要表达的是：是否提供一个封装client来屏蔽RPC的复杂度给用户的问题，从代码复用和编程简便的角度来说答案是肯定的啦。
|
| 返回顶楼 | |
|
发表时间：2010-04-02
最后修改：2010-04-02
Z的client包开发者水平，的确是一个考虑要素。
但是如果是一个异构系统，A-Y系统采取的开发语言、架构都不一样，Z的水平再高，也没精力没必要为A-Z都开发一套client，无缝的用在A-Y的系统中。所以这个时候，提供协议/规范就是首选了。 换个角度来看，这其实是个可重用性的问题。 |
| 返回顶楼 | |
|
发表时间：2010-04-02
最后修改：2010-04-02
dennis_zane 写道 你这里谈的非RPC，仍然是普通意义上的RPC，这里我认为你想要表达的是：是否提供一个封装client来屏蔽RPC的复杂度给用户的问题，从代码复用和编程简便的角度来说答案是肯定的啦。
是的,是这个意思,只是我的声音太小,所以只能眼睁睁的看着很多不合理的现象发生,包含之前谈到的成本之类的问题.甚至直接影响到项目的周期,互联网项目周期长短对项目影响很大 |
| 返回顶楼 | |
|
发表时间：2010-04-02
讨论到现在
我有点分不清rpc和非rpc的界限了 |
| 返回顶楼 | |
