用于微服务的REST消息传递层是否足够快？

Question

我对微服务知之甚少，因此这无疑是我学习阶段的一部分。假设我有多个nodejs微服务（身份验证服务，用户服务，车辆服务等）。在此之间共享数据的最佳方法是什么？

HTTP调用是否足够好？，因为仅通过“ Pointsman”服务或其他内容调用许多HTTP调用非常容易。所有这些nodejs服务将在同一台机器上运行，因此它们应具有相当快的速度。 HTTP调用也是异步的，因此您可以控制服务如何轻松地相互等待。基本的调用测试似乎超级快，但是很难知道更大的数据将如何工作。

我问的原因是因为人们谈论消息传递层。消息将放置在要观看服务的地方。因此，服务将放置并提取为其分配的消息。

我只是觉得HTTP调用足够好，为什么不使用它们呢？

Answer 1

要回答您的问题，我们需要了解差异。微服务之间需要进行的各种通信，并以此为基础进行区分。方法。

以Facebook的域示例为例，讨论通信类型：

1. 用于消息传递：您喜欢某些帖子。在这种情况下，需要发生很多事情，例如首先需要增加帖子的赞数，然后一些推荐服务将根据您对推荐的更改来尝试查看您喜欢的帖子类型，某些应用程序服务将发送一些通知到有关帖子更新的应用，等等。在这些情况下，基于诸如UserLikedAPost之类的事件，许多事情都需要在diff中发生。微服务，我们应该在诸如Kafka或Rabbit MQ之类的Message Queue中编写此类事件，然后其他服务可以订阅并完成相应的工作。

在这种情况下，我们不希望在发送用户HTTP请求的最终响应之前完成所有其他操作，因为这样会使诸如请求的时间增加。

1. 用于HTTP或gRPC ：获取我的帐户详细信息：在这种情况下，显示数据时会显示您的兴趣和工作，而这一切都是diff的一部分。兴趣和工作等微服务。为此，当一个请求到来时，该请求需要使用Rest或gRPC（REST与JSON进行了高度优化）调用每个服务以返回结果。

现在，我为您提供了同时需要消息传递和HTTP（或gRPC）的示例。

此外，在许多情况下，您可能更喜欢一种方案。您可能想阅读：microservices pattern，以了解有关这些事情的更多信息

Answer 2

问题不是关于足够快的问题，而是关于可扩展和可用的微服务。

HTTP协议已同步

人们普遍认为HTTP是异步的。 Http是同步协议，但您的客户端可以异步处理。例如。当您使用http调用任何服务时，您的http客户端将安排在后端线程（异步）上。但是，http调用将一直等待，直到超时或响应返回为止，在此期间，http调用链一直在同步等待。现在，如果您一次有数百个请求，则可以想象同步调度了多少个http调用，并且可以运行套接字。

AMQP

在微服务架构中，我们更喜欢AMQP（高级消息队列协议）。这意味着服务将消息放入队列中，然后将其忽略。这是真正的异步传输协议，因为您的服务一旦将消息放入队列中就完成了，有兴趣的服务会选择它们。

首选这种类型的协议，因为即使其他服务停止运行，您也可以放心扩展，因为它们最终将获得消息/事件/数据。

这就是为什么HTTP不是共享消息/数据的首选方式。