简介

客户端-服务器通信是当今软件开发的核心操作之一。一个系统(客户端)可以通过在彼此之间发送消息并传达所请求工作的结果来请求在另一个系统(服务器)上完成工作。当您开始管理发送消息的速率、服务在给定时间可以处理的请求数量以及客户端需要响应的速度时,管理这种通信很容易在网络层变得复杂。

在这篇文章中,我们着眼于管理网络应用程序之间的通信的两种方法,以及如何解决扩展流程带来的一些问题。

同步和异步处理

什么是同步处理?

同步处理是客户端-服务器通信中的传统处理方式。客户端向服务器发送请求并等待服务器完成作业并发送响应,然后客户端才能继续执行任何其他工作。这个过程通常被称为_blocking_(即客户端被阻止做任何其他工作,直到收到响应)。

[](https://res.cloudinary.com/practicaldev/image/fetch/s--XDEL6HTK--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://dev-to- uploads.s3.amazonaws.com/uploads/articles/vcxb61v9zurlobikcmxu.png)

什么是异步处理?

异步处理与同步处理相反,因为客户端在发出请求后不必等待响应,可以继续其他形式的处理。这个过程被称为_non-blocking_,因为客户端的执行线程在发出请求后并没有被阻塞。这允许系统更好地扩展,因为可以在给定的时间内完成更多的工作。

[](https://res.cloudinary.com/practicaldev/image/fetch/s--1ft08GMG--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://dev-to- uploads.s3.amazonaws.com/uploads/articles/ik6odk5ba5jcbyw7gnol.png)

同步和异步处理的区别

现在我们了解了同步和异步处理是什么,让我们比较两者,看看异步处理如何提供比异步处理更多的好处:

• 同步请求阻塞了客户端的执行线程,导致它们等待请求所花费的时间,然后才能执行另一个操作。另一方面,异步请求不会阻塞并允许在给定时间内完成更多工作。

• 同步请求的阻塞特性导致客户端消耗更多资源,因为执行线程在等待期间被锁定。异步请求立即释放执行线程以执行更多功能,而无需等待响应。

• 由于无法确定请求需要多长时间,因此很难构建具有同步处理的响应式应用程序。您执行的阻塞操作越多,系统就会变得越慢。使用异步处理,响应时间很快,因为客户端不必等待请求。

• 异步处理的容错性比同步处理高,因为当请求失败时很容易构建重试系统,客户端不会因为请求重试多少次或需要多长时间而停滞不前。

• 异步处理可以实现客户端请求的并行执行,而同步处理请求只能顺序处理。

如何实现异步处理

上面的部分阐明了异步处理是构建可扩展和高度响应的应用程序的方式。然而,异步处理的所有好处都是以系统架构为代价的。

同步处理是一个简单的过程。您无需考虑太多即可实现它 - 这是客户端-服务器通信中的默认行为。

为了实现异步处理,需要在客户端和处理服务器之间插入一个中间人。这个中间人充当客户端和服务器之间的消息代理,接收请求消息并根据处理服务器在任何给定时刻可以处理的负载将它们分发到服务器。一旦请求消息被摄取,客户端会得到快速响应,并且可以继续执行其他活动而无需等待服务器。

异步处理架构提供回调端点,当响应准备好发出请求时可以调用这些端点。

当今异步处理架构中的一个中间人是消息队列,将在下一节中讨论。另一种选择是使用发布/订阅系统,如事件总线。

什么是消息队列?

消息队列是缓冲和分发异步请求的组件。消息是一段数据,可以是 XML 或 JSON 格式,并且包含服务请求的所有必要信息。

客户端称为消息生产者,他们将请求消息发送到消息队列而不是处理服务器。当消息被添加到队列中时,这会得到快速响应,这使他们能够继续进行其他形式的处理,而无需等待服务器。

[](https://res.cloudinary.com/practicaldev/image/fetch/s--Ds2Otr7j--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://dev-to- uploads.s3.amazonaws.com/uploads/articles/upav0itzu90n53ydl4du.png)

服务器被称为消息消费者,并根据它们在任何给定时间可以服务的请求数量从队列中获取消息。这种情况一直持续到队列中的所有消息都已送达为止。

并非所有向您的服务器发出请求的客户端都由您控制。有时,您需要处理来自SaaS应用程序的请求,这些应用程序使用 webhook 与您的服务器通信。这些也被认为是消息生产者。

消息队列可以使用开源技术(如RabbitMQ和Apache Kafka)或使用基础设施即服务(如Hookdeck(稍后将详细介绍))构建到您的基础设施中。

消息队列的好处

以下是通过向基础架构添加消息队列获得的一些即时好处:

• 消息队列支持异步处理,即使您的系统不是为实现异步处理而构建的(与事件总线不同)。

• 包含消息队列有助于生产者处于非阻塞状态(他们的执行线程不需要阻塞),因为他们不必等待消费者可用或完成执行。

• 它使消息生产者和消费者能够以不同的方式扩展,以实现更快的扩展速度。您可以添加更多处理服务器,以确保更快地处理请求,同时仍然享受非阻塞客户端的好处。

• 容错增加:处理服务器可以关闭,客户端的请求仍然会被处理。服务器备份后,消息队列将待处理的请求提供给服务器进行处理。

使用 Hookdeck 将您的 webhook 排队

假设您有一个Shopify商店,并且您需要在购买时向买家发送电子邮件以传达产品交付的详细信息。然后在 Shopify 上配置一个 webhook,以在每次购买要发送的电子邮件时调用您服务器上的端点。

当有很多人购买您的商品时,您很容易遇到服务器因 webhook 请求而过载的情况,如果处理不当,您的服务器将在资源不足时关闭以处理更多请求。这可能导致业务损失并对客户满意度产生负面影响。这就是Hookdeck的用武之地。

Hookdeck 是一种用于 webhook 的基础设施即服务,它允许您从消息队列中受益,而无需编写任何代码。Hookdeck位于您的 webhook 请求和处理服务器之间,用于对您的请求进行排队,并根据您的 API 可以处理的负载将它们提供给您的端点。您将获得高性能的消息队列系统、请求跟踪、请求日志记录、警报、重试、错误处理以及用于搜索和过滤请求的直观仪表板。

Hookdeck只需几个步骤即可设置,无需安装。你所要做的就是:

• 注册用于 Hookdeck 帐户

• 添加您的 webhook 提供商(例如 Shopify、Stripe、GitHub 等)

• 添加您的 API 目标端点

• 将您的 webhook 提供程序的目标端点替换为 Hookdeck 生成的端点

就是这样!最好的部分是您可以立即开始使用免费。

结论

异步处理在您的应用程序中引入了非阻塞请求处理过程,为您提供了一个更加解耦的系统,可以轻松扩展以提高性能。在这篇文章中,我们研究了异步处理的好处以及如何使用消息队列轻松实现它。

为了在您的应用程序中快速轻松地实现异步处理,您可以立即开始使用Hookdeck。