微服务选型---HTTP OR RPC

2021-04-13 15:39:55 浏览数 (1)

在上一篇文章中,有提过,在微服务的选型方面,使用什么协议来构建微服务体系,一直是个比较热门的话题,目前,较常用的是http和rpc两种方式,本文将对比这两种方式的优劣,从而使得读者可以根据实际需求,去选择通讯方式。

RPC:远程过程调用(Remote Produce Call),自定义数据格式(较为通用的有Protobuf和Json),基于原生的TCP进行通讯,速度快,效率高。

HTTP:超文本传输协议(HyperText Transfer Protocol),是一种网络协议,通常在7层模型的传输层,其本身基于TCP,有特定的传输格式。现在的浏览器采用的都是Http协议(此处Https归为Http,其是在Http基础上做了加密操作)

OSI七层模型

正如上文所说,HTTP处于七层模型的最顶端,即应用层,TCP处于第四层,即传输层。HTTP较TCP相比,包含了大量的HTTP头部信息,这就使得有用信息比低,传输效率低。从使用者的角度来看,更多的是传输速度快,QPS(Query Per Second)优,所以从这个角度来看,HTTP的可读性似乎不是那么重要了。

在一般情况下,两个应用或者接口之间的调用方式,可以分为HTTP和RPC两种,如下图所示:

最最简单的方式,如果是部门之间,那么建议使用HTTP方式,这样使得耦合度尽可能的低,在业界,有个不成文的约定,就是部门之间尽量使用HTTP方式来调用,即使有时候中间件比如REDIS或者KAFKA使得业务实现更容易,这样的目的只有一个,在出现问题的时候,防止双方互相推卸责任。

现在继续回到上图,在上图中,RPC其功能上较HTTP更为丰富,大致包括:

1、server选择:

目前大部分RPC框架在底层server选择上都使用的轮询。假如有server端有ip0, ip1,ip2,ip3...ipn,在client内部实现一个机制,即某次调用的ip0 服务,那么下次就调用ip1的服务。

轮询方式,如果被调用的服务负载较低,或者业务功能简单、永不出错(理想情况下),那么这种基本就能满足业务需求。但是随着接触互联网的用户越来越多,QPS达到百万级别,这样在服务器扛不住,或者某一台服务器宕机的情况下,上面这种简单的轮询方式显然不能满足一个优秀的RPC框架的需求,这就使得在server选择上面,需要考虑下游服务的负载情况以及该服务的可用性等等因素。

2、序列化和反序列化:

现在业界通用的RPC协议是Protobuf以及Json,在调用端,将需要的参数进行序列化(Protobuf)和封装(Json),在被调用放则进行反序列化和解析,从而拿到对应的参数进行数据处理。

3、通信:

RPC之间的通信,一般有HTTP、TCP和UDP三种,HTTP的优缺点上面已经有提,所以此处不再进行赘述。TCP是业界使用最多的通信方式,其特点是可靠传输,后面笔者将会深入带大家了解下TCP。而对于UDP,大家第一印象就是不可靠的,因为其只负责将数据包传输出去,不管对方有没有接收到,这样就导致对于比较重要的业务,使用可靠的TCP进行传输,对于不重要的业务,使用HTTP进行通讯,这就显得UDP比较鸡肋。

4、容错:

容错功能,是一个优秀的RPC框架非常重要的功能,比如,如果下游某个服务器挂了,或者下游所有服务均不可用,那么是否能够保证整个业务正常运行,即不至于影响其他业务线。笔者所负责的业务之前就有存在该情况,在节假日的时候,流量可能会较平时增加很多。这样就有可能导致下游某些服务扛不住了,从而导致整个业务线或者数据流受到了影响,由于临时扩容需要时间,也需要人员配合,这就一定程度上导致流量浪费,业务异常,从而引起收入损失。从该点来看,限流和熔断,也是非常重要的功能之一。

上面,我们简单介绍了HTTP以及RPC,HTTP方式较简单,但效率低,RPC效率高,但是实现起来非常复杂。所以,对于这俩的选择,目前没有一个标准,只能依赖业务场景,进行站位。

0 人点赞