[마이크로서비스패턴] 2. 분해 전략
애플리케이션 요건
- 애플리케이션이 할 일을 정의한 기능 요건이다. 보통 유스 케이스, 유저 스토리로 정의한다.
- ~성으로 끝나는 서비스 품질 요건. 확장성, 신뢰성같은 런타임 품질 외에도 관리성, 테스트성, 배포성처럼 개발 시점 품질도 해당됩니다.
계층형 아키텍쳐
계층형 아키텍쳐는 전형적인 아키텍쳐 스타일로 명확히 정의된 역할을 분담하여 계층 간 의존성은 아키텍처로 제한한다.
육각형 아키텍처 스타일
애플리케이션 표현 계층 대신 로직을 호출해 외부 요청을 처리하는 어댑터와 영속화 계층 대신 로직에 의해 호출되고 호출하는 아웃바운드 어댑터를 둔다. 핵심은 로직이 어댑터를 의존하지 않는 점이다.
느슨한 결합
느슨하게 결합된 서비스는 마이크로서비스의 주요 특성이다.
유지보수성, 테스트성을 높이고 애플리케이션 개발 시간을 단축하는 효과가 있다. 서비스가 DB 테이블을 공유하지 않기에 런타임 격리성도 높아진다.
공유 라이브러리
바뀔 일이 전혀 없는 기능은 공유 라이브러리에 담아 사용하면 좋다. 그러나 변경 가능성이 조금이라도 있으면 별도의 서비스로 구현하는 것이 낫다.
애플리케이션 아키텍처를 정의하는 방법
3가지 프로세스로 정의한다.
첫번째는 애플리케이션 요건을 핵심 요청으로 추출하는 것이다.
두번째는 여러 서비스로 어떻게 분해할지 결정한다.
세번째는 서비스별로 API를 정의하는 일이다.
분해 과정은 여러 장애들을 생각해야 한다.
첫째 네트워크 지연
둘째 서비스 간 동기적 통신으로 가용성이 떨어지는 문제
세번째 여러 서비스의 일관성을 지키는 사항이다.
시스템 작업 식별
시스템 작업을 기술하기 위해 용어를 제공하는 핵심 클래스로 구성된 고수준 도메인 모델을 생성하고, 동작을 도메인 관점에서 기술하는 것이다.
createOrder()의 작업 명세
1. 작업: createOrder
2. 반환값: orderId
3. 선행조건: 소비자가 있고 주문할 수 있다. 주문 품목은 메뉴항복에 있다. 배달 주소/시각은 음식점에서 서비스할 수 있다.
4. 후행조건: 소비자 신용카드로 주문 금액만큼 승인 처리되었다. 주문 상태가 PENDING_ACEEPTANCE 상태로 생성된다.
DDD로 분해하는 방법
도메인 분해를 위해 단일 책임 원칙과 공동 폐쇄 원칙을 지켜야 한다.
단일 책임 원칙은 클래스는 오직 하나의 변경 사유를 가져야 한다.
공동 폐쇄 원칙은 동일한 유형 변경에 닫혀 있어야 한다.
서비스 분해의 장애물
- 네트워크 지연
- 동기 IPC로 가용성 저하 - 비동기 메시징으로 결합도 제거하고 가용성을 높인다.
- 데이터 일관성 유지 - 최종적 일관성만을 보장한다. 원자적으로 업데이트해야 하는 방법은 분해의 걸림돌이 된다.
- 일관된 데이터 뷰 확보
- 만능 클래스의 존재 - 공통 라이브러리는 존재만으로도 분해의 걸림돌이다.
서비스 정의
시스템 작업을 서비스로 배정
서비스 간 필요한 API 확정