近年来,反应式编程已经越来越多地扩展,它已经被多种语言所解决,但是在Java中,它对您来说是新事物吗? 然后,这一系列文章适合您!
在本系列文章中,我将讨论诸如反应式编程,Spring Webflux,Project Reactor和Netty之类的问题。
在本文的第一部分中,我将介绍一些一般概念,然后深入研究每个概念,然后开始:
The Problem:
我们希望我们的应用程序具有可扩展性,我们需要越来越高效地使用资源,延迟时间必须最短,我们需要对请求的快速响应,我们需要处理竞争的请求(每个线程消耗一点内存),传统的API在 同步和阻塞方式。
为了解决这个问题,我们创建了回调和期货:
回调不易阅读且难以维护,它们很复杂(它们可以构成地狱回调),因此无法返回任何值。
Future:返回future类型的实例,并且很难扩展多个异步操作,作为替代方案,Java 8推出了Completable Future,它支持使用多个异步操作进行功能性且易于编程的编程,但是,没有完美的选择 ,对于具有多个项目的异步调用不是一个好的选择。
Alternative way to develop APIs
- 异步和非阻塞
- 外部按需线程模型
- 减少创建的线程数
反应式编程就可以了,但是有什么不同呢?
- 异步和非阻塞
- 数据流作为事件/消息驱动流
- 代码保持功能性的编程风格。
- 数据流中的BackPressure
让我们更加关注数据流部分:
数据可以来自数据库,外部文件,集成服务,其他应用程序等。对于此数据源的每个项目,我们都有一个事件或消息被触发,在执行该事件/消息后,我们会显示一条错误消息 还是说它已经完成了。
例如,对于保存数据的请求,我们有一个onNext(Product)事件:
List <Product> products= productRepository.getAllProducts();
例如,当我们从数据库中调用数据时,该调用返回,并为每个项目启动一个onNext(Product),并且当我们完成清单时,我们有一个onComplete()事件来通知我们请求已结束。
如果我们的请求有错误怎么办?
而不是返回onComplete()事件,我们将拥有OnError()事件,而我们将不会获得预期的内容。
Reactive Stream Specification
是由Pivotal和Netflix等公司创建的一组流使用规范,在这些规范中,我们有:
- 发行人: Publisher接口是按顺序方式提供无限数量的元素的提供程序,并根据其从订阅服务器收到的需求进行发布(我将解释下一步)。 同一发布者可以在不同时间动态为多个订阅者提供服务。 出版商是我们的数据来源。
public interface Publisher<T>{
public void subscribe (Subscriber<? super T> s);
}
- 订户: 您将订阅服务器的实例传递给Publisher.subscribe(订阅者)后,您才收到对OnSubscribe的调用。 在调用Subscription.request(长整数)之前,不会收到任何通知。 发起呼叫后: 将启动一个或多个onNext(Object)调用,直到达到Subscription.request(long)定义的最大数目。 单个onError(Throwable)错误调用或完整的onComplete()请求。 每当Subscriber实例可以处理更多请求时,可以通过Subscription.request(long)发出此需求信号。
public interface Subscriber<T>{
公共无效onSubscribe(Subscription s);
公共无效onNext(T t);
公共无效onError(Throwable t);
public void onComplete();
}
和订阅:
公共接口订阅{
公共无效请求(长n);
public void cancel();
}
- 处理器: 它代表一个处理步骤,既是接受这两个标准的订阅者又是发布者。
public interface Processor <T,R> extends Subscriber <T>,Publisher <R>{
}
就是这样:
通知订户的元素的T型。
通知发布者的元素的R类型。
这是系列文章的第一部分,其中我们讨论了反应式编程的一些要点和优点,接下来,我将介绍一些反应式库。
有疑问或反馈吗?
以下是与此主题相关的一些有趣参考和内容:
图片来自: https://docs.spring.io/spring-framework/docs/5.0.0.M1/spring-framework-reference/html/images/web-reactive-overview.png
下篇文章见!