在上一篇文章中，有提过，在微服务的选型方面，使用什么协议来构建微服务体系，一直是个比较热门的话题，目前，较常用的是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效率高，但是实现起来非常复杂。所以，对于这俩的选择，目前没有一个标准，只能依赖业务场景，进行站位。