위 내용은 마이크로 서비스 패턴을 기반으로 개인공부용으로 작성하였습니다.
[0. 모놀로식-> 마이크로]
- 모놀로식 육각형 계층적
• 표현(프레젠테이션) 계층(presentation layer): 사용자 인터페이스 또는
외부 API가 구현된 계층
• 비즈니스 로직 계층(business logic layer): 비즈니스 로직이 구현된 계층
• 영속화(퍼시스턴스) 계층(persistence layer): DB 상호 작용 로직이 구현
된 계층
- 마이크로 서비스 아키텍처
[1.마이크로 서비스 설계 및 분해방법]
마이크로 서비스를 분해하는 방법은 크게 3가지 방식으로 나뉜다.
1.시스템 작업 식별: 애플리케이션이 처리하는 핵심요청을 분석하여 추상화시킨다. 예를들면 주문 ,주문허가 등이있다.
2.서비스 식별: 요청에 따른 기능 구현에 앞서 어떻게 서비스를 분해할지 결정.
예를들면 주문서비스,배달서비스,음식점 서비스,배달 서비스이 있다.
3.서비스별 Api정의: 먼저 시스템작업별 서비스 배정후, API구현 그리고 IPC(프로세스간 통신)을 정해야 한다.
- 1.1 시스템 작업 식별
애플리케이션이 어떤 핵심요청을 처리할지 고민하는 단계이다. 핵심 요청에 대해 분석하고 이를 추상화시킨다. 이때 이에따른 고수준 도메인 모델을 생성시킨다.
1.1 도메인 설계과정
예를들어 주문하기 스토리는 다음과 같다.
전제(given):
- 소비자가 있다.
- 음식점이 있다.
- 음식점은 소비자의 주소로 제시간에 음식을 배달할 수 있다.
조건(when):
- 소비자가 음식을 주문한다.
결과(then):
- 소비자 신용카드가 승인된다.
- 주문이 PENDING_ACCEPTANCE 상태로 생성된다.
- 생성된 주문이 소비자와 연관된다.
- 생성된 주문이 음식점과 연관된다.
이 시나리오를 보고 도메인을 분석한다면 소비자,주문,음식점,신용카드와 같은 클래스들이 필요하다. 주문 접수에 해당하는 스토리는 다음과 같다.
전제(Given):
- 현재 주문은 PENDING_ACCEPTANCE 상태다.
- 주문 배달 가능한 배달원이 있다.
조건(When):
- 주문을 접수한 음식점은 언제까지 음식을 준비할 수 있다고 약속
한다.결과(Then):
- 주문 상태가 ACCEPTED로 변경된다.
- 주문의 promiseByTime 값을 음식점이 준비하기로 약속한 시간으
로 업데이트한다.- 주문을 배달할 배달원을 배정한다.
주문 접수의 경우 배달원,배달 클래스가 필요하다.이를 기반으로 분석해보면 총 도메인은 다음과 같다.
1.2 요청에 따른 시스템 작업의 종류
- 커맨드:데이터 생성,수정,삭제(CUD)
- 쿼리:쿼리: 데이터 읽기(R)
예를들어 주문하기에 따른 시나리오는 다음과 같다.
- 사용자는 배달 주소 및 시간을 입력합니다.
- 시스템은 배달 가능한 음식점을 표시합니다.
- 사용자는 음식점을 고릅니다.
- 시스템은 메뉴를 표시합니다.
- 사용자는 원하는 메뉴를 선택한 후 체크아웃합니다.
- 시스템은 주문을 생성합니다.
이에 필요한 쿼리는 다음과 같다.• findAvailableRestaurants(deliveryAddress, deliveryTime): 주어진 장소/시간으로 배달 가능한 음식점 목록을 조회합니다. • findRestaurantMenu(id): 메뉴 항목 등 음식점 정보를 조회합니 다.이때 findAvailableRestaurants의 경우에 지리검색과 더 복잡한 쿼리를 실행하므로 아키텍처 관점에서는 중요하다. 또한 주문시마다 실행되므로 성능에 신경써야한다.
- 1.2 서비스 식별
요청에 따른 기능구현에 앞서 어떻게 여러 서비스로 분해할지 결정해야하는데 중요한것은 비즈니스 능력 패턴별 분해이다. 비즈니스 능력 명세는 입력, 출
력, SLA 등 다양한 컴포넌트로 구성됩니다. 일반적으로 특정 비즈니스 객체에 집중하며 여러개의 하위 비즈니스 능력으로 분해할 수 있습니다.
예를들면 다음과 같습니다.
- 공급 관리
- 배달원 관리: 배달정보 관리
- 음식점 정보 관리: 음식점 메뉴,위치,영업 시간,기타 정보 관리
- 소비자 관리
- 소비자 개인정보 관리
- 주문 접수 이행
- 주문 관리: 소비자 주문을 생성,/관리할 수 있게 관리한다.
- 각 음식점별 주문관리: 음식점의 주문 준비 상태를 관리
- 로지스틱스(실행계획)
- 배달원 가용성 관리: 배달원이 배달가능한지 실시간 관리
- 회계
- 소비자 회계: 소비자 과금 관리
- 음식점 회계: 음식점 지불 관리
- 배달원 회계: 배달원 지불 관리
최상위 비즈니스 능력은 공급자 관리, 소비자 관리, 주문 접수 및 이행 등등입니다. 이들을 위와 같이 하위 비즈니스능력으로 나눌 수 있다. 이제 이들을 몇개의 서비스로 나뉠지 생각해보면 다음과 같다.
1. 공급관리
배달원관리와 음식점 정보 관리는 완전 다른 성격의 공급자이므로 두개의 별도의 서비스로 매핑한다.
2. 주문 접수 이행
주문 접수 이행의 경우 세개의 독립적 서비스로 나뉘었다.
1. 소비자별 주문관리
2. 음식점별 주문관리
3. 배달원 가용성관리: 이때 배달원 가용성 관리와 1.공급관리에서의 배달원 관리능력은 밀접한 관계가 있으므로 한 서비스로 묶었다.3. 회계 능력
유형별 회계가 대동소이하기 때문에 자체 서비스에 매핑했습니다.
이를 요약하면 다음과 같다.
- 1.3 서비스별 Api정의
먼저 시스템작업별 서비스 배정후, API구현 그리고 IPC(프로세스간 통신)을 정해야 한다. 서비스별 Api는 외부클라이언트 및 타 서비스 호출하는 시스템 작업과 프로그램 내에서 IPC로 서비스 호출 전용으로 사용할 Api로 두개입니다.
[2.서비스 분해의 장애물]
비즈니스 능력과 하위 도메인별로 서비스를 정의해서 마이크로서비스
아키텍처를 구축하는 전략은 그다지 어려울 것 같지 않아 보이지만, 막
상 시도해 보면 장애 요소가 많습니다.
• 네트워크 지연
해결방안: 여러 객체를 한번게 가져오는 배치 API구현 또는 값비싼 IPC를 사용
• 동기 IPC통신으로 인한 가용성 저하
해결방안: 비동기 메시징으로 강한결합도 제거
• 여러 서비스에 걸쳐 데이터 일관성 유지
해결방안: 원자적으로(atomically) 업데이트가 일어나야한다.
메시징을 이용한 일련의 로컬 트랜잭션 사용. 원자적으로 업데이트해야 함으로 데이터를 하나의 서비스 내부에 두다보니 분해의 걸림돌이 된다.
일관된 데이터 뷰 확보의 어려움
예를들어 마이크로 서비스 아키텍쳐의 경우 각 서비스다 각 데이터 뷰를 가지고 관리한다. 하지만 여러 트랜잭션별 상호작용을 할때(ex 주문과-배달서비스) 배달서비스 내에서 주문과 관련된 데이터를 가지고 있어야 하는 상황이 발생하고 이때, 이것이 변경된 데이터일 수 있는 문제가 발생한다. 하지만 이를 위해 배달서비스 내부에 주문에 관련된 데이터 뷰를 확보하게 된다면 분해의 걸림돌이 된다.
하지만 이것이 거의 문제가 발생하지 않는다.
• 분해를 저해하는 만능 클래스
만능 클래스: 여러 클래스,서비스들이 연관되어있는 클래스이다.
위를 보면 Order은 Address, Courier,Consumer,Restaurant,PaymentInfo등등과 연관 되어있다.
해결방안: DDD모델 적용
Order에 포함된 각서비스를 자체 도메인 모델을 갖고 있는 개별 하위 도메인으로 취급. 주문과 조금이라도 연관된 서비스는 모두 각자 버전의 클래스를 가진 도메인 모델을 따로 둔다.
예를들어 Order에 포함된 Delivery의 경우 따로 하위 도메인을 설계후 다음과 같은 서비스만 담당하도록 나눈다.
주문서비의 경우는 제일 복잡하지만 이전과 비교했을때 단순해짐을 확인할 수 있다.
