Reactive中有哪些Streams规范

Reactive中有哪些 Streams规范，很多新手对此不是很清楚，为了帮助大家解决这个难题，下面小编将为大家详细讲解，有这方面需求的人可以来学习下，希望你能有所收获。

创新互联凭借在网站建设、网站推广领域领先的技术能力和多年的行业经验，为客户提供超值的营销型网站建设服务，我们始终认为：好的营销型网站就是好的业务员。我们已成功为企业单位、个人等客户提供了成都做网站、成都网站制作、成都外贸网站建设服务，以良好的商业信誉，完善的服务及深厚的技术力量处于同行领先地位。

1）什么是Reactive Streams:

Reactive Streams is an initiative to provide a standard for asynchronous stream processing with non-blocking back pressure. This encompasses efforts aimed at runtime environments (JVM and JavaScript) as well as network protocols.

概括的说，Reactive Streams 是个规范，它规范了“有非阻塞背压机制的异步的流处理”。挺简单的定义，但是能够真正正确理解异步、非阻塞并不容易，以后单独开写一篇。实际上Reactive Streams规范或者说它的第三方代码实现包含的内容更加丰富：除了non-blocking，还有：Composable、Deferred、Flow Controll、Resilient、Interruptible。

其中Composable就是函数式编程思想的用武之地。 可体会下Java8里的Stream API各种算子的参数，所以Lamda表达式是进行Reactive Streams实现的基本前提，否则很难想象臃肿的面向对象的Composable。有了JDK8的铺垫，Reactive Streams接口被JDK9定义在Flow里才是可能的。

As of August 23rd, 2019 we have released version 1.0.3 of Reactive Streams for the JVM, including Java API, a textual Specification, a TCK and implementation examples.

这个规范由三部分组成：Java API（org.reactive-streams）、以文字描述的规范、技术兼容工具包。
Reactive Streams 规范 仅限于 Java（JavaScript、网络协议）世界，其它语言虽然也有 Reactive 这样的工具（参考这里：ReactiveX）实现，但好像没有类似的规范。

2）为什么要有 Reactive Streams

因为很多厂商开发了 reactive 库，但是它们直接很难/不可能互操作。用 Reactive Streams 进行规范就使得它们可以互操作，也就让它们串起来形成一个 reactive 链成为了可能。

3）为什么要用 Reactive

因为 reactive 可以榨干 CPU...，所以从老板的角度讲是省钱、从环保的角度讲是省电、从码农的角度讲是有意思。

4）Java 世界里知名的 Reactive 库

RxJava

从 Reactive 宣言、到 Reactive Streams 规范，再到各种 Reactive 库是很自然的一个脉络。但现实是大家先有了 Reactive 系统的思想，聪明的程序开发出各种蕴含着 reactive 思想的库(比如 RxJava 1.0)。为了各个库之间的统一性、可操作性，大家一起协商出了 Reactive Streams 规范。继而这些已经存在的 reactive 库便改进自己的 API 设计，向 reactive streams 规范靠拢并提供各种转化 api 让用户在原生 api 和 reactive streams 接口直接转换。比如 RxJava 2.0 的 Flowable 就直接继承自 org.reactive-streams.Publisher 并提供了 toObservable() toFlowable()。因为各个库的实现细节不同，用到具体转换 api 需要参考其手册。

RxJava虽然是java ractive编程的领路人，并且RxJava跟Project Reactor 3.0 基本是等价的。但是考虑到Spring生态的强大，估计其前途不会太光明了。

JDK

这个规范被的 API 形式定义从 JDK 9 这个版本开始，以 java.util.concurrent.Flow 静态子类的形式被定义。其实，既然已经有了 org.reactive-streams 这样的规范，为什么还要在 JDK 中弄出个 Flow 来再重新定义一次。难道就是要宣示 JDK 自身有支持 reactive streams 的东西？

这个思路的本意应该就像 JDBC 接口一样，让 Flow 里定义的接口成为 SPI，让不同供应商的 reactive sreams 可互操作吧。所以 JDK 里的 Flow 中定义的东西不能算是库，而是个 SPI：Service Provider Interface。

Vert.x、MongoDB 响应式流驱动

这些都做了改进以符合 org.reactive-streams 中的 API 定义。其中Vert.x不仅提供了对 java 的 reactive 库，还有 JavaScritp、Ruby、Scala 等。

Spring 的 Project Reactor

https://projectreactor.io/docs/core/release/reference/

既然 Spring 都提供了对 Reactive Streams 的实现，感觉其实上面列出的几个库已经没有太多的意义。各家对Reactive Streams规范的实现在细节上都有很大不同，因为Spring 的生态太强大了，如果没有特殊的需求，比如 JDK 小于 8，那么我们的项目基本于 Project Reactor，那么应该是较好的选择。这个网页 https://tech.io/playgrounds/929/reactive-programming-with-reactor-3/Intro 可以帮助操练 Reactor Api。  

Project Reactor 到目前为止经历了 1.0, 2.0, 3.3。其中 1.0 这个阶段还没有 Reactive Stream 是规范。在 2.0 开始 follow 规范并基本定型。3.0 感觉是个重构版，形成 reactive-streams-commons 库。这里是 3.0 的 release 文档: https://github.com/reactor/reactor-core/releases?after=v3.0.0.RELEASE 。

有了 Project Reactor 这样的基础库，整个 Spring 组件基本都有了 Reactive Style 的版本，在这个基础上用 Netty（或 Servet 3.1 Containe）+ Reactive Streams 适配层 + Spring Security Reactive + WebFlux + Spring Data Reactive Repository，就可以构建出重头到尾的 Reactive 应用。

从 Spring Cloud 的组件角度讲，也衍生出 Reactive Discovery Client, Reactive Load Balancer, Blockhound, Reactor Debug, Improved Reactor Micrometer Support, Reactor Netty Metric ...

看完上述内容是否对您有帮助呢？如果还想对相关知识有进一步的了解或阅读更多相关文章，请关注创新互联行业资讯频道，感谢您对创新互联的支持。