동기: Resttemplate, Feign Client
비동기: 메세지브로커(Kafka, Amazon SQS 등) - AMQP 프로토콜
말씀하신 내용처럼 서비스 간의 통신 요청을 한 다음 응답을 기대리지 않고 다른 작업을 할 수 있다는게 Kafka나 RabbiMQ와 같은 메시징 큐 서비스의 특징. GET방식에서의 비동기도 요청에 대한 응답이 오기까지 기다리지 않고 다른 작업을 진행하면서, 응답이 전달되면, 해당 처리를 하게 할 수 있다. 예를 들어 아래와 같은 대시보드 화면에서 각각의 그래프를 표시하는 데이터를 하나씩 GET 방식으로 요청했다고 생각해 보면, 데이터를 응답 받지 못한 그래프는 Loading 상태로 표시되면서, 응답이 전달된 요청에 대한 그래프는 바로 그래프를 표시한다. 바로 각각의 그래프를 처리하는 작업에서 MSA로 구현되고, 비동기로 응답된 데이터를 처리
뉴르 리뷰 작성 -> 뉴스 점수 증가
위의 트랜잭션을 만든다고 할때, review api가 producer 역할로서, 리뷰가 작성되면 MQ로 메시지를 보내 news api에서 뉴스의 점수를 증가시켜주는 consumer 역할을 수행 할 수 있어야합니다.
비동기 처리 이유
Tightly Coupled System의 구조에서는 한 시스템이 장애가 발생했을 때 그 장애가 연결된 다른 시스템들에 영향을 미치기 쉽다.
대표적인 케이스로, 서버1 -> 서버2 -> DB2의 이벤트 플로우에서, 서버2에 장애가 발생해서 필요한 이벤트를 받아내지 못했을 때, 그 이벤트와 관련된 데이터가 모두 유실되어 버릴 가능성이 있는 것이다. 그렇기 때문에 MSA의 장점을 살리려면 서비스 간 결합이 느슨해야 한다
WebFlux와 차이점
WebFlux와 Message Broker는 사용 용도가 다르다. Spring WebFlux는 Spring Framework에서 그동안 동기 방식으로 처리되었던, ServletReqeust, ServletResponse 방식 대신 ServerRequest, ServerReponse를 사용하면서 비동기 프로그래밍을 처리하는 것이고, Messaging Broker는 시스템 간, 서비스 간, 애플리케이션 간에 메시지를 송수신 하기 위해 사용되는 기술. 메시지로 전달될 수 있는 형태는 다양하며, 연결할 수 있는 시스템, 서비스, 애플리케이션도 다양하다. 예를 들어, GPS와 연동되어 실시간 현재 위치(위도, 경도)를 데이터베이스에 저장하는 애플리케이션이 있다고 가정. GPS 정보를 1초에도 수십/수백 건의 데이터가 발생할 수 있고, 그 데이터를 데이터베이스에 저장하는 것은 성능도 문제고, 비용도 상당히 발생한다. 이때 Messaging Broker를 도입하여, 발생하는 데이터를 송신하고, Broker에서는 streaming 된 데이터를 Batching 등 활용하여 일괄적으로 DB에 저장할 수도 있다. (https://www.confluent.io/product/ksql/)
