들어가기 전
하나의 서비스를 구성하고 설계하는 법은 사고가 넓고
경험이 많아야 한다.
예외처리가 관건이고 사용자의 편의를 생각하는 사람이 잘하는 거 같다.
FeignClient
간단하게 설명하면
모듈끼리 Http 프로토콜을 이용한 API 통신
그럼 한가지를 알 수 있다.
- 즉각 처리가 필요한 모듈의 통신에 필요한 기능
출처는 불분명하지만 FeignClient의 사용법
-
실시간 응답이 필요할 때: 주문을 생성할 때 상품 재고를 즉시 확인해야 한다면, order 서비스가 product 서비스의 재고 조회 REST API를 호출할 수 있습니다.
-
요청-응답 패턴: 요청자(consumer)가 결과를 즉시 받아야 하는 경우(ex. 결제 승인 요청 및 결과 확인).
-
트랜잭션적으로 묶을 필요성이 있을 때: 부분적으로나마 트랜잭션(예를 들어 SAGA 패턴 등)에 사용될 수 있습니다.
위의 내용들을 보면 조회나 즉시 응답이 필요한 내용에 사용되는 것이다.
그럼 RabbitMQ의 사용법을 알아보고 마지막에 비교 표를 작성해보자
RabbitMQ
큐를 이용한 모듈 간의 통신, 비동기 처리가 가능하다
큐?
FIFO의 원칙을 이용한 배열로써 순서처리가 필요한 경우에 사용한다.
그럼 MQ를 사용해서도 모듈 간의 정보 통신이 가능하다.
어떤 경우에 사용하는지 알아볼 필요가 있다.
-
비동기 처리가 적합할 때: 주문 처리 후 결제 서비스에 결제 정보 전송 등 즉각적인 결과를 필요로 하지 않는 경우.
-
프로세스 분리: 주문 요청이 많아져도 결제나 배송 등 후속 프로세스가 느려져 전체 시스템이 영향을 받지 않도록 하고 싶을 때.
-
이벤트 기반 구조: 주문이 생성되면 MQ에 “OrderCreated” 이벤트를 발행하고, 결제·상품·배송 등 관련 서비스가 필요한 작업을 비동기로 처리.
-
내결함성과 확장성: MQ를 통해 메시지가 일시적으로 저장되므로, 네트워크 장애나 부분 서비스 장애가 발생해도 데이터 손실 없이 서비스가 복구되는 대로 처리 가능.
(근데 개인 적인 의견으로는 위의 내용들이 틀렸다고는 못하지만응용프로그램과의 통신은 큐로 통신을 주고 받으면 안된다 생각한다.-이후 내용은 추가로 TIL로 작성하고자 한다.)
RabbitMQ vs FeignClient
생각 날때마다 추가 예정
| 구분 | 응답 시간 | 동작 |
|---|---|---|
| RabbitMQ | 처리 후 응답 | 테스트3 |
| FeignClient | 즉시 응답 | 테스트3 |
