【RPC】springcloud、grpc、dubbo 什么区别?

介绍

SpringCloud与grpc

首先,对 dubbo 不是很了解,所以只说一下我对于 SpringCloud 和 grpc 的了解,如果有什么地方说得不对,请指正。
在 SpringCloud 中,服务间的调用是通过 http 通信的,其实就相当于在调用 RESTFul 接口。而 grpc 服务间的调用是基于 http2 以及 protobuff 协议的一种通信机制,他要求在调用前需要先定义好接口契约,并使用工具生成代码,然后在代码中调用这些生成的类进行服务调用。两者之间,个人认为 grpc 会有比较多的限制。
第二个问题,分布式和单体结构的通信区别,个人认为可能就是多了一个负载均衡的差异吧。原生与接口的通信、H5 与接口的通信,个人认为两者不应该有区别,接口只需要暴露出一种通信方式,这样才能节省开发成本。

gRPC

https://github.com/grpc/grpc-java
由谷歌开发的一个高性能开源RPC框架,基于HTTp/2协议标准开发。利用ProtoBuf作为序列化工具和接口定义语言。

Dubbo

Dubbo远程接口调用,负载均衡和容错,自动服务注册和发现。

RPC

HTTP 是通信协议,RPC 是一种设计实现框架。
RPC 中使用的通信协议大都是长连接,不需要每次经过 3 次握手。
RPC 中使用的通信协议大都自己设计,没有通用标准。
RPC 框架基本都围绕通信协议、传输协议、线程模型展开。
分布式不是 RPC 的必要特性。

总结

对springcloud、grpc、dubbo 什么区别?rpc和分布式的关联?根据网络各自不同的发声,总结如下

SpringCloud 中,服务间的调用是通过 http 通信的,其实就相当于在调用 RESTFul 接口。
grpc 服务间的调用是基于 http2 以及 protobuff 协议的一种通信机制,他要求在调用前需要先定义好接口契约,并使用工具生成代码,然后在代码中调用这些生成的类进行服务调用。

RPC 中使用的通信协议大都自己设计,没有通用标准。
RPC 中使用的通信协议大都是长连接,不需要每次经过 3 次握手。

分布式不是 RPC 的必要特性。

概念:

Dubbo RPC:基于TCP或HTTP的远程过程调用(就像在本地调用一样),RPC强调的是远程调用。

spring cloud:基于springboot,而springboot是基于HTTP协议REST风格的RPC。

对比:

1、协议:服务间通信协议不同,Dubbo是基于TCP协议的rpc,spring cloud基于http协议。

2、RPC避免了上面提到的原生RPC带来的问题。而且REST相比RPC更为灵活,SpringCloud不存在代码级别的强依赖

3、效率:由于协议的不同,调用的效率相比之下Dubbo比SpringCLoud效率高。

4、技术开放性:SpringCLoud基于http协议,由于http的协议更方便于多语言情况下的整合,提供服务方可以用任意语言开发服务。

5、spring cloud是微服务生态,包括完整的微服务相关的组件工具集,而RPC是远程调用的技术,仅仅是微服务的一部分,而dubbo框架正是RPC的实现框架。

6、Spring Cloud还提供了包括Netflix Eureka、hystrix、feign、Spring Boot Admin 、Sleuth、config、stream、security、sleuth等分布式服务解决方案,

而Dubbo为了拥抱融入Spring Cloud生态,Dubbo也在积极规划和演进适配SpringCloud生态的新版本。

优缺点

grpc限制多,但http2相对http有二进制、长连接、服务器主动发消息等优势。

历史溯源

rpc先于http出现
(但当时是http初代有很多问题,现在http2个人觉得grpc还是有可取的优势)

性能

grpc一开始(2016年前)的性能貌似是dubbo的2/3左右
但是2017年的一篇博客看出grpc已经开始超越dubbo

性能分析demo

瑞 新 CSDN认证博客专家 分布式 Java 架构
求职中 • Java全栈养成计划
公众号 • 让我遇见相似的灵魂
回复领取:竞赛 书籍 项目 面试

左手代码,右手吉他,这就是天下:如果有一天我遇见相似的灵魂 那它肯定是步履艰难 不被理解 喜黑怕光的。如果可以的话 让我触摸一下吧 它也一样孤独得太久。 不一样的文艺青年,不一样的程序猿。
已标记关键词 清除标记
©️2020 CSDN 皮肤主题: Age of Ai 设计师:meimeiellie 返回首页