원글 페이지 : 바로가기
이번 프로젝트에 참여하기 전에, 개인적으로 결제 시스템의 핵심은 비동기라고 판단했다. 하여 결제에 대한 부분을 비동기적인 형태로 완성했다. CONTROLLER에서 호출단만해도, 비동기적인 작성은 이렇게 코드가 길어졌다. 하지만 리팩토링을 하면서 보니, 비동기적인 통신 형태에 대해 조금 더 명확하게 정리하고 이를 비동기적으로 설계하면 어땠을까 라는 아쉬움이 있었다. WEB FLUX VS MVC? 먼저, WEBFLUX와 MVC 패턴에 대한 예시를 보아야 한다. https://velog.io/@shdrnrhd113/Spring-MVC-Vs.-Spring-WebFlux 이와 같이, WEB FLUX와 MVC는 아키택처부터 다르다. MVC는 MODEL -VIEW- CONTROLLER 아키택처를 따른다. 이는 현재 가장 많이 상용화된 아키택처로써, 서브 시스템을 호출하고 해당 시스템에 MODEL이라는 정보를 전달, VIEW는 그것을 표현하는 시스템이다. 하지만 WEBFLUX는, 아키택처부터 다른 모델이다. 이러한 MVC패턴이 일련적인 모델이라면, WEBFLUX는 비동기적인 모델이 된다. https://velog.io/@suhongkim98/%EB%AA%85%EB%A0%B9%ED%98%95-%ED%94%84%EB%A1%9C%EA%B7%B8%EB%9E%98%EB%B0%8D-%EC%84%A0%EC%96%B8%ED%98%95-%ED%94%84%EB%A1%9C%EA%B7%B8%EB%9E%98%EB%B0%8D-%EB%A6%AC%EC%95%A1%ED%8B%B0%EB%B8%8C-%ED%94%84%EB%A1%9C%EA%B7%B8%EB%9E%98%EB%B0%8D-%EB%A6%AC%EC%95%A1%ED%8B%B0%EB%B8%8C-%EC%8B%9C%EC%8A%A4%ED%85%9C..-1 모델 형태가 다르다. 시스템 간의 통신 수단으로 탄력성과 회복성을 지니는 시스템의 형태임을 확인할 수 있다. (서브 시스템으로 계속 내려가는 MVC와는 구조 상의 차이가 있다.) (OBSERVER 패턴을 기반으로 했다고 한다!) WEBCLINET VS FEIGN? 두 매소드 모두, 사실 포함된 의존성과 사용 방식의 차이이며, 블로킹 , 논블로킹을 모두 지원한다. 하지만 현재 spring에서 권고하는 형태는 WEBCLIENT이다. MONO는? WEBCLIENT의 동작은 모두 MONO객체에 담아서 RETURN해야했고, 이객체는 JAVASCRIPT처럼 파싱이 되지도 않았기 때문에 코드 작성이 굉장히 힘들었다. 대체 MONO는 뭘까? https://thalals.tistory.com/381 MONO가 아닌 형태로 비동기 적인 요청을 진행하게 되면, 어떻게 그값을 받을 수 있을까. 아직 작업은 끝났다는 RETURN 전에는 끝나지 않은 것이다. (비동기 적이라는 의미이다) MONO객체는, 이러한 상황에서의 값을 응답할 수 있는 스트림 객체가 된다. (0개 , 혹은 1개의 데이터 값을 가지고 있다) 즉, 비동기 작업을 위한 스트림! 신기술과 기술의 적용은, 나만 쓴다고 다 되는게 아니었다. 특히 MSA 에서는 프로젝트 이전엔, 비동기적인 작업을 해서 속도를 높인다는 것에 큰 관심이 있었다. ++ 클라우드 , MSA구조이기 때문에 발생하는 수많은 통신에 대한 문제를 비동기로 해결하고자 했ㄷ었다. 하지만 결과적으론, 비동기적인 처리를 결제 부분에선 하지만, 통신 과정에서 동기적인 과정을 겪기 때문에 전체 과정은 동기적으로 진행된다. MSA 구조에선, 다른 작업들과의 통신을 매우 많이, 반복적으로 진행한다. 내가 사용했다고 해서, 남이 그것에 맞추어 사용하거나 하지 않을 수도 있다는 의미이다. 결제 부분에선 PORTONE,MEMBER,SERVICE와 모두 통신하기 때문에 비동기 적인 작업이 의미가 있을 수 있다. 하지만 다른 SERVICE는 그렇지 않다면? 이러한 부분을 고려하여 결제 부분을 설계할걸.. 하는 아쉬움이 남는다. 그렇다면, 내가 만든 WEBFLUX 통신은 장점이 하나도 없는가 그렇지 않다. 비록 PRODUCT와 MEMBER 등 내부 서비스와 통신하는 순간 비동기적이지 않고 동기적인 작업이 되지만, 그럼에도 FRONT -> PURCHASE -> PORTONE으로 이어지는 구간은 비동기적으로 동작, 작업한다. 이후 , PRODUCT와 MEMBER가 비동기적인 방식을 지원하는 형태로 (이유 있게) 변환하게 되면, 이에 맞는 기반을 쌓았다고도 할 수 있다. 거기에, 현재 SPRING이 추천하는 메소드 형태라는 점도 가산점. 완벽한 비동기가 깨짐에 아쉽지만, 그럼에도 비동기 작업의 기반을 다졌다는데에 의의를 두자. (다음 리팩토링은, 예외 처리를 진행하겠습니다.) 내 작업들은 순서가 정해져있지만, 그 순서 내부적으론 비동기적으로 동작할 수 있다. 말 그대로다. 결제->검증->~` 로 이어지는 과정은 순서가 정해져 있어 비동기적인 장점이 없어 보일 수 있어도. 결제 로직 내부적, 검증 내부적으론 비동기적으로 동작한다. 추가++ 리액티브 스트림의 mono가 제공하는 것 중 하나로, error에 감싸서 전달할 수 있다. 이렇게 되면 이러한 응답을 받은 front가, 해당 응답이 ERROR임을 명확히 판단할 수 있다! 서버의 에러는 아니기 떄문에 409로 표현하였다. 판매 완료되고, 결제가 취소됨을 명확하게 표현하였다.