首先写结论：

  RPC主要用于公司内部的服务调用，性能消耗低，传输效率高，服务治理方便。

  HTTP主要用于对外的异构环境，浏览器接口调用，APP接口调用，第三方接口调用等。

远程调用 Dubbo 与 Feign 的区别（引用）

一、相同点

Dubbo 与 Feign 都依赖注册中心、负载均衡。

二、区别

1、协议

Dubbo：

  • 支持多传输协议(Dubbo、Rmi、http、redis等等)，可以根据业务场景选择最佳的方式。非常灵活。
  • 默认的Dubbo协议：利用Netty，TCP传输，单一、异步、长连接，适合数据量小、高并发和服务提供者远远少于消费者的场景。

Feign：

基于Http传输协议，短连接，不适合高并发的访问。

2、负载均衡

Dubbo：

  • 支持4种算法（随机、轮询、活跃度、Hash一致性），而且算法里面引入权重的概念。
  • 配置的形式不仅支持代码配置，还支持Dubbo控制台灵活动态配置。
  • 负载均衡的算法可以精准到某个服务接口的某个方法。

Feign：

  • 只支持N种策略：轮询、随机、ResponseTime加权。
  • 负载均衡算法是Client级别的。

3、容错策略

Dubbo：

支持多种容错策略：failover、failfast、brodecast、forking等，也引入了retry次数、timeout等配置参数。

Feign：

利用熔断机制来实现容错的，处理的方式不一样。

 

 

Spring Cloud 为什么需要RPC（引用https://www.geekdigging.com/2019/09/17/3112135178/的1.4）

       在Spring Cloud构建的微服务系统中，大多数的开发者使用都是官方提供的Feign组件来进行内部服务通信，这种声明式的HTTP客户端使用起来非常的简洁、方便、优雅，但是有一点，在使用Feign消费服务的时候，相比较Dubbo这种RPC框架而言，性能堪忧。

虽说在微服务架构中，会讲按照业务划分的微服务独立部署，并且运行在各自的进程中。微服务之间的通信更加倾向于使用HTTP这种简答的通信机制，大多数情况都会使用REST API。这种通信方式非常的简洁高效，并且和开发平台、语言无关，但是通常情况下，HTTP并不会开启KeepAlive功能，即当前连接为短连接，短连接的缺点是每次请求都需要建立TCP连接，这使得其效率变的相当低下。

对外部提供REST API服务是一件非常好的事情，但是如果内部调用也是使用HTTP调用方式，就会显得显得性能低下，Spring Cloud默认使用的Feign组件进行内部服务调用就是使用的HTTP协议进行调用，这时，我们如果内部服务使用RPC调用，对外使用REST API，将会是一个非常不错的选择，恰巧，Dubbo Spring Cloud给了我们这种选择的实现方式。

 

 

HTTP和RPC的优缺点（引用http://www.ccutu.com/244407.html的2）

传输协议

RPC:可以基于TCP协议，也可以基于HTTP协议

HTTP:基于HTTP协议

传输效率

RPC:使用自定义的TCP协议，可以让请求报文体积更小，或者使用HTTP2协议，也可以很好的减少报文的体积，提高传输效率

HTTP:如果是基于HTTP1.1的协议，请求中会包含很多无用的内容，如果是基于HTTP2.0，那么简单的封装以下是可以作为一个RPC来使用的，这时标准RPC框架更多的是服务治理

性能消耗

RPC:可以基于thrift实现高效的二进制传输

HTTP:大部分是通过json来实现的，字节大小和序列化耗时都比thrift要更消耗性能

负载均衡

RPC：基本都自带了负载均衡策略

HTTP：需要配置Nginx，HAProxy来实现

服务治理

RPC：能做到自动通知，不影响上游

HTTP:需要事先通知，修改Nginx/HAProxy配置