Java를 시작한지 289일, 블로그를 만든 건 285일차.

API 를 해석하고 정리하고, 개인 취미로 Spring WebFlux 도큐먼트를 해석해 정리하고 있다.

 

읽다가 이해안되면 구글 번역기에 문장을 띄우고서 문장 흐름을 보며 다시 정리한다. 보여준대로 읽으면 이해 안된다.

 

비동기, 논 블로킹에 대한 환상이 좀 있었는데, 리엑티브 선언문 + 도큐먼트 안내 보고선 와장장 부쉈다.

 

읽어보니 선택 기준에 따라 다른 것이지, Web MVC 와 Web Flux 는 따라다닌다.

 

이해한바로는 SPA 처럼 응답자가 기다리는 읽기요청에는 WAS Thread 소비를 최소화 하고자 내부 Thread Pool 을 돌리고 기다리는 응답자가 필요없을 경우 메세지 큐를 이용해 이벤트를 퍼블리싱 하는 모양이다. 이게 핵심같다. WAS 내부 쓰레드를 최소화해서 적은 자원으로 서버를 돌리겠다. 라는 거.

 

Netty 같은 비동기 특화 WAS, Servlet3.1 이상대도 지원하기는 하는 듯한데 서블릿 내부메서드가 블로킹 되는 경우가 많더라.

 

getParameter, getPart 같은 애들이 그렇더라. 파라미터와, 데이터를 받는 아이들인데 블로킹이라니..하면서 탄식을 하기도 했다.

 

공부는 늘 이렇다. 이게 매력인데, 알려달라고 입벌리고 있는것보다 직접 찾아나서는 게 더 느끼는게 많다는 것이다.사실 알려달라고 가만히있으면 스스로 좀  자괴감을 느껴서, 그건 싫고. 알려줘도 알고나서 아는게 느끼는 것도 많더라, 라는 개인적 감상이다.

 

MSA 같은 경우 하나의 MS 는 작은 크기의 축소 App 이니 , 경량 App 기준에서는 리엑터 기반 Web Flux 를 쓰는게 알맞아 보였다.

 

하지만 클라이언트가 일반 브라우저냐, 다른 조직이냐 읽기냐 쓰기냐..등등에 따라 동기, 논블로킹 동기, 메세지 기반 비동기 방식이 갈리니까. 아마 혼합되어 쓰지 않을까 싶다.

 

어찌되었든 느낀 핵심은 JPA JDBC 같은 블로킹 데이터베이스 구현체에서는 WAS 부담의 최소화하기 위해 Thread Pool 을 내부에서돌려줘야하겠다. 라는 것이다.

 

여튼 서문을 보았으니, 취미로 계속 진행해보아야겠다.