白城网站开发,宁波网络营销咨询,金融app开发,58招商加盟项目在本文中#xff0c;我们将看到如何使用Spring WebFlux构建响应式REST API。 在进入反应式API之前#xff0c;让我们看看系统是如何发展的#xff0c;传统REST实现遇到的问题以及现代API的需求。 如果您查看从旧版系统到下文所述的现代系统的期望#xff0c; 现代系统的期… 在本文中我们将看到如何使用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
