服务间通信

REST

REST (Representational State Transfer) 是一种架构风格，它本身只是一种设计理念，并不是具体的协议，其本身最重要的理念就是资源。

REST 本身并不受限底层协议，但是大多数情况下它是基于 HTTP 协议的，因为 HTTP 的很多特性刚好跟 REST 的设计理念吻合，比如 HTTP 的动词 (GET、POST、PUT、DELETE) 可以直接映射到 REST 的操作上。

很多项目都会根据自己的 API 去提供一个客户端，比如 k8s go 客户端，Java 客户端，客户端都是对自身 REST API 的一种封装。

我们可以使用 swagger 提供的 OpenAPI 来描述 REST API，OpenAPI 是一个开放的 API 描述规范，它允许开发者使用一种标准化的方式来描述 RESTful API 的结构和行为，从而自动的生成文档，并且可以生成客户端代码。

OpenAPI 规范的主要特点包括：

• ​​ 统一文档 ​​：通过 YAML 或 JSON 格式定义接口，生成可读性强的交互式文档 (如 Swagger UI)。 ​- ​ 自动化开发 ​​：支持代码生成工具自动创建客户端 SDK 或服务端框架 ​- ​ 协作优化 ​​：前后端团队可基于同一规范并行开发，减少沟通成本

RPC 通信协议

所谓的微服务架构，主要就是指的是 RPC 服务，RPC 服务基本上仅存在于后台系统的内部。

rpc 远程服务调用，目的是屏蔽网络编程的细节，能够像调用本地方法本地函数一样调用远程方法。

rpc 框架通过代理模式将网络通信屏蔽，服务调用者仅需像本地调用者一样调用一个 RPC 方法即可调用执行远程方法。

rpc 通信的本质就是调用方将调用的方法和参数发送到被调用方，被调用方处理后将结果返回给调用方的过程

• 首先，方法的输入参数，输出参数，这些对象要进行二进制的转换传输，比如 google 的 gRPC 使用的就是 protobuf 二进制序列化
• 被调用方接收到数据包后，将二进制数据进行解码，然后获取其方法名称，参数，然后调用本地方法，最后将结果返回给调用方。

常见的 RPC 框架有：

• grpc
• thrift

rpc 框架只是一种用于屏蔽远程调用的设计手段，其与 http 协议或者 tcp 协议不在一个层面，我们可以将 rpc 的底层设计为 tcp 亦或者 http，比如 grpc 底层就是基于 http2 协议的。

GraphQL

它支持客户端定义查询，从而避免发送多个请求来获取相同信息的情况。

它可以很大程度的改善客户端的性能，避免服务端需要多个专门实现这类聚合的功能，多次查询后端的 API 的行为使用 GraphQL 可以仅仅查询一次，并且 GraphQL 还可以让调用的数据不返回多余的无用数据，这就是 GraphQL 的意义。

不过由于客户端拥有动态查询的功能，很多时候服务端就会导致频繁的查询，从而导致服务端压力过大。

通常由于 GraphQL 的查询特性，它更适合查询的工作，所以很多工程师都是将它作为查询功能，将 REST API 作为写入的功能。

另外 GraphQL 千万不要跟微服务的底层数据耦合在一起，使用该协议时不要认为你调用的不是微服务整体而只是一个数据库入口而已，因为微服务本身是有自己的内部逻辑和行为的。

GraphQL 适合在系统的外部使用，为外部的客户端提供功能，它非常适合于移动设备，毕竟能减少网络请求次数，因为它查询的过程即便是后端的行为再多，反应在客户端的行为都是只进行了一次的查询工作。

GraphQL 也适合于外部的 API，外部客户端经常要进行多次的调用来获取所要的信息，如果减少调用次数将大大方便了客户的工作。

GraphQL 的本质是一种聚合和过滤机制，通过它聚合多个微服务的调用，以及过滤掉无用的数据，从而减少网络请求次数，从而提高系统的性能。API 网关也是一种数据的导向工作，不过它更多的不是聚合数据，而是将请求进行合理的映射路由处理。

但现代架构中，通过将 GraphQL 集成到网关层 (如华为云方案、腾讯云 API 网关)，已经实现了两者的优势互补。这种融合模式既保留了网关的流量管理能力，又赋予其类似 GraphQL 的数据处理灵活性，成为当前云原生架构的主流选择

API 网关和 GraphQL 结合的方式不同也适合不同的应用场景。

推荐采用 GraphQL 前置的场景 ​​

​- ​ 客户端主导型业务 ​​：如社交网络动态信息流，需高频调整字段组合 (Facebook 的新闻流采用此模式) ​​- 多版本并行需求 ​​：通过 GraphQL 的 schema 版本管理实现蓝绿发布，避免网关路由规则频繁变更 ​​- IoT 设备接入 ​​：低功耗设备需最小化数据传输量 (某智能家居平台实测流量节省达 70%) ​​ 建议采用 GraphQL 后置的场景 ​​ ​​

• 高安全要求系统 ​​：金融/医疗领域需网关统一实施审计日志和合规检查 ​​- 混合协议环境 ​​：需网关完成 REST 到 gRPC 等协议转换 (如京东订单系统的支付服务集成) ​​- 全局流量管控 ​​：电商大促期间通过网关动态调整 GraphQL 节点的流量分配

消息代理/消息队列

消息队列是一种用于异步通信的中间件，为了防止服务之间的耦合，使用消息队列来进行服务之间的通信可以完美解决耦合的问题。

发送方将消息放入队列，消费者从该队列中提取数据，这通常叫做点对点的消息代理模式。

发布/订阅模式

上面介绍的是使用的消息队列的点对点模式，如果是主题模式，那么就变成了经典的发布和订阅模式，多个消费者订阅一个主题，每一个消费者都会收到一个该消息的副本。

消息代理提供了一种消息确认机制，当有了这个机制之后，代理可以保证消息一定会被触达 --- 代理将保留消息，直到所有的消费者都确认收到该消息。这通常需要持久化的能力。

数据序列化技术

Json 是文本序列化格式的首选，因为浏览器通常是对 Json 的支持非常友好的。

如果使用 gRPC 通常我们要使用 protobuf 来进行数据的序列化和反序列化。

protobuf 是一种二进制序列化格式，它的序列化和反序列化速度非常快，体积也非常小。