RPC or noRPC,这是个问题

感觉本贴说明的是这两个抉择：
A、需要服务端提供支持库(包括数据结构、客户端)
B、只需要服务提供调用协议。

协议也是一种接口，其中也包括了数据结构描述。从这个角度来说，服务端提供的支持库实际上是协议的一种具体实现了。

客户端采用支持库，方便、性能好些，但是被耦合了。

企业内部，容易沟通，舍弃一个可统一协调维护的支持库不用，非得绕弯来各自实现协议，有点隔靴挠痒的感觉。看似解耦了，实际成本却高。

就我个人实践的经验看,和你说的恰恰相反.
多个项目都去依赖一个库,只要这个项目群有一定的活跃度,一定会周期性的出现大的重构需求.至于重构对各依赖项目群的影响能有多少,及其考验支持库的设计者(语言技巧和业务理解).这还是说的项目群的进度在业务上一致的情况,如果出现系统本身升级,但是项目群又无法同步的切换,依赖包给做大量的兼容甚至给出多个版本.成本一点一不低.

比较赞同robbin的观点，如果是企业内部的整合集成，采用RPC相对好些，性能高，规模也容易控制，而且RPC可以提供比restFul更多的特性，第三方集成采用restFul更合适，第三方总想有更多的控制，而且restful接口一目了然，也比较容易进行问题分析。

举个实际的例子，alipay，
它实际上是restful的接口。但同时也提供了java和其他语言的wrapper，大多数人会用。

这个是看情况的吧。。如果是新系统
我倾向用rpc。现在我就用ice。phprpc也用过。

旧系统 如果不好做rpc。就用非rpc 封装一层。

说实话,非常同意你的观点.

各自实现只是看似解耦,因为发生需求变动的时候,A-Y个应用的开发者是非常痛苦的,他们要阅读文档中变化的地方,而且会提出各种问题,接着Z的开发者就不停的解答这些问题,沟通的成本非常高,从这个角度来看,项目之间的耦合程度是非常高的.

这样的场景我们是否可以通过项目管理来实现控制.

1.在依赖库升级的时候保证对修改封闭,对扩展开放的原则,这样不会出现修改已有接口的情况发生.
2.只兼容有限的最近几个接口,也就是说老版本支持只保持在一定的版本号之内.

我们公司能做到这一点并不难,原因有2个:

1.企业内部使用的依赖库做到这一点并不难,但是如果是对公众开放的依赖库这样做就不合适了.

2.我之所以说我们做到这一点并不难还有一个原因,就是我们也是属于互联网产品的一部分,互联网产品更新的速度是非常高的,大多数情况下Z的客户端升级的时候,A-Y也存在升级的需求了.

同意这个观点，虽然我们现在内部使用的是hessian，但是我觉得对于一个对外部提供服务的业务来说，不应该限制客户端的语言，可以提供默认的实现。有客户自己决定用与不用。

我能理解你的心情,但是我也希望你不要答非所问.


现在很多rpc都没有语言限制阿,只要你的序列化方式是同用的,那么基本上就没有语言限制.比如说:
hessian
thirft
protobuffer
PHPRPC

等等.

alipay的场景和我们还有区别,alipay是个独立的平台,hatedance描述的是独立平台之间的依赖.
我们的场景包括平台内部和平台之间这两种.如果是平台内部应用的调用,搞那么多只是增加了成本降低可维护性.

restful 接口和 WebService 接口都是用来推脱责任的最好借口。如果不希望自己承担责任，又不在乎实施项目的两方互相踢皮球浪费时间的话，使用 Restful 接口或 WebService 接口就是最佳选择。

反之，如果希望项目能够做的又快又好，后期维护又方便，实施两方都不愿意扯皮，并且都是有责任感的人的话，那就使用RPC方式。