為什么 nestjs 框架在微服務方法中使用不同於 HTTP 的傳輸層？

Question

賞金將<\/a>在 3 天后<\/span>到期。 此問題的答案有資格獲得+100<\/span>聲望賞金。 Francisco Aguilera<\/a>正在尋找一個規范的答案。

一段時間以來，我一直在使用 Spring Boot 開發微服務，使用 feign 客戶端、rest 模板和 AMPQ 代理來建立每個微服務之間的通信。

現在，我正在學習 NestJs 及其微服務方法。 我注意到nestjs 使用TCP 作為默認傳輸層，這與使用Spring Boot 完成的方式不同。

為什么nestjs 更喜歡那些傳輸層（TCP、AMPQ）而不是HTTP？ HTTP不是REST微服務的傳輸協議嗎？

來自 NestJs 文檔：

“微服務本質上是一個使用與 HTTP 不同的傳輸<\/strong>層的應用程序”

Answer 1

如果您查看 OSI 模型，HTTP 是第 7 層（應用程序）的一部分。 TCP 是第 4 層（傳輸）。

在查看第 4 層時，沒有決定性特征使其成為 HTTP、AMPQ、gRPC 或 RTSP。 第 4 層明確說明了遠程設備如何傳輸和接收數據。

---

現在，這就是網絡和軟件開發世界碰撞的地方。 網絡人員將使用“傳輸”表示第 4 層，而編程人員使用“傳輸”表示將數據包傳輸到另一個組件的方式。

“傳輸”（或文檔中使用的“傳輸器”）的含義被用作此架構中如何共享消息的抽象。

如果您正在為您的微服務尋找類似 AMPQ 的東西，請查看文檔，您可以使用NATS或REDIS （這兩種實現都是由它們構建的）。

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

Answer 2

主要原因是速度慢。 HTTP 方法的問題在於，使用 HTTP，JSON 會產生不需要的處理時間來發送和翻譯信息。

http-json 的一個問題是發送的 JSON 的序列化時間。 這是一個昂貴的過程，想象一下大數據的序列化。

除了 JSON 之外，還有許多 HTTP 標頭需要進一步解釋，這些標頭可能會被丟棄。 唯一需要考慮的是維護一個用於發送和接收消息的層。 因此，使用 JSON 的 HTTP 協議在微服務之間進行通信非常慢。 有一些優化技術，這些技術很復雜，不會增加顯着的性能優勢

此外，HTTP 等待的時間比它傳輸數據的時間要長。