https://www.youtube.com/watch?v=BnS6343GTkY
위의 사례 중 Domain Event 및 CQRS 관련 일부 내용 발췌 + 첨언
리뷰, 라이더스 등 Callee 서비스 장애 시 Caller인 주문 서버스도 연쇄적으로 장애
- 이벤트 기반으로 주문의 Lifecycle을 정의
- 전사에서 이해할 수 있는 명확한 주문 Lifecycle 이벤트 정의
- 쇼핑몰이라면 주문, 취소, 교환, 반품 등
상품, 가입 등 다른 업무에도 위와 같이 적용 가능 - 앞으로 주문 서비스는 약속된 위의 이벤트를 발행할거야 필요한 서비스들이 가져가서 각자 알아서 사용해
- 이렇게 해두면 앞서 API기반의 경우와 같이 리뷰 서비스 장애 시 주문과 관련이 없고
리뷰 서비스가 살아나면 그 동안 쌓여있던 이벤트를 받아서 못했던 일을 하면 됨
(5분동안 죽었다면 5분뒤 살아나면서 리뷰 해달라 요청하면 됨)
-> 회복력(Resilience) 좋아짐 - 새로운 서비스가 추가되고 그 서비스도 주문의 Lifecycle이 필요하다고 하면 이미 정의되어 있는 Lifecycle의 이벤트를 구독해 바로 사용 가능
-> 확장성(Scalability) 좋아짐, 주문팀이 편해짐
예전 같았으면 주문 완료 시점에 추가된 시스템의 API 를 호출하는 등 주문의 로직을 추가/변경했어야함 - 이렇게 Event Driven으로 변경되면서 서비스 간의 결합도가 낮아져 장애가 급격히 줄어듬
'MSA해설 > EDA' 카테고리의 다른 글
EDA로 가라 (0) | 2022.12.06 |
---|---|
Event Driven Architecture 정의 (0) | 2022.12.02 |
Batch? Event? (0) | 2022.11.10 |
분산 시스템은 근본적으로 다르다? (0) | 2022.09.01 |
실시간도 아니라는데 굳이 비동기 통신을 해야하나요? (0) | 2022.07.22 |