介绍
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 的必要特性。
优缺点
grpc限制多，但http2相对http有二进制、长连接、服务器主动发消息等优势。
历史溯源
rpc先于http出现
（但当时是http初代有很多问题，现在http2个人觉得grpc还是有可取的优势）
性能
grpc一开始(2016年前)的性能貌似是dubbo的2/3左右
但是2017年的一篇博客看出grpc已经开始超越dubbo