Trong phần 1, chúng ta đã tìm hiểu về một số khái niệm trong lập trình reactive. Bây giờ, ở phần 2, chúng ta sẽ hiểu lý do Webflux được tạo ra và cách kiến trúc của nó hoạt động như thế nào.
Spring WebFlux là gì?
Spring WebFlux có thể được định nghĩa là một phiên bản “song song” với Spring MVC đã biết đến rộng rãi, với sự khác biệt chính là hỗ trợ các luồng Reactive NIO và hỗ trợ khái niệm backpressure với máy chủ Netty được tích hợp sẵn trong kiến trúc của nó.
Từ phiên bản 5.0 của Spring Framework, chúng ta có phần reactive được thêm vào cấu trúc Servlet đã tồn tại, mỗi module này đều là tùy chọn, bạn có thể sử dụng phần Servlet hoặc phần reactive hoặc thậm chí cả hai trong ứng dụng của mình.
Webflux nằm trong “phần reactive” của stack,
- Netty / Undertow thay thế servlet làm máy chủ.
- Không sử dụng API Servlet (blocking) mà sử dụng Reactive Streams
- Sử dụng router thay vì @Controller.
Điều quan trọng cần lưu ý là chúng ta có thể sử dụng một hoặc cả hai kiến trúc, tận dụng những điểm tốt nhất của cả hai.
Spring Webflux được phát triển nhằm đáp ứng nhu cầu cho các ứng dụngnon-blocking, có khả năng hoạt động với số lượng luồng nhỏ và tài nguyên phần cứng hạn chế.
Trong Servlet 3.1 có API NIO, nhưng không phù hợp với các API và khái niệm đồng bộ như getPart và getParameter.
WebFlux giúp dễ dàng hơn trong việc hiểu và sử dụng lập trình functional/reactive. Với các tính năng từ Java 8 (như lambda expressions, streams, Optional …), Spring WebFlux có các functional endpoint và annotated controllers trong các ứng dụng.
Hoạt động như thế nào?
Trong mô hình MVC, yêu cầu hoạt động như sau:
Client gửi yêu cầu, được TomCat nhận và điều khiển bởi thread pool, rồi được chuyển đến Dispatcher Servlet để điều phối yêu cầu đến endpoint tương ứng trong RequestMapping, sau đó được nhận tại Controller để xử lý dịch vụ và cuối cùng trả về phản hồi. Quá trình này xảy ra theo kiểu blocking.
Trong Webflux, điều này sẽ khác một chút:
Client gửi yêu cầu đến máy chủ non-blocking (Netty), bên trong có một event loop quản lý các yêu cầu này, sau đó truyền đến reactor-netty để làm interface reactive cho ứng dụng, tiếp theo là dispatcher handler, thông qua các functional endpoint sẽ tạo ra phản hồi này, và trong suốt quá trình này, các yêu cầu mới có thể được thực hiện mà không cần chờ yêu cầu cũ hoàn tất vì đây là kiến trúc non-blocking.
Chúng ta có thể nói rằng Spring WebFlux sử dụng những gì tốt nhất của stack servlet cùng với các tính năng reactive của nó.
Bên MVC chúng ta có lập trình mệnh lệnh, JDBC / JPA và các blocking dependencies / processes khác.
Bên Spring Webflux, chúng ta có các functional endpoint, event loop, Netty và một số tính năng đã tồn tại trong MVC nhưng trong Webflux bắt đầu có sự hỗ trợ lớn hơn, như các Reactive Clients.
Bài viết này đã giới thiệu lý do tạo ra WebFlux và sự khác biệt của nó so với MVC, trong bài viết tiếp theo chúng ta sẽ nói về Project Reactor!
Cảm ơn bạn đã đọc!
Nguồn: https://dev.to/kamilacode/spring-webflux-reactive-java-applications-part-2-5b0l