시스템이 너무 복잡해져서 ROI 등을 따져서 적절하게 MSA로 전환하는데,
이벤트 방식으로 데이터 변경 사항을 전파시(loose 커플링, 장애 복구성 등의 장점 때문에) 순서에 대한 보장의 문제 등을 겪게 될겁니다.
이런 순서에 대한 문제를 해결하기 위한 방법이 있기는 하지만, 코드 및 아키텍쳐의 복잡성을 낮추기 위해서 저는 보통 zero-payload방식을 사용(추천)합니다.
간단히 핵심 내용만 정리하자면 아래와 같습니다.
- 데이터 발생서비스는 메시지큐(kafka, aws sqs 등)에 변경이 발생한 데이터의 id(예. 주문ID와 같은 RDB에서의 PK)만 메시지큐에 발행(pub)
- 전파받아야하는 서비스(메시지 큐를 sub)하는 서비스는 해당 id로 메시지 발행 서비스에 API로 최신정보를 조회
참고 링크: reflectoring.io/microservice-communication-patterns/
Microservice Communication Patterns
A discussion of several different communication patterns between distributed micro services.
reflectoring.io
'아키텍쳐 > MSA 아키텍쳐' 카테고리의 다른 글
| MSA에서 outbox패턴을 이용한 트랜잭션 처리하기 (0) | 2020.07.10 |
|---|---|
| Microservice Architecture ( outbox pattern) (0) | 2019.09.18 |
