微服务主流通信协议详解

一卷旌收千骑虏，万全身出百重围。这篇文章主要讲述微服务主流通信协议详解相关的知识，希望能为你提供帮助。
【微服务主流通信协议详解】一个完整的微服务调用框架包含3个部分。
1）通信框架：主要解决客户端和服务器端如何建立连接、管理连接以及服务器端如何处理请求的问题。2）通信协议：主要解决客户端和服务器端采用哪种数据传输协议的问题。
3）序列化和反序列化：主要解决客户端和服务器端采用哪种数据编解码的问题。
远程服务调用是分布式服务框架的基础和核心功能。目前主流的分布式服务框架使用两种传输协议。
1）RPC协议：以HSF、Dubbo、Thrift、gRPC、Motan为代表的框架使用的协议。
2）HTTP REST协议：以Spring Cloud为代表的框架使用的协议。
RPC远程过程调用（Remote Procedure Call，RPC）框架作为架构微服务化的基础组件，能大大降低架构微服务化的成本，提高服务调用方与服务提供方的开发效率，屏蔽跨进程调用函数（服务）的各类复杂细节。

RPC调用的四个关键细节

客户端如何找到服务器端地址

多数RPC产品采用本地负载均衡策略，即调用方启动时从注册中心拉取服务地址信息后，在本地缓存，运行过程中真正发起调用时，直接从本地缓存读取服务地址信息，根据一定的负载均衡算法选取某一个地址，发起点对点的直接调用。当服务器端地址信息发生变更时（如节点上下线），由注册中心实时推送变更信息到所有的调用方同步更新。

服务器端如何处理请求

服务器端I/O的方式通常分为3种处理方式：
同步阻塞（Blocking I/O，BIO）方式—— 一次请求需要创建一个线程处理。
同步非阻塞（Non-blocking I/O，NIO）方式——多个连接共用一个线程。
异步非阻塞（Asynchronous I/O，AIO）方式——当进行读写操作时，AIO只需直接调用API的read或write方法。

序列化和反序列化

客户端和服务器端交互时将参数或结果转化为字节流在网络中传输，那么将数据转化为字节流或者将字节流转换成能读取的固定格式时，就需要进行序列化（数据编码）和反序列化（数据解码），序列化和反序列化的速度也会影响远程调用的效率。
常用的序列化方式分为两类：文本类（如XML、json等）、二进制类（如Hessian、Thrift等）。而具体采用哪种序列化方式。主要取决于3个方面的因素：支持数据结构种类的丰富度、跨语言支持、性能。

如何进行网络传输

多数RPC框架会选择TCP作为传输协议，也有部分会选择HTTP（如gRPC使用HTTP/2）。不同的协议各有利弊，TCP更加高效，而HTTP在实际应用中更加灵活。
RPC的优点：

对于服务器端的开发人员而言，容易设计、开发。
对于消费者而言，调用非常简单。便于做集中的监控。
基于socket的二进制RPC协议，建立连接延迟低、网络传输效率高。
支持有状态的长连接，可进行双向通信，实时性好。
在各个企业的使用较为成熟，许多企业都有自己的RPC实践，并已广泛应用在生产环节。

RPC的缺点：

紧耦合：API一旦发布，就难以再做改动。客户端必须使用特定的框架，而且需要引入API包。
没有统一的设计风格：增加了客户端开发人员的学习成本。难以实现通用的客户端库，每个RPC框架都有各自的协议。通常以动词的形式设计API，一个功能就增加一个API，设计时很少考虑领域模型。
掩盖网络的复杂性：开发人员很容易混淆远程调用与本地调用。实际上网络调用与本地调用是完全不同的，RPC的调用方式，让使用者很难意识到是在进行网络调用，忽略了针对网络复杂性的处理。这样会损害用户（客户端）可感知的性能。

RESTfulRESTful是一种网络应用程序API的设计风格和开发方式，基于HTTP，可以使用XML格式定义或json格式定义。最常用的数据格式是json。由于json能直接被javascript读取，因此以json格式编写的REST风格的API具有简单、易读、易用的特点。

REST风格协议的特点如下：
1）每个统一资源标识符（Uniform Resource Identifier，URI）代表一种资源。任何事物只要有被引用的必要，它就是一个资源；要让一个资源可以被识别，需要有一个唯一标识，在Web中这个唯一标识就是URI。2）客户端使用GET、POST、PUT、DELETE这4个表示操作方式的动词对服务器端资源进行操作：GET用来获取资源，POST用来新建资源（也可以用于更新资源），PUT用来更新资源，DELETE用来删除资源。3）通过操作资源的表述形式来操作资源，资源在外部的具体呈现可以有多种表述形式（例如文本资源可以采用html、XML、json等格式，图片可以使用PNG或JPG格式展现出来），在客户端和服务器端之间传送的也是资源的表述，而不是资源本身。
4）客户端与服务器端之间的交互在请求之间是无状态的，从客户端到服务器端的每个请求都必须包含理解请求所必需的信息。这里说的无状态通信原则，并不是说客户端应用不能有状态，而是指服务器端不应该保存客户端状态。
RESTful API的优点：

使用HTTP作为应用层协议（注意：不是传输层），没有耦合性。
可以使用浏览器扩展（如Postman）或者curl之类的命令行来测试RESTful API。
客户端使用任意支持HTTP的工具即可。使用类似Netflix Feign这样的专门设计的工具，可以做到接近RPC的调用方式。
可以方便地发布到外网环境。HTTP对防火墙友好，可以设置各种安全策略。
基于资源的设计思想，强迫设计人员抽象资源，思考模型，使设计人员加深对业务模型的理解。
不需要中间代理，简化了系统架构。

RESTful API的缺点：

由于HTTP是应用层协议，本身比TCP慢一些；加之数据本身是自描述的文本格式，需要占用更多的带宽，因此相比于RPC，RESTful API的速度会稍慢一些。
并不是所有业务场景都适合采用RESTful API。也不是在设计API时就一定要遵守所有规则，如何取舍还要看具体业务需求，适合的才是最好的，毕竟架构也是伴随业务的发展而不断演进的。