使用Spring WebFlux构建反应性REST API –第1部分

在本文中，我们将看到如何使用Spring WebFlux构建响应式REST API。 在进入反应式API之前，让我们看看系统是如何发展的，传统REST实现遇到的问题以及现代API的需求。

如果您查看从旧版系统到下文所述的现代系统的期望，

现代系统的期望是，应用程序应该是分布式的，云原生的，拥抱高可用性和可伸缩性。 因此，有效利用系统资源至关重要。 进入为什么要使用响应式编程来构建REST API？ 让我们看看传统的REST API请求处理是如何工作的。

以下是传统REST API遇到的问题，

• 阻止和同步→请求正在阻止和同步。 请求线程将等待任何阻塞的I / O，并且直到I / O等待结束后，线程才可以释放以将响应返回给调用方。
• 每个请求的线程 → Web容器使用每个请求模型的线程。 这限制了要处理的并发请求的数量。 除了某些请求之外，容器还会对请求进行排队，这些请求最终会影响API的性能。
• 处理高并发用户的限制 →由于Web容器按请求模型使用线程，因此我们无法处理高并发请求。
• 无法更好地利用系统资源 →线程将因I / O而阻塞并处于空闲状态。 但是，Web容器不能接受更多请求。 在这种情况下，我们将无法有效地利用系统资源。
• 没有反压支持→我们无法从客户端或服务器施加反压。 如果请求突然激增，则可能导致服务器或客户端中断。 之后，用户将无法访问该应用程序。 如果我们有背压支持，则应用程序应在重负载期间持续运行，而不是无法使用。

让我们看看如何使用反应式编程解决上述问题。 以下是我们使用反应式API所获得的优势。

• 异步和非阻塞→反应式编程为编写异步和非阻塞应用程序提供了灵活性。
• 驱动事件/消息 →系统将为任何活动生成事件或消息。 例如，来自数据库的数据被视为事件流。
• 支持背压 →我们可以通过施加背压来优雅地处理从一个系统到另一个系统的压力，从而避免拒绝服务。
• 可预测的应用程序响应时间→由于线程是异步且非阻塞的，因此在负载下应用程序响应时间是可预测的。
• 更好地利用系统资源 →由于线程是异步且非阻塞的，因此不会为I / O 占用线程。 使用更少的线程，我们可以支持更多的用户请求。
• 根据负载缩放
• 远离每个请求的线程 →借助反应式API，我们正在远离每个请求的线程模型，因为线程是异步且非阻塞的。 发出请求后，它将与服务器一起创建事件，并且请求线程将被释放以处理其他请求。

现在让我们看看反应式编程是如何工作的。 在下面的示例中，一旦应用程序调用了从数据源获取数据的操作，线程将立即返回，并且来自数据源的数据将作为数据/事件流出现。 在这里，应用程序是订阅者，数据源是发布者。 数据流完成后，将触发onComplete事件。

下面是另一种情况，如果发生任何异常，发布者将触发onError事件。

在某些情况下，可能没有任何要从发布者交付的项目。 例如，从数据库中删除一个项目。 在这种情况下，发布者将立即触发onComplete / onError事件，而无需调用onNext事件，因为没有数据可返回。

现在，让我们看看什么是背压？ 以及我们如何对反应流施加背压？ 例如，我们有一个客户端应用程序正在从另一个服务请求数据。 该服务能够以1000TPS的速率发布事件，但是客户端应用程序能够以200TPS的速率处理事件。 在这种情况下，客户端应用程序应缓冲其余数据以进行处理。 在随后的调用中，客户端应用程序可能会缓冲更多数据，并最终耗尽内存。 这会对依赖于客户端应用程序的其他应用程序造成级联效应。 为了避免这种情况，客户端应用程序可以要求服务在事件末尾缓冲事件，并以客户端应用程序的速率推送事件。 这称为背压。 下图描述了相同的内容。

在接下来的文章中，我们将看到反应式流规范及其实现Project Reactor之一，其中包含一些示例应用程序。 到那时， 快乐学习！！

翻译自: https://www.javacodegeeks.com/2020/05/build-reactive-rest-apis-with-spring-webflux-part1.html