https://okky.kr/article/1229709
Why MSA?
- 특정 트래픽이 몰리는 service만 scale out하기 용이
- 부분적인 변화에 용이(그 부분만 재배포)
- 레거시 개선에 용이(점진적으로 적용하면 되니까)
- 스타트업 등에서 부분부분 작게 출시 가능
- 실패 비용도 적을 수 있음(한 서비스당)
- 기술 선택에 제약이 없음(polyglot 가능)
MSA의 단점
- Transaction 처리의 어려움
- 데이터의 안정성, 신뢰성이 최우선인 곳은 적용이 어려울 수 있음 - 러닝 커브
- 이해도(나중에 다른 사람이 업무 로직 따라가볼 때 등)
- 테스트 및 모니터링의 어려움
MSA Pattern
DB 관련
- CQRS : view 테이블 활용...
- Saga : vuex 느낌(transaction을 별도 관리)
- Shared : 통합 DB
API Gateway 관련
- Server Side : Router 필요. Scale-out 매커니즘 필요
- Client Side : Registry한테 사용 가능한 Instance를 쿼리로 질의
- Circuit breaker : 한 인스턴스에서 응답이 없을 경우, 그 연결을 끊어 다른 인스턴스에서 에러 처리할 수 있도록 하는..?
- BFF(Backend For Frontend) : api와 ui 사이를 mapping해주는 역할..?
MSA 적용 경험
- 도메인 관점에서 비즈니스 로직 구분(포스트잇으로 워크샵까지 해가면서 ㄷㄷ)
- Actor, 데이터, 숨겨진 이벤트 등 여러 관점에서 한 번 더 구분
- 관리자 서비스는 Monolithic & 모든 DB 접근 권한
- 외부 통신만 담당하는 서비스 배치
- 리스크가 큰 프로세스(계약 & 결제 등)는 하나의 Service로 묶어 Transaction 처리
기타
istio
Fault Injection을 통해 실제 환경 기반 장애 대응 테스트에 용이
토이 프로젝트
기능 구현보다는 전체 아키텍쳐 및 통신 등의 패턴 학습에 중점을 둘 것
낯선 용어들
- event sourcing, event storming
- service mesh : https://bcho.tistory.com/1292
- spring cloud gateway
- envoy proxy
- akamai : 웹 캐싱 서비스를 제공하는 B2B 솔루션 회사
- sonar qube
- [모니터링] elk, kiali, prometheus, grafana
- mini service(hybrid service?)
