일체형 어플리케이션
마이크로 서비스로 시작했을 때 단점
- 여러 개의 모음 마이크로서비스는 배포 관리, 테스트가 불리
- 시스템 설꼐에 불리(각 마이크로서비스만을 생각하게됨)
=> 개발, 통합 테스트, 표준, API, 로깅&모니터링, 에러처리, 커뮤니케이션방법 등등에 많은 주의가 필요
첫 릴리즈까진 일체형으로 개발 후 마이크로서비스로 분리하여 개발 진행
- 첫 릴리즈와 그 후 마이크로 서비스는 연결되고, 분리 확장 가능해야함
- 에러 확률 낮아짐
- 일체형 어플리케이션이 더 커지는 것을 방지할 수 있음
(프로젝트가 무거워지고, 개발 가이드라인을 지키지 못할 위험 생김) - 다른 개발 기능에 관계없이 서비스 개선 가능(다른 서비스에 영향이 없기때문)
이벤트 중심 아키텍쳐
마이크로서비스 연결 방법
1. DB 공유
-> 데이터를 공유하면 컨텍스트 분리의 이점이 사라짐
2. 다른 서비스가 주기적으로 데이터를 끌어오는 방법
-> 필요하지 않아도 지속적으로 데이터를 끌어와야함
3. 이벤트가 발생하면 마이크로서비스를 호출하여 데이터 업데이트
-> 서비스가 분리된 상태로 설계 가능
다른 프로세스에 영향을 주지 않고 연결 가능
이벤트 중심 아키텍쳐
: 중요한 행위가 일어날 때마다 마이크로서비스 이벤트 전송
마이크로서비스는 메시지 브로커(이벤트 버스)를 톨해 이벤트 주고받음
이벤트를 구독하고 처리
이벤트 네이밍
- 과거형 (SolvedEvent)
- 해당 이벤트를 구족하면 로직을 수행하고 다른 이벤트 발행 가능특징
- 낮은 결합도
- 서비스 전체에 트랜젝션 없음
: 요구사항 설계와 변환 방법 변경 - 장애 허용 능력
: 서비스 중 하나가 멈춰도 전체 서비스는 멈추지 않기 때문에 데이터를 복구하는 방법 중요
RabbitMQ
: 스프링 부트와 연동되는 오픈소스 메시지 브로거 (AMQP 프로토콜 사용)
프로듀서
: 메세지 발생
- 프로듀서는 큐에 직접 메시지를 넣을 수 없다
- 익스체인지 채널을 통해서만 메시지 전송 가능
익스체인지
: 받은 메시지를 어느 큐에 넣을지 결정 (일종의 라우터)
- 다이렉트
: 라우팅 키가 일치하는 큐에 메시지 전송 - 토픽
: 라우팅 키 패턴이 일치하는 큐에 메시지 전송 - 헤더스
: 라우팅에 헤더 사용, 헤더와 일피하는 큐에 메시지 전송 - 팬아웃
: 모둔 큐에 전송
큐
: 발생 메시지 보관 버퍼, 하나의 큐에 여러 개의 라우팅 키 부여 가능
컨슈머
: 메시지 수신
