Spring MVC vs Webflux - GANGNAM-JAVA/JAVA-STUDY GitHub Wiki

Spring MVC vs Webflux

• Spring MVC는 Java EE의 Servlet Spec에 기반하여 만들어 졌다.
  • Synchronous blocking I/O 구조를 사용
  • 1 request -> 1 thread
• Webflux는 non-blocking web framework이다.
• 내장 서버
  • Webflux('spring-boot-start-webflux')의 기본 내장 서버는 Netty(비동기적인 이벤트 중심의 서버 중 하나)이다.
  • Spring Boot starter('spring-boot-starter-web')의 기본 내장 서버는 Tomcat이다.
• Programming 방식
  • Spring MVC는 명령형 로직(Imperative programming)으로, 코드 작성 및 디버깅이 쉽다.
    • 작업이 수행되는 동안 완료될 때까지 아무 것도 할 수 없다(이 작업을 수행하는 스레드는 차단되고, 차단되는 스레드는 낭비다).
  • Webflux는 이벤트 기반의 reactive programming 방식이다(명령형 프로그래밍의 대안).
    • 연결을 수락하는 하나의 보스 스레드와 cpu의 코어 수에 비례하는 N개의 워커 스레드만으로 구성(many request -> 1 thread)
• Event loop concurrency model
  • 모든 것이 이벤트로 처리
  • 이벤트 루프가 DB나 네트워크 작업과 같은 집중적인 작업의 콜백을 등록하여 병행(concurrency)으로 수행되게 하고, 다른 이벶트 처리로 넘어간다.
  • 작업이 완료되면 완료 이벤트를 푸시하게 되고, 이를 이벤트 루프가 받는다.
• Webflux는 2가지 모델을 지원한다.
  • Annotated Controller
    • Spring MVC 모델 기반의 기존 spring-web 모듈과 같은 방식으로 구성하는 방법, Spring MVC에서 제공하는 어노테이션들을 그대로 사용 가능
  • Functional Endpoints
    • lambda 베이스의 lightweight한 함수형 프로그래밍 모델
    • request을 routing과 handling 할 때 사용하는 라이브러리
    • callback 형태로써 요청이 있을 때만 호출된다는 점이 annotated controller 방식과의 차이점

Webflux의 탄생 이유

Servlet 3.1에서 non-blocking I/O에 대한 API를 제공했으나, non-blocking API를 사용하게 되면 Filter, Servlet 등의 동기화나 getParameter, getPart 등의 blocking을 API을 사용하지 못하게 된다. 이는 곧 non-blocking이 기반이 되는 새로운 공통 API가 필요한 이유가 되었다.

참고

• https://spring.io/reactive
• https://docs.spring.io/spring/docs/current/spring-framework-reference/web-reactive.html
• https://docs.spring.io/spring-framework/docs/5.0.0.BUILD-SNAPSHOT/spring-framework-reference/html/web-reactive.html
• https://docs.spring.io/spring-boot/docs/1.1.3.RELEASE/reference/html/howto-embedded-servlet-containers.html#howto-use-jetty-instead-of-tomcat
• https://docs.spring.io/spring/docs/current/spring-framework-reference/web-reactive.html#webflux-new-framework
• https://dreamchaser3.tistory.com/6
• https://kimyhcj.tistory.com/343