翻譯自：https://tech.io/playgrounds/929/reactive-programming-with-reactor-3/BlockingToReactive
Blocking to Reactive
Description
The big question is "How to deal with legacy, non reactive code?".
最大的問題是“如何處理遺留的、非反應性的代碼？”。
Say you have blocking code (eg. a JDBC connection to a database), and you
want to integrate that into your reactive pipelines while avoiding too much
of an impact on performance.
假設您有阻塞代碼（例如，到數據庫的JDBC連接），您希望將其集成到反應式管道中，同時避免對性能造成太多影響。
The best course of action is to isolate such intrinsically blocking parts
of your code into their own execution context via a Scheduler, keeping
the efficiency of the rest of the pipeline high and only creating extra
threads when absolutely needed.
最好的做法是通過調度器將代碼中這些固有的阻塞部分隔離到它們自己的執行上下文中，
從而保持管道其余部分的高效率，并且僅在絕對需要時創建額外的線程。
In the JDBC example you could use the fromIterable factory method.
But how do you prevent the call to block the rest of the pipeline?
在JDBC示例中，可以使用fromIterable工廠方法。但是，如何防止調用阻塞管道的其余部分呢？
Practice
The subscribeOn method allow to isolate a sequence from the start on a
provided Scheduler. For example, the Schedulers.boundedElastic() will
create a pool of threads that grows on demand, releasing threads that
haven't been used in a while automatically. In order to avoid too many
threads due to abusing of this easy option, the boundedElastic Scheduler
places an upper limit to the number of threads it can create and reuse
(unlike the now deprecated elastic() one).
subscribeOn方法允許在提供的Scheduler上從開始隔離序列。例如，Schedulers.boundedElastic()
將創建一個按需增長的線程池，自動釋放一段時間未使用的線程。為了避免由于濫用此easy選項而導致過多線程，
boundedElastic調度程序對其可以創建和重用的線程數設定了上限（與現在已棄用的elastic()不同）。
Use that trick to slowly read all users from the blocking repository
in the first exercise. Note that you will need to wrap the call to the
repository inside a Flux.defer lambda.
在第一個練習中，使用該技巧慢慢讀取阻塞repository中的所有用戶。
注意，您需要將對repository的調用封裝在Flux.defer lambda中。
// Create a Flux for reading all users from the blocking repository deferred until the flux is subscribed, and run it with a bounded elastic scheduler
Flux<User> blockingRepositoryToFlux(BlockingRepository<User> repository) {
return Flux.defer(() -> Flux.fromIterable(repository.findAll()).subscribeOn(Schedulers.boundedElastic()));
}
For slow subscribers (eg. saving to a database), you can isolate a smaller
section of the sequence with the publishOn operator. Unlike subscribeOn,
it only affects the part of the chain below it, switching it to a new Scheduler.
對于速度較慢的訂閱者（例如保存到數據庫），可以使用publishOn運算符隔離序列的較小部分。
與subscribeOn不同，它只影響其下方鏈的一部分，將其切換到新的Scheduler。
As an example, you can use doOnNext to perform a save on the repository,
but first use the trick above to isolate that save into its own execution
context. You can make it more explicit that you're only interested in knowing
if the save succeeded or failed by chaining the then() operator at the end,
which returns a Mono<Void>.
例如，您可以使用doOnNext在repository上執行保存，但首先使用上述技巧將該保存隔離到其自己的
執行上下文中。通過在末尾鏈接then()運算符，您可以更明確地知道保存是成功還是失敗，這將返回一個Mono<Void>。
// Insert users contained in the Flux parameter in the blocking repository using a bounded elastic scheduler and return a Mono<Void> that signal the end of the operation
Mono<Void> fluxToBlockingRepository(Flux<User> flux, BlockingRepository<User> repository) {
return flux.publishOn(Schedulers.boundedElastic()).doOnNext(repository::save).then();
}
