简单点，HTTP是协议，RPC是概念！实现RPC可以基于HTTP协议（Feign），TCP协议(Netty)，RMI协议（Soap），WebService（XML—RPC）框架。传输过程中，也因为序列化方式的不同，又有一些框架和协议，比如Dubbo中的Dubbo协议，gRpc—Protobuf序列化协议等等。
GRPC是跨语言的，为何偏偏在go语言上这么火？
首先grpc最大的使用场景是微服务，go语言很容易编译成不依赖第三方动态链接库的可执行程序，而且这个可执行程序通常也不大，这个特性对容器化非常友好。所以go顺利成为微服务领域扛把子的语言，k8s，etcd，docker 这些核心组件都是用golang实现的。其次你如果了解go的grpc的话，你会看到很多grpc的插件，现在很多go服务化框架都不会仅仅提供grpc接口，利用插件功能顺带把http接口也实现了，也就是说一个服务提供了grpc和restful api。
微服务调用为什么用RPC框架，http不更简单吗？
简单点，HTTP是协议，RPC是概念！实现RPC可以基于HTTP协议（Feign），TCP协议(Netty)，RMI协议（Soap），WebService（XML—RPC）框架。传输过程中，也因为序列化方式的不同，又有一些框架和协议，比如Dubbo中的Dubbo协议，gRpc—Protobuf序列化协议等等。
其实，都是基于远程调用的概念，何为远程调用？重点是，RPC就是远程调用，远程调用就是客户端把调用的接口，参数，参数类型，方法，返回值，返回值类型等（这些称为方法签名），通过如上的协议，发送给服务端，告知服务端需要调用的接口方法，这个过程就是RPC的实现过程！HTTP和RPC是不同层面的两个东西！性能方面，HTTP本身是基于TCP协议的，属于应用层协议，所以HTTP协议本身在实现过程中就会占用大量的资源（内存，带宽等），性能上肯定没有通过TCP直接实现RPC协议快，不管HTTP如何优化肯定的是不如TCP的！而TCP则是依靠字节码，现在普遍采用的是将客户端调用的接口信息，序列化的方式发送给服务端，序列化框架又包含很多（Hession，Protobuf，Kryo等等，序列化性能最高的是Kryo，序列化后字节码最小的是Protobuf），序列化后的字节码越小，占用带宽越少，序列化时间越短，线程IO等待时间就会越小。
