領先一步
VMware 提供培訓和認證,助您加速進步。
瞭解更多Reactor 團隊很高興地宣佈釋出 2.0.0.RC1 版本,現已在 spring.io Maven 倉庫以及 Maven Central 中提供。2.0 版本是 Reactor 1.1 的 #uberupdate,包含了幾個新元件以及對 Stream 等重要類的完全重寫,現在它實現了 Reactive Streams 標準。
請注意,Reactor 2.0 的 Maven 座標已從 Reactor 1.x 的座標更改。新的座標都屬於組 ID io.projectreactor,而不是之前的 org.projectreactor。Gradle 專案的示例依賴塊可能如下所示
ext {
reactorVersion = '2.0.0.RC1'
}
repositories {
maven { url 'http://repo.spring.io/libs-milestone' }
mavenCentral()
}
compile "io.projectreactor:reactor-core:$reactorVersion",
"io.projectreactor:reactor-net:$reactorVersion",
"io.projectreactor.spring:reactor-spring-context:$reactorVersion"
如果您是 Reactor 的完全新手,您可能需要先跳轉到炫酷的新網站 http://projectreactor.io 瞭解一下,這樣才能理解其中的一些內容。
除了 2.0.0.M1 版本中宣佈的更改,以下是相對於 1.1 版本的一些重要更改的簡要列表
Stream 已重寫以實現 Reactive Streams 標準,速度提高了 5-10 倍,並且開銷比以前的版本少得多。Stream 的新簽名和 Reactor 重新命名為 EventBus。有關此轉換的文件正在進行中。Stream API 源自 Reactive Extensions,並借鑑了其許多命名約定。透過利用通用詞彙和行為,可以輕鬆地將 Rx.NET 和 RxJava 示例轉換為 Reactor。Stream 整合、DSL 輔助方法。如果必須將討論限制在一個更改上,那麼就是對 Reactive Streams 的原生和基礎支援。很難誇大 Reactive Streams 對 Reactor 的重要性。流處理是 新 黑科技,Reactor 從專案開始就接受了這一點。然而,Reactive Streams 的加入及其對背壓傳播的支援,使您的雲應用程式更容易在即時或接近即時處理大量資料。現在,諸如負載下的 stop-read、batch flush 或 adaptive batch 等模式已開箱即用。
Reactor Stream 中的每個步驟都是一個 Reactive Streams 元件,它根據當前資源限制下的處理速率正確傳播需求和背壓。使用 Reactive Streams,Reactor 2.0 可以建立一個自動調整其資源使用的處理流。由於 Reactive Streams 背壓向上遊通訊的方式,您可以影響將新專案拉入系統的速率。這意味著緩慢的下游元件可以將壓力一直推回源頭,以降低攝取速率,如果當前處理正在使用所有可用資源。
Pool<Connection> pool;
Stream<Message> input;
input.capacity(1)
.batchConsume(msg -> {
pool.getConnection().merge(msg);
}, requestMore -> Math.max(pool.getSize() - pool.getActive(), 1));
在上面的程式碼片段中,我們根據池中可用連線的數量調整要處理的專案數量。作為 batchConsume 方法的第一個引數傳遞的 Consumer 將根據作為第二個引數傳遞的 Function 返回的 requestMore 值呼叫。在這種情況下,我們將預取與池中空閒連線數量相等的郵件數量,如果所有連線都處於活動狀態,則只預取單個郵件(在這種情況下,我們將依賴於連線池的背壓)。
如果我們要確保我們的流不會佔用資源,我們還可以將容量演算法更改為返回小於可用連線數量的數字,這將為應用程式中的其他元件留下一些可用連線。
從 Reactor 2.0.0.RC1 開始,可以透過簡單地排除 gs-collections 庫將 Reactor 包含在您的 Android 應用程式中,否則由於其大小,您將不得不經歷一些麻煩。我們為 EventBus 實現了一個不使用 gs-collections 的 SimpleCachingRegistry。未來的改進可能包括一個專用的 UI 事件迴圈 Dispatcher,以確保您的事件處理程式在正確的執行緒上執行。
我們非常感興趣地看到 Reactor 如何促進 Android 裝置上的響應式應用程式,以及這如何與 Reactor 在伺服器端極高的吞吐量、低延遲能力相關聯。如果您正在 Android 上使用 Reactor,並且我們可以做些什麼來改善這種體驗,請告訴我們。
RC1 引入了基於 Reactor 使用 Netty 4 的 HTTP 新支援。它尚未全面,但它提供了一些輔助方法和一些有用的抽象,用於構建(和訪問)非阻塞的基於 REST 的微服務和納服務。我目前不會嘗試用它來構建生產服務,因為在正式釋出之前還需要進行一些完善。您可以使用 Reactor 嵌入微服務,而無需直接使用 Netty API。
以下內容建立一個基於 Netty 的嵌入式 HTTP 伺服器,該伺服器具有路徑引數,可將任務分派到共享的 RingBufferDispatcher。
HttpServer<String, String> server = NetStreams.httpServer(
spec -> spec.listen(3000)
.codec(StandardCodecs.STRING_CODEC)
.dispatcher(Environment.sharedDispatcher())
);
server.get("/echo/{greeting}", ch -> {
String greeting = ch.param("greeting") + " World!";
ch.transfer(Transfer.NON_CHUNKED)
.responseHeader("Content-Length", "" + greeting.length())
.log("server");
return Streams.just(greeting);
});
server.start();
我們還更新了 TCP 和 ZeroMQ 支援,以更好地利用我們對 Stream 所做的重要更改。最重要的是,TCP 伺服器和客戶端利用 Reactive Streams 背壓支援來實現“停止讀取”等模式,以防止伺服器在有可用資源處理之前從客戶端讀取過多資料而導致下游處理溢位。
在釋出 Reactor 2.0 GA 之前,我們將至少再發佈一個 RC 版本。在確保其可預測性令人滿意之前,我們還需要對複雜的 fork/join 排程進行一些調整。由於這只是第一版,可能會對 HTTP 支援進行一些補充。我們可能還會發現一些邊緣情況下的錯誤。
我們對這個候選版本感覺很好,我們鼓勵您試用它。如果您正在進行新開發,那麼我們強烈建議您在 Reactor 2.0 的 Reactive Streams 基礎上構建,而不是使用功能較弱的、Reactive Streams 之前的 1.1 版本。如果您正在升級現有的 Reactor 程式碼,升級路徑實際上非常簡單。在幾乎所有情況下,您的程式碼都將大大簡化。
如果您在升級程式碼時遇到問題,或者對如何使用 Reactor 解決您的快速資料問題有一般性疑問,請隨時在 Reactor Framework Google Group 上提問。
我們也歡迎透過 GitHub 上的拉取請求進行社群貢獻。
您可能還會感興趣的是,Reactive Streams 專案正在考慮以新的 java.util.concurrent.Flow 類和適當的內部類的形式包含在 JDK 9 中。關於此主題的討論正在 JSR-166 concurrency-interest 郵件列表中進行,該列表由紐約州立大學奧斯威戈分校的 Doug Lea 教授管理。
Reactor 採用 Apache 2.0 許可證,專案透過 GitHub 管理