작성
·
327
0
현재 강의는 핵사고날 아키텍처를 사용하여 결제 시스템을 구축하고 있습니다. 어니언 아키텍처로도 충분히 의존성을 안쪽으로 향하게 하여 entity와 usecase를 외부 변경으로 부터 보호가 가능하지 않나 생각이 들었습니다.
(결정적으로 핵사고날은 구조가 좀 복잡했습니다.)
webflux를 쓰신 이유가 궁금합니다. 강의에서 내세운 견고한 시스템을 만들기위한 요구사항을 읽어봤을 때 반응성이 아니더라도 충분히 무리가는 상황이 아니기도 했고
성능보단 견고함이 중요한 상황인데 webflux를 쓰신 이유가 궁금합니다!
제 역량이 모자라 이해 못하는 부분이 있을 수 있어 배우고자 질문드립니다. 감사합니다!
답변 1
1
안녕하세요~ 질문 남겨주셔서 감사합니다.
궁금한 사항이 있으셨던 것 같은데 제 생각을 남겨볼게요.
1) 어니언 아키텍처가 아닌 핵사고날 아키텍처로 한 이유:
저는 어니언 아키텍처와 핵사고날 아키텍처가 크게 다르다고 생각하지는 않아요. 핵사고날 아키텍처가 조금 더 복잡할 순 있겠지만 외부 시스템과의 입출력 상호작용을 파악하기 더 쉽다라고 생각하기 때문에 사용했습니다. 장단점을 판단해서 자신에게 맞는 아키텍처를 사용하면 될 것 같습니다.
2) Webflux 를 사용한 이유:
Spring Webflux 와 Spring MVC 를 비교했을 때 Webflux 가 좀 더 복잡한 프로그래밍을 요구하는 것 제외하고는 웬만해서는 MVC 보다 안정성 측면에서도 더 뛰어나다고 생각해요.
현재의 시스템은 서비스들이 마이크로서비스처럼 대부분 쪼개져있고 필요할 때 외부 통신을 하는데요. Spring MVC 와 같은 Synchronous Client 를 사용하게 되면 외부 서비스들이 장애가 나거나 요청이 안왔을 때 리소스가 점유당하는 문제가 생길 수 있습니다. 그에 반해서 웹플럭스와 같은 Asynchronous Client 는 하나의 이벤트 루프에서 최대 500개 까지의 Active Channel 을 맺을 수 있기 때문에 외부 서버의 장애에 클라이언트를 보다 보호해줄 수 있는거죠.
현재의 이 결제 시스템의 경우에는 외부 시스템과 상호작용하는 API 가 거의 없는데요. 카카오페이의 경우에는 수십개의 API 를 사용한다고도 합니다. 이 경우에는 Webflux 가 보다 안전할거에요.
도움이 되셨으면 좋겠습니다. 제 답변이 잘 와닿지 않는다면 다시 질문 주세요~
이해 됐습니다. 감사해요 사용자 요청으로 부터 발생하는 트래픽을 높은 동시성으로 해결하겠다로 바라봤는데 오히려 외부 수십개의 API를 높은 동시성으로 해결하는 것이군요. 또 webflux가 제공해주는 library를 사용하는 것이 MVC에서 직접 문제를 해결하기위한 라이브러리를 만드는 것 보다 안정성이 뛰어나기 때문이고요!