[도메인 주도설계로 시작하는 마이크로서비스 개발] 책 리뷰

http://aladin.kr/p/7yaJl

도메인 주도 설계로 시작하는 마이크로서비스 개발

집앞 도서관에서 책을 훓어보다가 MSA 관련해서 읽기 쉬운 책을 발견해서 읽어보는 중이다. 몇가지 정리해본다.

스프링 클라우드 기반 아키텍처(MSA)

https://engineering-skcc.github.io/microservice%20outer%20achitecture/outer-architecture-2/

• 서비스 레지스트리
  • 대표 도구: 스프링 유레카, 쿠버네티스 DNS 및 서비스
• 서비스 라우팅기능
  • H/W 구현: L4
  • S/W 구현: API 게이트웨이
    • 대표 도구: 스프링 API 게이트웨이 서비스, 쿠버네티스 서비스·인그레스 리소스
• 외부 저장소: 각 마이크로서비스의 외부환경설정 정보를 공동으로 저장하는 백업 저장소
  • 대표 도구: 스프링클라우드 컨피그, 쿠버네티스 컨피그맵

마이크로서비스 통신패턴

• 동기 통신방식: REST API
• 비동식 통신방식: (메세지 브로커 이용한) 아파치 카프카, 래빗엠큐, 액티브엠큐

저장소 분리 패턴

https://engineering-skcc.github.io/microservice%20outer%20achitecture/inner-architecture-saga/

• 저장소 격리
• 자신이 소유한 데이터는 다른 서비스에 직접 노출하지 않고 각자가 공개한 API를 통해서만 접근할 수 있다(정보은닉).
  ❓ 그렇지만 어떻게 비즈니스 정합성 및 데이터 일관성을 보장할수 있을 까? 👉 분산트랜잭션 처리 패턴을 사용

분산트랜잭션 처리 패턴

https://engineering-skcc.github.io/microservice%20outer%20achitecture/inner-architecture-saga/

사가 패턴

• 여러개의 분산된 서비스를 하나의 트랜잭션으로 묶지 않고 각 로컬 트랜잭션과 보상 트랜잭션을 이용해 비즈니스 및 데이터의 정합성을 맞춘다.
• 트랜잭션 실패 시, 이전 로컬 트랜잭션이 작성한 변경사항을 취소하는 일련의 보상 트랜잭션을 통해 비즈니스 일관성을 유지한다.
  (보상 트랜잭션: 어떤 서비스에서 트랜잭션 처리에 실패한 경우, 그 서비스의 앞선 다른 서비스에서 처리된 트랜잭션을 되돌리게 하는 트랜잭션)

CQRS 패턴(명령 조회 책임 분리)

https://engineering-skcc.github.io/microservice%20outer%20achitecture/inner-architecture-cqrs/

• 쓰기/조회 저장소를 따로 준비하여, 명령 측면과 조회측면의 두 부분으로 나눈다. 그 대신, CUD저장소와 뷰 저장소를 MQ를 통해 동기화한다.
• API의 직접적 의존성을 줄일 수 있다.