[microservice patterns] 2. 아키텍처의 중요성, 애플리케이션의 서비스단위 분해 패턴, 분해과정에서 마주치는 문제의 솔루션

서술 방식

def + history + example

 

목차

[microservice patterns]

1. 모놀리식 지옥의 징후, 마이크로서비스 아키텍처를 도입해서 탈출하기 + 마이크로서비스 아키텍처 패턴 언어란?

2. 아키텍처의 중요성, 애플리케이션의 서비스단위 분해 패턴, 분해과정에서 마주치는 문제의 솔루션

3. 메세지 기반 비동기 통신  - 서비스간 통신을 위한 최적 패턴

4. 사가 패턴  - 데이터 일관성 유지 방법

5. DDD의 aggregate 및 도메인 이벤트 패턴  - 서비스 비즈니스 로직 설계

-  DDD : 도메인 주도 설계

6. 이벤트 소싱 패턴 - 비즈니스 로직 개발

7. API 조합 패턴, CQRS 패턴 - 분산 데이터 조회 쿼리

- CQRS(커맨드 쿼리 책임 분산)

8. 외부 API 패턴 - 외부 클라이언트 요청 처리

9 ~ 10. 자동화 테스트 - 테스트 피라미드, 단위테스트, 통합테스트, 컨슈머 주도 계약 테스트, 컴포넌트 테스트

11. 프로덕션 레디 서비스 개발 - 보안, 외부화 구성  패턴, 서비스 관측성 패턴(로그수집, 애플리케이션 지표, 분산추적)

12. 서비스 배포 패턴 - 가상머신, 컨테이너, 서버리스,  서비스 메시

13. 스트랭글러 애플리케이션 패턴 - 모놀리식 -> microservice 마이그레이션

 

---

 

1. SW의 품질속성은 Architecture에 의해 결정된다 : 확장성,신뢰성 보안 -> + 관리성,테스트성,배포성

 

2. SW Architecture 정의

- 시스템은 sw element + property  & relationship + property 로 구성되어 있고, 이를 추론하는데 필요한 structure의 집합이 SW Architecture.

 

3. element & relationship 분해의 중요성 : 업무(labor)와 지식(knowledge)를 분리한다.

 

4. 4+1 View 모델

- 논리뷰(logical view) :

  -- element = class, package

  -- relationship(클래스 & 패키지의 관계) = inheritance, association, depends-on..

- 구현뷰(implementation view) :

-- element = 빌드 결과물, War/jar 파일

-- relationship = dependancy & component 조합 관계

- 프로세스뷰(process view)

-- element = runtime component, element

-- relationshiop = IPC

- 배포뷰(deployment view)

 -- element = machine, process

 -- machine 간 관계

 

5. 뷰 구동 시나리오

-- 각 뷰에서 element가 협동하여 요청 "처리하는 방법"을 기술

 

6. 아키텍처 스타일 : element & relation(connector) 의 한정된 palette를 제공.

 

- 계층화 아키텍처 스타일

 --- 3계층 아키텍쳐 : 계층화 아키텍처 스타일의 논리뷰

 --- presentation 계층

 --- business logic 계층

 --- persistence 계층

 단점: 표현 계층이 하나, 영속화 계층 하나, 비즈니스 로직이 영속화에 의존(DB 필수) 

 

- 육각형 아키텍처 스타일 : 비즈니스 로직의 독립성

 -- 표현계층 (어댑터 층) : 비즈니스 로직에 의존

   --- 인바운드 : 외부 요청을 인바운드 포트를 호출해서 처리

   --- 아웃바운드 : 내부 요청(비즈니스 로직 요청)을 외부 서비스를 호출해서 처리.

 

 -- 비즈니스 로직 : 포트 내장

   --- 인바운드 : 외부 애플리케이션이 비즈니스 로직 호출하기 위한 포트

   --- 아웃바운드 : 비즈니스 로직이 외부 시스템 호출하기 위한 포트

 

- 마이크로 서비스 아키텍처 스타일 :

구현 뷰를 다수의 컴포넌트로 구성한다. : 서비스 구현 뷰는 standardalone process, 컨테이너 내부 web app, osgi bundle, serverless cloud등 다양하게 가능.

 

핵심 제약조건은 서비스를 느슨하게 결합한다.

각 아키텍처는 육각형 아키텍처 형태를 취한다.

 

 

- 서비스 = 단독 배포가 가능한 SWC

- 서비스 API = 내부 구현 상세를 캡슐화.

 

- loosen coupled

-- 서비스는 API를 통해서만 상호작용

-> client에 영향을 끼치지 않고 내부 구현코드 변경

-> DB에 직접 통신 불가

-> 서비스의 영속적 데이터는 반드시 private

-> 서비스간 db 공유가 없으므로 runtime isolation 향상 -> 일관성 처리가 가장 난제.