[빗썸테크아카데미] 네번째, 다섯번째 - WebFlux

 

 

[빗썸테크아카데미] 네번째, 다섯번째 - WebFlux

 

 

네번째 날에는 퀴즈와 과제를 진행하는 시간이었기 때문에, 크게 기록할 것이 없어 다섯번째와 합쳤다.

퀴즈는 Event Driven Architecture와 동기/비동기 & 블로킹/논블로킹에 관한 문제였고

과제는 Reactor operator로 코드짜기 6문제였다.

 

Java나 Kotlin 둘중 아무거나 써도 된다고 해서,

나는 kotlin으로 개발을 하다보니

처음엔 kotlin으로 짜려고 했는데

생각해보니 과제 페어리뷰를 하려면 다른 사람에게 설명을 해야했다.

 

대부분이 자바 개발자였기 때문에

나한테 편한 kotlin보다는 다른사람들이 이해하기 쉬운 Java로 짜는게 좋을 것 같아 

Java로 코드를 작성했다.

 

과제를 다 끝내고 심심해 하던차에

어떤 분이 디스코드에 빌드 오류가 난다고 해서

그거 같이 해결해주면서

뭔가 뿌듯함을 느꼈다 ㅋㅋㅋ

 

이맛에 개발하지

 

 

---

 

다섯번째 수업에서는

과제 리뷰를 하고,

WebFlux 수업을 진행했다.

 

 

1. Spring WebFlux

1.1 spring WebFlux란?

• reactive stack을 지원하는 web container framework. 기본적으로 Non blocking 컨테이너를 사용
• 기존의 Spring MVC는 기본적으로 Blocking 기반의 컨테이너 이다.

 

Non blocking I/O

• 최소한의 리소스로 효율적인 운영
• Singler worker thread가 Event loop 처리

 

Functional Endpoints

• Lambda 기반 functional programming model
• Request Router가 handler로 request routing
• Handler method에 @RequestMapping 선언부 없이 request/response를 App에서 전부 제어

 

 

 

1.2 Spring MVC VS WebFlux

 

 

 

1.2.1 동시접속 유저(Concurrent Users)당 Response Time

• 초록색은 WebFlux, 빨간색은 MVC
• WebFlux는 동시접속자가 5000명까지도 Response Time이 일정한 반면, MVC는 동시접속자가 1500명부터 Response Time이 급격하게 증가한다
• WebFlux는 개발자의 높은 전문성을 요하고, 유지보수가 힘들기 때문에 1500명까지는 MVC 모델이 효율적            -> 머신의 성능이 좋을 수록 MVC의 효율 구간이 증가하기 때문에 회사에 돈이 많으면 그냥 MVC 모델 써도 좋음
• 그 이후는 응답성을 위해 WebFlux가 좋음

 

 

1.2.2 개발을 할 때 어떤것을 선택해야 할까?

새로 구축한다면

• 기능에 따라 -> 기능이 적으면 MVC
• 내부 호출양에 따라 -> 호출량이 적으면 MVC
• 개발팀 구성에 따라 -> WebFlux는 러닝커브가 높기 때문에 배울 수 있는 환경인가?

 

기존에 MVC 앱이 있다면

• 사용량에 따라 -> 사용량이 적으면 MVC
• 로직 내부 복잡도에 따라 -> 복잡하지 않으면 MVC
• 고장나지 않는다면 고치지 마라

 

WebFlux나 MVC를 쓰면서 몇개의 컴포넌트를 섞어 쓸 수도 있음

 

 

 

 

1.3 WebFlux 프로젝트 구성

Filter

• WebHandler API에 적용
• 요청 처리 전에 선행 로직 실행 가능 -> ex) 로그인 검사, 토큰 검사, path 변경 등...
• MSA의 API Gateway 역할을 하는 App에서 자주 사용

-> Filter Class 예시 : 함수를 정의하고, apply 안에서 사용

 

 

-> RouteConfig에서 gateway Filter 사용

-> host(SERVER_URL) 또는 path("/auth/user/**")로 들어온 요청들은 filter를 적용 후 AUTH-SEVICE_URI로 보냄

 

 

Handler

1. HttpHandler

• Annotated Controller(기존의 MVC와 동일한 형식) 와 같은 기본적인 것들이 포함

 

2. Functional Endpoint

2.1. WebHandler

• HttpHandler를 확장해서 만든 것
• WebHandler로 Funcitonal Endpoint를 만들면 DispatcherHandler가 각 컴포넌트를 호출

2.1.1. Handler Method(functional)

public Mono<ServerResponse> createPerson(ServerRequset serverRequest) {
	Mono<Person> stringBody = request.bodyToMono(Person.class);
    
    //..
    Mono<Person> savedPerson = // 뭔가 reactive한 서비스 메소드...
    
    return ServerResponse.ok().body(BodyInserters.fromValue(response));

}

 

 

3. Router

• Routing Function : Handler Function에 request routing
• @RequestMapping은 data만 전달하는 것에 비해, Router Function은 Mono<HandlerFunction>을 전달
• RouterFunctions.route()의 builder 사용 -> 위에서 아래로 순서대로 매핑

RouterFunction<ServerResponse> route = route()
	.path("/person", builder -> builder
    	.GET("{/id}", accept(APPLICATION_JSON), handler::getPerson)
        .GET("", accept(APPLICATION_JSON), handler::listPeople)
        .POST("/person", handler::createPerson))
    .build();

-> Post /person/person은 2.1.1.의 createPerson Handler Function으로 가게 된다.

 

WebClient, WebfluxConfigurer

• Non blocking Http Client Module : WebClient <-> Blocking Http Client Module : RestTemplete

• RestTemplete은 다른 서버에 요청을 보내고 받을때 Blocking 됨.
• WebClient는 다른 서버에 요청을 보내고 받을때 Nonblcoking 되기 때문에 Thead를 낭비하지 않고 원활하게 동작

 

 

1.4 R2DBC

• JDBC의 Blocking API를 대체하는 Nonblocking API Stack
• Spring 5.3.2+에서 동작

 

 

1.5 Handling Errors

• WebFilter / WebHandler Chain 에서 발생한 Exception 처리

 

 

 

 

 

 

---

 

완죠니 처음 들어보는 WebFlux...

듣는 내내 무슨소린지 이해가 안갔다..ㅋㅋㅋ

 

지금 정리하면서 조오금 이해한 수준

이번주 내내 다 처음 듣는 내용이라 맨날 복습하면서 이해했는데

아마 다음주랑 다다음주도 계속 그렇지 않을까 싶긴하다.

 

다음주 수업 주제는 MSA인데, 다음주는 매일매일 과제가 있다고 한다