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）实现，但好像没有类似的规范。
因为很多厂商开发了 reactive 库，但是它们直接很难/不可能互操作。用 Reactive Streams 进行规范就使得它们可以互操作，也就让它们串起来形成一个 reactive 链成为了可能。
因为 reactive 可以榨干 CPU...，所以从老板的角度讲是省钱、从环保的角度讲是省电、从码农的角度讲是有意思。
从 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生态的强大，估计其前途不会太光明了。
这个规范被的 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。
这些都做了改进以符合 org.reactive-streams 中的 API 定义。其中Vert.x不仅提供了对 java 的 reactive 库，还有 JavaScritp、Ruby、Scala 等。
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 ...
看完上述内容是否对您有帮助呢？如果还想对相关知识有进一步的了解或阅读更多相关文章，请关注创新互联行业资讯频道，感谢您对创新互联的支持。
