简体繁体 English

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

[英]Why does nestjs framework use a transport layer different than HTTP in a microservices approach?

原文 2020-09-29 02:05:55 7 2 node.js/ microservices/ nestjs

I have been developing microservices with Spring Boot for a while, using feign client, rest template and AMPQ brokers to establish communication between each microservice.一段时间以来，我一直在使用 Spring Boot 开发微服务，使用 feign 客户端、rest 模板和 AMPQ 代理来建立每个微服务之间的通信。

Now, I am learning NestJs and its microservice approach.现在，我正在学习 NestJs 及其微服务方法。 I've noticed that nestjs uses TCP as the default transport layer which is different from the way it is done with Spring Boot.我注意到nestjs 使用TCP 作为默认传输层，这与使用Spring Boot 完成的方式不同。

Why does nestjs prefer those transport layers (TCP, AMPQ) instead of HTTP?为什么nestjs 更喜欢那些传输层（TCP、AMPQ）而不是HTTP？ isn't HTTP the transport protocol for rest microservices? HTTP不是REST微服务的传输协议吗？

From NestJs documentation:来自 NestJs 文档：

"a microservice is fundamentally an application that uses a different transport<\/strong> layer than HTTP" “微服务本质上是一个使用与 HTTP 不同的传输<\/strong>层的应用程序”
<\/blockquote>"

2 个解决方案

If you look a the OSI model, HTTP is part of Layer 7 (Application).如果您查看 OSI 模型，HTTP 是第 7 层（应用程序）的一部分。 TCP is Layer 4 (Transport). TCP 是第 4 层（传输）。

When looking at Layer 4 there is no determining characteristic that makes it HTTP, AMPQ, gRPC, or RTSP.在查看第 4 层时，没有决定性特征使其成为 HTTP、AMPQ、gRPC 或 RTSP。 Layer 4 is explicitly how data is transmitted and received with the remote device.第 4 层明确说明了远程设备如何传输和接收数据。

Now, this is where networking and the software development worlds collide.现在，这就是网络和软件开发世界碰撞的地方。 Networking people will use "transport" meaning Layer 4, while Programming people use "transport" meaning the way a packet of data is transmitted to another component.网络人员将使用“传输”表示第 4 层，而编程人员使用“传输”表示将数据包传输到另一个组件的方式。

The meaning of "transport" (or "transporter" as used in the docs) is used as an abstraction from how messages are shared in this architecture. “传输”（或文档中使用的“传输器”）的含义被用作此架构中如何共享消息的抽象。

Looking at the documentation if you are looking for something like AMPQ for your microservice you can use NATS or REDIS (both implementations are built by them).如果您正在为您的微服务寻找类似 AMPQ 的东西，请查看文档，您可以使用NATS或REDIS （这两种实现都是由它们构建的）。

https://docs.nestjs.com/microservices/basics#getting-startedhttps://docs.nestjs.com/microservices/basics#getting-started

The main reason is it is slow.主要原因是速度慢。 The problem with HTTP approach is that, with HTTP, JSON can generate an unwanted processing time to send and translate the information. HTTP 方法的问题在于，使用 HTTP，JSON 会产生不需要的处理时间来发送和翻译信息。

One problem with http-json is the serialization time of JSON sent. http-json 的一个问题是发送的 JSON 的序列化时间。 This is an expensive process and imagine serialization for a big data.这是一个昂贵的过程，想象一下大数据的序列化。

In addition to JSON, there are a number of HTTP headers that should be interpreted further which may be discarded.除了 JSON 之外，还有许多 HTTP 标头需要进一步解释，这些标头可能会被丢弃。 The only concern should be to maintain a single layer for sending and receiving messages.唯一需要考虑的是维护一个用于发送和接收消息的层。 Therefore, the HTTP protocol with JSON to communicate between microservices is very slow.因此，使用 JSON 的 HTTP 协议在微服务之间进行通信非常慢。 There are some optimization techniques and those are complex and does not add significant performance benefits有一些优化技术，这些技术很复杂，不会增加显着的性能优势

Also,HTTP spends more time waiting than it does transfer data.此外，HTTP 等待的时间比它传输数据的时间要长。