Spring Leader分享：Spring Framework之再探Core Container 下

特別說明

這是一個由simviso團隊進行的關於Spring Framework 5.2版本內容分享的視頻翻譯文檔，分享者是Spring Framework 5.2項目leader。方便你們在將來某個時候回顧的時候能夠快速定位內容。

視頻地址：

【國外前沿技術分享-後端-中文字幕】Spring Framework之再探Core Container 上

【國外前沿技術分享-後端-中文字幕】Spring Framework之再探Core Container 中

【國外前沿技術分享-後端-中文字幕】Spring Framework之再探Core Container 下

視頻翻譯文字版權歸 simviso全部，未經受權，請勿轉載：

參與人員名單：

1. 響應式在Spring中的應用

Ok，雖然放在最後但依然比較重要，讓咱們接着討論響應式的話題。今天響應式的話題主要是圍繞你們所知的Spring WebFlux。咱們在Spring Framework 5.2 中引入了響應式Endpoints（請求路徑）的Web Controller模型，這裏跟老一套Controller的典型結構很像。

這裏的@GetMapping註解聲明瞭HTTP Endpoints（請求路徑），以及響應式的返回值（Mono）。在這個特定的例子中，響應式的返回值是Reactor Mono和Reactor Flux類型。同時，返回類型也能夠是Reactive Stream Publisher的任意一種實現，只不過這裏的Mono和Flux是Reactor Project下的對Publisher的一種特殊實現。你也能夠返回RxJava下的Flowable和Single類型，不管你選擇哪一種，咱們都須要知道該對它們進行怎樣的處理。咱們在運行時將它們集成到咱們的Reactive Pipeline中。經過Reactor Core這個項目來對這個過程進行Reactive適配實現，咱們在Spring 5.0中就已經引入了Reactor Core。在接下來的時間裏，我將闡述一些細節以及更深刻的東西。

這些返回響應式返回值的方法，在Spring MVC中一樣可用。Spring WebFlux 是咱們響應式Web棧，在Netty上面運行的EventLoop和Web棧是徹底分離的。但若是咱們討論的是Spring MVC的話，它是一個基於Servlet的Web棧。你一樣能夠響應式的方式返回數據，便可以在這裏返回Reactive Stream Publisher。它們雖然具備一樣的組件模型，可是它們運行時的處理策略是不同的。咱們基本上是將Servlet請求切換到它的異步模式，咱們對Servlet的異步流處理適配了一套Reactive Stream Publisher實現，這裏甚至使用了一點背壓。

隱藏在它們背後的是不同的架構處理，可是它們表達了一個相似的意圖，相似的目的。咱們正盡最大的努力來讓Reactive Stream Publisher能夠應用在Spring MVC Servlet 架構上面。你能夠很好的基於一些需求來進行工做 而這些需求不須要你進行徹底的背壓或徹底的基於EventLoop的處理（Netty中的EventLoop處理）。它是基於一個DeferredResult來替代實現。

Spring MVC距離擁有這樣功能的一個DeferredResult還有很長時間，這個就像擁有對Reactive Stream Publisher這樣的返回值類型進行處理能力的DeferredResult。若是你在WebFlux上進行同種類型的請求處理，它們實際上經過基於EventLoop的架構全程進行響應式處理。今後處能夠看出，在WebFlux上對於請求路徑的處理（Endpoints）是有點不同的。在Spring MVC中你能夠將常規標準的阻塞式同步Endpoints（圖中路徑對應的處理方法）與Reactive Streams Publisher這種返回類型混合使用。想要作到這點真的還有很長的路要走。

2. 響應式事務處理

和剛纔所講的這些事情同樣，大部分的Spring功能均可以經過一些有趣的途徑將它們整合到一塊兒。對於響應式功能來說，一樣如此。一個很明顯的例子就是Spring Framework 5.2中的響應式事務處理。咱們拿圖中這個Service class中的@Transactional方法來說。在方法上聲明@Transactional註解，同時返回一個Reactive Streams Publisher。當咱們進行事務攔截的時候會說，這不是一個常規的事務方法常規的事務方法是在同一個線程上咱們在調用方法時開啓事務，在方法返回的時候對事務進行 commit 或 rollback。

這是一個不同的method，它須要經過一個指令級流式編程的風格返回一個Reactive Streams Publisher。你每每須要在裏面經過一系列方法創建管道式的鏈式調用。在這裏，它調用了一個Repositiory的指令，多是一個Spring Data Repositiory，也多是自定義的，這裏並無什麼區別。它調用一個用於返回一個Mono或者Flux的repository。因此咱們僅僅經過該repository 就能夠獲得想要的。

固然你能夠在這裏經過響應式鏈式操做來作任何事。若是你須要，你能夠對元素進行後置處理，此時事務會很智能的切換到一種不同的操做模式下，在這個事務操做背後，會有一個承載響應式鏈式執行事務信息的context 在操做調用之初就已經默默在背後運行了（譯者注：底層是基於Spring Reactor的Context實現的）。這個repository操做在執行時會檢測事務的context，而後在事務上下文中工做。在響應式鏈式操做執行完畢後跳出事務操做。可是要注意的一點，事務會在會在EventLoop中觸發。這裏，事務並非在調用該方法獲得返回值時執行，而是在 pipeline（響應式鏈式）實際執行時，咱們才選擇是提交仍是回滾（譯者注：Context是基於訂閱者的，只有發生訂閱，纔會有Context產生）。顯而易見，Repository 實現須要有感知Transaction Context的特性，那就須要Repository 有專門的事務實現支持。

並且和標準的事務同樣，你也須要有一個這樣的Repository（好比基於JPA的實現，基於Hibernate的實現，基於JDBC的實現）能夠很好的和事務一塊兒使用，只不過限制有點多。咱們目前支持基於R2DBC的Repositories，它是咱們響應式關係型數據庫鏈接的抽象實現。

R2DBC是Pivotal贊助的一個獨立項目，同時咱們整合了大多數常見數據庫的驅動實現，包括MongoDB。當發生數據存儲的時候咱們有一個事務上下文模型，固然咱們也支持索引排列，這就是咱們在Spring Framework 5.2 中實現響應式事務支持所選擇的方式。

關於事務背後的機制就到這裏，咱們也明確的說起了R2DBC和MongoDB，它們背後的實現也不同。它們是不一樣的SPI。若是你對整合這種響應式處理比較感興趣，好比一些響應式的數據存儲API。基於此你的主要精力應該放在ReactiveTransactionManager SPI上。 這是一個很不同的SPI。固然，也是由於這裏它並不基於Threadlocal工做。它們在Spring MVC和Spring WebFlux中惟一有點像的地方在於它們都使用同樣的註解。這是兩種SPI，PlatformTransactionManager 是標準的基於Threadlocal綁定的事務處理機制。ReactiveTransactionManager則是基於響應式鏈式操做綁定的事務機制，使用了同樣的註解配置來安裝。

3. Reactive Messaging與RSocket

另一個值得一提的話題就是在Spring 5.2中才有的Reactive Messaging。Reactive Messaging使用起來很是簡單。若是你有WebFlux的使用經驗的話，這裏它就和使用Endpoints是同樣的，可是須要集成Spring Messaging模塊。這樣就能夠經過上面的@MessageMapping註解並返回Reactive Stream Publisher來作到對Reactive Messaging的使用。關於這個消息集成模塊，固然它能夠和JMS同樣，能夠基於同步。在你使用這個消息技術時，你真正依賴的是底層的消息架構，咱們這裏主要是基於RSocket這個響應式流處理模型。

RSocket也是一個行業合做所誕生的產物，不只僅是由Netifi（Rscoket公司）來爲Rscoket提供基礎開發（譯者注：Spring旗下的Reactor-Netty是它的核心基礎庫）。因此RSocket是一個比較有趣的通訊模型，它能夠經過響應式Endpoints（譯者注：將請求路徑和對應的處理類一塊兒封裝的一個類），來直接映射到RSocket的基礎設施API，這是咱們爲何推薦使用它。咱們打算自上而下進行響應式的支持。拿數據存儲來說，你可使用支持響應式的Repository來進行數據存儲操做。咱們想將響應式操做貫穿整個Spring操做棧，包括messaging endpoints 和web endpoints。這也是咱們的主要目標，對於此處的消息傳遞一樣如此。整個過程基於一個像Rsocket同樣的消息架構進行，即關於消息綁定和驅動都是基於響應式流的能力。而後你能夠直接經過Spring 5.2 中的messaging endpoint來進行使用。

4. Reactive Application Event

在響應式介紹的最後，除了常見的針對請求的響應式編程處理，還有一個很棒的地方就是關於Application Events。關於ApplicationEvent這個基礎類在Spring中已經存在好久了。傳統的，事件監聽器在不少狀況下都是同步執行的，並不會阻塞操做。可是若是對ApplicationEventMulticaster進行線程池配置（調用setTaskExecutor設置），那就有可能在調用時產生阻塞。有不少事情依然能夠經過ApplicationEvent來作到，可是有一件事作不到。就是對那些以返回值響應式類型的eventlistener方法實現的處理（看圖中的@EventListener註解方法）。那咱們能夠這樣說，這裏有一個事件，對應這個事件會有一個響應式的鏈式調用管道，你應該將它們集成到你的事件廣播中，這也是咱們在Spring 5.2中正努力作到的事情。它尚未徹底可用，即你可使用一個Mono類型或CompletableFuture類型的返回值來表達說。我是一個EventListener，我能夠作到異步或響應式鏈式執行。當Multicaster看到這個事件信號時，就會根據條件判斷選擇這個最合適的EventListener對事件進行處理。因此關於Application Events這塊兒實際上是Spring整個響應式迭代過程當中的最後一塊拼圖。主要也是因爲它在架構中常常用到，那若是使用響應式開發的話也不會例外。

你能夠看到，我前面提到的這些代碼（如Mono、Flux）都是基於Spring Reactor 的API。你也可使用Rxjava的Single和Flowable API。在不少狀況下，你也能夠用CompletableFuture，但沒有背壓支持，就是一個單個元素，可是它也能夠被適配轉換到響應式鏈式處理中，並運行在Netty的一個eventloop中。咱們底層有一套能夠將它自動轉換爲響應式API類型的實現。並且這套實現已經存在好久了，能夠很好的處理RxJava 和JDK 9 下的java.util.concurrent.Flow API類型或其餘響應式publisher實現。

咱們即將在Spring 5.2中加入全新的Kotlin協程支持，也是基於響應式API來適配的。在Kotlin中，協程是Kotlin語言的基本功能，做爲一種可掛起的方法。與之伴隨的是Kotlin的底層API —— CoroutineContext。CoroutineContext實際上很是接近響應式模型。咱們在Spring Framework 5.2中將CoroutineContext直接適配到咱們的響應式架構中。所以，你也能夠選擇基於Reactor或響應式的API來使用Kotlin的協程。同時咱們自動的將它們適配到咱們的響應式請求路徑處理（Endpoint）中，底層作了一些API適配和一些Kotlin擴展。在Spring Framework 5.2版本中咱們將加入Kotlin協程支持。

so，我基本上已經講完了我想說的。談到這裏，我但願前面的內容多少能引發你的興趣。這也是咱們去年談過的一些內容，咱們在響應式架構上作了不少的改進。依靠Java 8 API進行更全面更普遍的改進，使用了Java 8語言的特性，並對註解處理進行了徹底從新實現。特別是在性能調優、啓動性能調優、熱點性能調優等方面，經過這些改進容許咱們爲你提供一個更好的性能體驗。基本上Spring Framework 5.2 RC1版本會在七月份出來。GA版本計劃在九月上旬發佈，在此以後會發布SpringBoot 2.2的新版本。OK，這就是我今天想要帶給大家的。感謝各位的參與，若是各位有任何疑問，在演講結束後我很樂意爲各位解答。再次感謝並但願大家能享受接下來的show。

更多請關注咱們的公衆號：