介绍
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
