WebFlux의 처리량은 Netty 구조에서 온다
Boss/Worker EventLoopGroup 분리부터 ChannelPipeline, EventLoop 블로킹 위험, ConnectionProvider 연결 풀 튜닝까지, Spring WebFlux의 성능 설계를 추적한다.
총 7개의 글
Boss/Worker EventLoopGroup 분리부터 ChannelPipeline, EventLoop 블로킹 위험, ConnectionProvider 연결 풀 튜닝까지, Spring WebFlux의 성능 설계를 추적한다.
I/O 집약 고동시성 환경에서 WebFlux가 MVC를 압도하는 조건부터, 블로킹 의존성·팀 역량·도메인 복잡도가 만드는 함정까지, 도입 판단의 기준을 추적한다.
Mono/Flux의 지연 평가부터 Backpressure 전략, Reactor Context까지 — WebFlux가 왜 이 방식으로 동작하는지, 그 근본 원리를 추적한다.
JPA의 블로킹 JDBC가 EventLoop를 점유하는 원리부터 R2DBC의 논블로킹 구조, Reactor Context 기반 트랜잭션, N+1 해결 패턴까지 WebFlux 데이터 계층의 설계 결정을 추적한다.
Thread-per-Request 모델이 I/O 앞에서 무너지는 이유부터 epoll 이벤트 루프, Reactive Streams 스펙, 그리고 WebFlux vs MVC 선택 기준까지 하나의 흐름으로 추적한다.
MVC Security의 ThreadLocal 기반 설계가 Reactor Context로 대체되는 과정부터, JWT 필터 체인·Method Security·OAuth2 Client Credentials 흐름까지, Reactive Security 전체를 관통하는 설계 원칙을 추적한다.
DispatcherHandler의 Reactive 위임 구조부터 WebClient 병렬 호출, SSE/WebSocket 스트리밍, WebFilter 불변 패턴까지 — WebFlux 설계 철학의 일관된 흐름을 추적한다.