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框架必然会增加运维成本,有时需要一整个团队来维护这个框架等运行。