8. 스프링 클라우드 스트림을 사용한 이벤트 기반 아키텍처

비동기 메시지를 사용해 다른 마이크로서비스와 통신하는 스프링 기반의 마이크로서비스를 설계하고 구현하는 방법을 알아보자

목표

8. 스프링 클라우드 스트림을 사용한 이벤트 기반 아키텍처

메시지를 사용해 상태 변화를 표현하는 이벤트로 통신하는 방법

이벤트 기반 아키텍처(EDA, Event Driven Architecture)

메시지 기반 아키텍처(MDA, Message Driven Architecture)

EDA 기반의 접근 방식을 사용하면 특정 라이브러리나 서비스에 밀접하게 결합하지 않고 변화에 대응할 수 있는 높은 수준으로 분리된 시스템 구축 가능

8.1 메시지와 EDA, 마이크로서비스의 사례

캐싱 솔루션 구현의 핵심 요구 사항

1. 캐싱된 데이터는 라이선싱 서비스의 모든 인스턴스에 일관성이 있어야 한다
    
2. 라이선싱 서비스를 호스팅하는 컨테이너 메모리에 조직 데이터를 캐싱해서는 안 된다
    
3. 업데이트나 삭제 연산으로 조직 레코드가 변경될 때 라이선싱 서비스는 조직 서비스의 상태 변화를 인식해야 한다

8.1.1 동기식 요청 - 응답 방식으로 상태 변화 전달

문제점

1. 서비스 간 강한 결합
    
2. 쉽게 깨지는 서비스 관계
    
3. 조직 서비스 변경에 관심 있는 새 소비자를 추가할 때 경직성

8.1.2 메시징을 사용해 서비스 간 상태 변화 전달

1. 느슨한 결합 - 서비스가 소유한 데이터를 직접 관리하는 엔드포인트만 노출함으로써 의존성을 최소화
    
2. 내구성 - 큐가 존재하므로 서비스 소비자가 다운될 때도 메시지 전달 보장
    
3. 확장성 - 메시지가 큐에 저장되므로 메시지 소비자를 더 많이 가동시켜 더 빠르게 처리 가능(수평 확장)
    
4. 유연성 - 원래 발신 서비스에 영향을 주지 않고 새로운 메시지 소비자를 쉽게 추가 가능

8.1.3 메시지 아키텍처의 단점

1. 메시지 처리의 의미론 - 애플리케이션이 메시지의 소비 순서를 기반으로 어떻게 동작할지와 메시지가 순서대로 처리되지 않을 때 어떤 일이 발생할지 이해해야 한다
    
2. 메시지 가시성 - 마이크로서비스에서 메시지 사용은 동기식 서비스 호출과 서비스 내 비동기 처리가 합쳐진 것을 의미한다.  웹 서비스의 호출과 메시징을 경유하는 사용자 트랜잭션을 추적할 수 있어야 한다
    
3. 메시지 코레오그래피 - 단순한 요청-응답 모델을 사용해 선형적으로 처리되지 않으므로 비즈니스 로직을 추론하는 것이 더 어려워진다

8.2 스프링 클라우드 스트림 소개

애플리케이션 메시지 발행자와 소비자를 쉽게 구축할 수 있는 애너테이션 기반 프레임워크

8.2.1 스프링 클라우드 스트림 아키텍처

1. 소스 - 메시지를 받아 직렬화(JSON)하고 메시지를 채널로 발행
    
2.  채널 - 메시지 생산자와 소비자가 메시지를 발행하거나 소비한 후 메시지를 보관할 큐를 추상화 한 것, 채널이 읽거나 쓰는 큐를 전환하려면 코드가 아닌 구성 정보를 변경
    
3. 바인더 - 특정 메시지 플랫폼과 통신, 메시지를 발행하고 소비하기 위해 플랫폼마다 별도의 라이브러리와 API가 필요 없음
    
4. 싱크 - 서비스는 싱크를 사용해 큐에서 메시지를 받음, 들어오는 메시지를 위해 채널을 수신 대기하고, 메시지를 다시 POJO로 역직렬화한다

8.2.1 스프링 클라우드 스트림 아키텍처

1. 소스 - 메시지를 받아 직렬화(JSON)하고 메시지를 채널로 발행
    
2.  채널 - 메시지 생산자와 소비자가 메시지를 발행하거나 소비한 후 메시지를 보관할 큐를 추상화 한 것, 채널이 읽거나 쓰는 큐를 전환하려면 코드가 아닌 구성 정보를 변경
    
3. 바인더 - 특정 메시지 플랫폼과 통신, 메시지를 발행하고 소비하기 위해 플랫폼마다 별도의 라이브러리와 API가 필요 없음
    
4. 싱크 - 서비스는 싱크를 사용해 큐에서 메시지를 받음, 들어오는 메시지를 위해 채널을 수신 대기하고, 메시지를 다시 POJO로 역직렬화한다