확장큐브
- x축: 부하 분산
- 일반적인 모놀리식 애플리케이션 확장 수단
- z축: 라우팅
- 다중 인스턴스 실행, 요청의 속성에 알맞는 인스턴스로 라우팅
- y축: 서비스 분해
- 여러 서비스로 쪼갬
MSA 단점
- 특정 서비스마다 DB가 따로 있어 다중 DB에 접속하여 조회하고 트랜잭션을 구현하는 것이 어렵다. -> 사가패턴 이용
- 단순 쿼리로는 데이터를 조회할 수 없다 -> API 조합 or CQRS 뷰
-> 만병통치약은 아님, 단순하면 당근 모놀리식이 맞다!!
마이크로서비스 아키텍처 패턴 언어 개요
애플리케이션을 여러 서비스로 분해하는 패턴
- 비즈니스 능력에 따라 분해
- 하위 도메인에 따라 분해
통신패턴
- 통신 스타일: 어떤 종류의 IPC?
- 디스커버리: 서비스 ip주소를 어떻게 가져오는지?
- 신뢰성: 서비스 불능 시 서비스 간 통신의 신뢰성은 어떻게 보장?
- 트랜잭셔널 메시징: 비즈니스 데이터를 업데이트하는 DB 트랜잭션에 메서지를 송신하고 이벤트를 발행하는 행위를 어떻게 통합?
- 외부 API: 애플리케이션 클라이언트는 서비스와 어떻게 통신?
트랜잭션 관리를 위한 데이터 일관성 패턴
사가 패턴 어쩌구
데이터 쿼리 패턴
- API 조합 패턴
- CQRS: 하나 이상의 데이터 레플리카를 유지해서 쉽게 쿼리
관측성 패턴: 애플리케이션 동작 파악
관측 가능한 서비스를 설계하려면 다음과 같은 패턴 필요
- 헬스 체크
- 로그 수집
- 분산 추적
- 예외 추적
- 애플리케이션 지표
- 감사 로깅
서비스 테스트 자동화 패턴
서로 다른 여러 서비스가 조화롭게 잘 작동되는지 테스트하는 일이 중요, end to end test 는 피하는 것이 상책
- 컨슈머 주도 계약 테스트: 클라이언트가 의도한 대로 서비스가 동작하는지
- 컨슈머 쪽 계약 테스트: 클라-서비스 상호 통신 가능한지 확인
- 서비스 컴포넌트 테스트: 서비스 따로 테스트
흠..냐
횡단 관심사 처리 패턴
DB 자격증명 같은 구성 매개변수를 런타임 서비스에 제공하는 외부화 구성 패턴 적용 필요 -> 섀시 패턴을 이용해 횡단 관심사 처리
보안 패턴
api 게이트웨이가 사용자 정보 인증 후 호출할 서비스에 관련 정보 전달함
가장 일반적인건 jwt와 같은 엑세스 토큰 패턴을 적용하는 것!
💻 ☕️ 🏝 🍑 🍹 🏊♀️