spring cloud 服务调用方式为什么使用http restful 而不是RPC？

Question

RT

http restful 易读、灵活、低耦合，这些优点我能明白

但RPC高效低延迟这个性能指标相信是很多微服务梦寐以求的，如果一个请求所需要的服务是3个以上并且各个服务业务逻辑复杂，甚至涉及众多IO操作，那是不是RPC的方式更为保障。

在我印象中服务与服务的调用如果要用http方式的话，满足条件：远距离的第三方服务；低频服务。

或者说spring cloud 默认使用http restful（至少我查阅的资料全是http），而提供RPC方案？

Answer 1

HTTP Restful本身轻量，易用，适用性强，可以很容易的跨语言，跨平台，或者与已有系统交互，毕竟HTTP现在没有不支持的。
Spring可以整合其他的RPC方案，比如各种MQ，Hessian，Thrift，都可以。
但是各类RPC协议本身有各自的使用范围和编码要求，这些会对交互两端的代码形成约束，所以应该根据自身实际情况去选择。
至于各类整合方案，应该很多，可以带着具体的RPC协议去搜

Answer 2

在跨语言调用的时候，Rest风格直接把http作为应用协议，不同语言之间调用比较方便。
而RPC是把http作为一种传输协议，本身还会封装一层RPC框架的应用层协议，不同语言之间调用需要依赖RPC协议。

Answer 3

RPC vs REST

另外，由于Dubbo是基础框架，其实现的内容对于我们实施微服务架构是否合理，也需要我们根据自身需求去考虑是否要修改，比如Dubbo的服务调用是通过RPC实现的，但是如果仔细拜读过Martin Fowler的microservices一文，其定义的服务间通信是HTTP协议的REST API。那么这两种有何区别呢？

先来说说，使用Dubbo的RPC来实现服务间调用的一些痛点：

服务提供方与调用方接口依赖方式太强：我们为每个微服务定义了各自的service抽象接口，并通过持续集成发布到私有仓库中，调用方应用对微服务提供的抽象接口存在强依赖关系，因此不论开发、测试、集成环境都需要严格的管理版本依赖，才不会出现服务方与调用方的不一致导致应用无法编译成功等一系列问题，以及这也会直接影响本地开发的环境要求，往往一个依赖很多服务的上层应用，每天都要更新很多代码并install之后才能进行后续的开发。若没有严格的版本管理制度或开发一些自动化工具，这样的依赖关系会成为开发团队的一大噩梦。而REST接口相比RPC更为轻量化，服务提供方和调用方的依赖只是依靠一纸契约，不存在代码级别的强依赖，当然REST接口也有痛点，因为接口定义过轻，很容易导致定义文档与实际实现不一致导致服务集成时的问题，但是该问题很好解决，只需要通过每个服务整合swagger，让每个服务的代码与文档一体化，就能解决。所以在分布式环境下，REST方式的服务依赖要比RPC方式的依赖更为灵活。

服务对平台敏感，难以简单复用：通常我们在提供对外服务时，都会以REST的方式提供出去，这样可以实现跨平台的特点，任何一个语言的调用方都可以根据接口定义来实现。那么在Dubbo中我们要提供REST接口时，不得不实现一层代理，用来将RPC接口转换成REST接口进行对外发布。若我们每个服务本身就以REST接口方式存在，当要对外提供服务时，主要在API网关中配置映射关系和权限控制就可实现服务的复用了。
相信这些痛点也是为什么当当网在dubbox（基于Dubbo的开源扩展）中增加了对REST支持的原因之一。
来自：https://zhuanlan.zhihu.com/p/...

Answer 4

简单点，就是Rest对内对外统一，跨平台跨语言，约束少一些。

Answer 5

个人觉得，如果暴露在外和内部调用的接口要求一样的话，restful可以起到很大的复用性。

Answer 6

springcloud也支持rpc，比如grpc

可以注册到eureka实现负载均衡、分布式追踪等springcloud一样的特性
https://github.com/yidongnan/...

使用方法参考里面的目录