Http服务与RPC服务对比

http服务和Rpc服务都是用来实现系统之间的信息交换的。不同的是：

（以下均为笔者自己的总结，如有不正之处，欢迎指出）

原理：

http服务是通过http请求去获取响应数据，和在浏览器地址栏输入URL来获取网页是一样的原理。通过HttpClient发送请求，并解析返回的结果。
RPC框架则是通过注册中心管理服务的提供方IP和端口，服务调用方通过封装好参数，然后调用服务的提供方的实现。底层的架构用到了注册中心，参数的序列化和数据的传输。从服务调用方来看，在RPC框架下调用服务和在自己系统里调用服务一样。

性能

http服务使用的http报文格式，这势必导致http服务的报文头占据了很大的网络开销。在数据段比较少时，尤为明显；就算数据量比较大时，报文头大开销也不容忽视。
RPC框架中的报文为开发者自定义，只包含少量报文头信息。大大减少了网络传输上的消耗。

开发效率

对于前期部署阶段，http服务几乎是0部署，只要在开发时构建一个http请求去访问服务提供方，然后处理返回数据。而RPC框架则需要部署整个框架，并且需要一个注册中心来管理这些接口服务，会带来一些硬件上的开销。
对于后期的迭代开发来说，http可以封装成公共方法或组件在项目中使用。RPC框架则需要在提供新服务时，公布自己的jar包（服务接口interface）以供调用方引用。且每次接口有改动时，都必须要更新jar包，并通知调用方更新jar包。一定程度上增加了服务方和调用方的耦合度和开发工作量。

安全性

安全性方面，HTTP几乎没有安全性方面的策略，只要知道URL，并且了解入参形式，任何人都可以构建一个请求去访问这些接口。要想加强安全机制，只能增加调用方校验机制。另外，服务提供方的URL变更，都会导致服务不可用，增加了系统风险。
RPC框架则不同，RPC框架有注册中心只要服务方的接口ID和服务实例名没有变更，都可以通过自动注册机制来调用。并且通过注册中心的负载均衡策略来保证服务的响应效率。此外，RPC框架可以控制调用权限，对于未制定权限的系统，将阻止起调用，保证了系统安全。

使用场景

HTTP更适合小企业，内部系统不多，且调用场景不频繁，对响应速度没有太大要求的场景。在微服务系统较多，接口数量巨大的场景下，http服务将变得难以管理。如果调用量巨大，还会导致响应缓慢等问题。
一般大型企业，或互联网公司，都会配置RPC框架来实现系统间的数据交换。不仅利于管理，且保证了调用效率。然而配置RPC框架必然会增加运维成本，有时需要一整个团队来维护这个框架等运行。