为什么 Nestjs 框架在微服务方法中使用与 HTTP 不同的传输层？

Question

我已经使用 Spring Boot 开发微服务有一段时间了，使用 feign 客户端、REST 模板和 AMPQ 代理在每个微服务之间建立通信。

现在，我正在学习 NestJs 及其微服务方法。我注意到 Nestjs 使用 TCP 作为默认传输层，这与 Spring Boot 的方式不同。

为什么nestjs更喜欢那些传输层（TCP，AMPQ）而不是HTTP？HTTP 不是 REST 微服务的传输协议吗？

来自 NestJs 文档：

“微服务本质上是一个使用与 HTTP 不同的传输层的应用程序”

Answer 1

主要原因是速度慢。HTTP 方法的问题在于，使用 HTTP，JSON 可能会产生不必要的处理时间来发送和翻译信息。

http-json 的一个问题是发送的 JSON 的序列化时间。这是一个昂贵的过程，想象一下大数据的序列化。

除了 JSON 之外，还有许多需要进一步解释的 HTTP 标头，这些标头可能会被丢弃。唯一需要关心的是维护一个用于发送和接收消息的层。因此，微服务之间使用HTTP协议配合JSON进行通信非常慢。有一些优化技术，但这些技术很复杂，并且不会增加显着的性能优势

此外，HTTP 等待的时间比传输数据的时间还要多。

Answer 2

如果您查看 OSI 模型，就会发现 HTTP 是第 7 层（应用程序）的一部分。TCP 是第 4 层（传输）。

当查看第 4 层时，没有确定的特征使其成为 HTTP、AMPQ、gRPC 或 RTSP。第 4 层明确说明了远程设备如何传输和接收数据。

现在，这就是网络和软件开发世界的碰撞点。网络人员会使用“传输”来表示第 4 层，而编程人员使用“传输”来表示数据包传输到另一个组件的方式。

“传输”（或文档中使用的“传输器”）的含义用作此架构中如何共享消息的抽象。

查看文档，如果您正在为微服务寻找类似 AMPQ 的东西，您可以使用NATS或REDIS（这两种实现都是由它们构建的）。