响应式流的生命周期
这里所说的响应式流的生命周期是说我们从定义响应式流到触发这个流的处理所经历的不同阶段。
总的来说，就是三个阶段。组装时、订阅时、运行时。
组装时
这个阶段就是我们建立处理模型的阶段。基本上是解决了下面 3 个方面的问题。
1）定义这个 reactive stream 的数据来源是什么。Publisher
这个阶段我们通过使用诸如 just(), range(), fromArray(), push(), create(), generate()等方法来设置数据源头。
2）这个数据流的最终订阅者是谁？Subscriber
我们在最下游 publisher 上通过调用 subscribe()方法把 subscriber 从下游到上游依次传递到最上游的包含数据源的 publisher。
3）数据到达最终订阅者那里时需要做哪些转换、处理？ Operator
以上两个调用解决了数据来源于哪里、被谁最终接收的问题。但是在数据从上游被传递到下游的过程中，我们往往需要对数据做各种处理。这个阶段就各种 operator 大显身手的地方，比如 map(), flatMap(), filter(), reduce(), scan(), concatMap(), usingWhen()… …
实际上每经历一个 operator，就生成了一个新的中间级别的 publisher，这就是 reactive stream 的不可变性。
组装时基本就是我们写出的代码定义出的静态逻辑这部分。
程序运行起来，才会进入下面的两个阶段：订阅时、运行时，所以说这两个阶段是程序的动态表现。
订阅时
通过组装时我们定义了什么数据(publisher)经过怎样的处理(operator)最后传递给谁(subscriber)。而订阅时这个阶段，解决的问题是把调用下游 publisher 时传入的 subscriber 依次传递给上游的的 publisher。可以想象 Project Reactor 在传递 subscriber 的时候是依次进行封装之后传递的而不会是直接把下游的 subscriber 传递上去，因为以 operator 串联起来的各个 publisher 都需要“自己”的 subscriber。可以体会下这里“Subscriber 链”的概念。
这个传递过程很重要，因为 subscriber 中的 onSubscribe(Subscription s)提供了上游 publisher 把 Subscription 传递给下游 Subscriber 的机制。
因为 Subscriber 只有通过 subsciption 的 request 方法才能启动数据的流动。
运行时
经过组装时、订阅时，数据流已经“一触即发”。我们只有通过上游传递给我们的 Subscription 调用 request()方法就可以触发数据的流动了。
通过（在 Subscirberd 的 onSubscription(), onNext()被回调时）向 Subscription 的 request()传入不同的数字，我们分别可以实现拉模型、推模型、拉-推模型。
响应式流的运行时所强调的就是这种 Publisher 和 Subscriber 之间的信号交换。