1.5　Spring 5與響應式編程

無論是電商類系統，還是互聯網場景下的智能終端平臺，都面臨著大流量、高并發的訪問請求。在各種請求壓力下，系統就可能出現一系列可用性問題，作為系統的設計者，需要保證系統擁有即時的響應性。如何時刻確保系統具有應對請求壓力的彈性，成為一個非常現實且棘手的問題。響應式編程技術針對這類問題提供了一種新的解決方案。

1.5.1　響應式編程技術

經典的服務隔離、限流、降級以及熔斷等機制能夠在一定程度上實現系統的彈性。通過對比更多可選的技術體系之后，可發現構建系統彈性的一種嶄新的解決方案，這就是響應式編程。響應式編程打破了傳統的同步阻塞式編程模型，基于響應式數據流和背壓機制實現了異步非阻塞式的網絡通信、數據訪問和事件驅動架構，能夠緩解服務器資源的競爭，從而提高服務的響應能力。

比方說，當系統中的服務A需要訪問服務B時，在服務A發出請求之后，執行線程會等待服務B的返回，這段時間該線程就是阻塞的，因此整個過程的CPU利用效率低下，很多時間線程被浪費在了I/O阻塞上。更進一步，當執行數據訪問時，數據庫的執行操作也面臨著同樣的阻塞式問題。這樣，整個請求鏈路的各個環節都會導致資源的浪費，從而降低系統的彈性。而通過引入響應式編程技術，就可以很好地解決這種類型的問題。

事實上，很多開發框架中已經應用了響應式編程技術。在1.4節中提到的Spring Cloud中存在的Netflix Hystrix組件，就是專門用來實現服務限流的熔斷器組件。在這個組件中，實現了一個HealthCountsStream類來提供滑動窗口機制，從而完成對運行時請求數據的動態收集和處理。Hystrix在實現這一機制時大量采用了數據流處理方面的技術以及RxJava響應式編程框架。

再比方說，針對Spring Cloud，Spring家族還專門開發了一個網關工具Spring Cloud Gateway。相比Netflix中提供的基于同步阻塞式模型的Zuul網關，Spring Cloud Gateway的性能得到了顯著的提升，因為它采用了異步非阻塞式的實現機制，而這一機制正是借助于響應式編程框架Project Reactor以及Spring 5中所內嵌的相關開發技術實現的。

1.5.2　響應式Spring中的技術組件

你可能會問，如何應用響應式編程技術呢？它的開發過程是不是很有難度呢？這點不用擔心，因為隨著Spring 5的正式發布，我們迎來了響應式編程的全新發展時期。Spring 5中內嵌了與數據管理相關的響應式數據訪問、與系統集成相關的響應式消息通信以及與Web服務相關的響應式Web框架等多種響應式組件，從而極大簡化了響應式應用程序的開發過程和降低了相應的開發難度。圖1-11展示了響應式編程技術棧與傳統的Servlet技術棧之間的對比。

圖1-11　響應式編程技術棧與傳統的Servlet技術棧之間的對比（來自Spring官網）

可以看到，圖1-11左側為基于Spring WebFlux的技術棧，右側為基于Spring MVC的技術棧。我們知道傳統的Spring MVC構建在Java EE的Servlet標準之上，該標準本身就是阻塞式和同步的。而Spring WebFlux基于響應式流，因此可以用來構建異步非阻塞的服務。

在Spring 5中，選取了Project Reactor作為響應式流的實現庫。由于響應式編程的特性，Spring WebFlux和Reactor的運行需要依賴于諸如Netty和Undertow等支持異步機制的容器。也可以選擇使用較新版本的Tomcat和Jetty作為運行環境，因為它們支持異步I/O的Servlet 3.1。圖1-12更加明顯地展示了Spring MVC和Spring WebFlux的區別和聯系。

在基于Spring Boot以及Spring Cloud的應用程序中，Spring WebFlux和Spring MVC可以混合進行使用。

另一方面，針對數據訪問，從Spring Boot 2開始，對于那些支持響應式訪問的數據庫，Spring Data也提供了響應式版本的Repository支持。我們可以使用MongoDB和Redis等NoSQL數據庫來實現響應式數據訪問。

圖1-12　Spring MVC和Spring WebFlux的區別和聯系