Micro Service Architecture - 3.패턴

패턴은

패턴은 특정 상황에 발생한 문제에 재사용 가능한 해법이며 실제로 검증된 유용한 생각입니다.

패턴은 어떤 상황에서는 유용하지만, 또 어떤 상황에서는 전혀 유용하지 않을 수 있습니다. 또 기술적인 부분이 강제되는 점도 있습니다.

• 강제 조항 (Forces)

  문제 해결을 위해서 강제로 처리해야 할 이슈들에 대해서 우선순위를 정하는 것.
  예를들어 코드를 이해하기 쉬우며 성능도 우수해야 한다면 리액티브 스타일 코드는 성능은 우수할지 모르지만 이해햐기 어렵습니다. 따라서 이는 전에 반드시 해결 되고 진행 되어야 함.
  (리액티브 스타일 : 함수형 언어나 엑셀등에서 사용, 자세한 것은 구글링)

• 결과 맥락 (Resulting Context)

  패턴 적용 결과 장점과 단점, 이후 새로운 문제에 대해 고려 필요

• 연관 패턴 (Realted Patterns)

  선행자 : 이 패턴을 필요하게 만든 선행 패턴, 가령 MSA 패턴은 나머지 패턴들의 선행 패턴
  

후행자 : 이 패턴으로 야기된 이슈를 해결하기 위한 후행 패턴, 가령 MSA 패턴 적용시 서비스 디스커버리 패턴, 회로 차단기 패턴 등이 후행자 패턴

대안 : 대체 패턴으로 모놀리식과 MSA 는 서로 대안 패턴이다.

일반화 : 문제를 해겨라는 일반적 패턴

세분화 : 특정 패턴을 세부적으로 나다낸 형태

![3-1](https://raw.githubusercontent.com/sanggi-wjg/micro_service_pattern_study/main/data/3-1.PNG)
* 인프라 패턴

주로 개발 영역 밖의 인프라 문제를 해결

* 애플리케이션 인프라 패턴 

개발에도 영향을 미치는 문제를 해결

* 애플리케이션 패턴 

개발의 문제를 해결

* 통신 패턴

MSA 애플리케이션은 기본적으로 분산 시스템이여서 통신이 매우 중요하다.
서비스 상호 간, 외부와 어떻게 통신을 할 것인지 다양한 결정을 해야 하며 크게 다섯 그룹으로 정리 된다.

1. 통신 스타일 : 어떤 종류의 IPC를 사용 하는가?
2. 디스커버리 : 서비스 Client는 Server 의 IP를 어떻게 가져오는가?
3. 신뢰성 : 서비스 불능 시 서비스 간 통신의 신뢰성은 어떻게 보장 되는가?
4. 트랜잭션널 메시지 : 비지니스 데이터를 수정하는 DB 트랜잭션의 메시지를 송신하고 이벤트 발행하는 행위를 어떻게 통합 할 것인가?
5. 외부 API : 외부 서비스와 어떻게 통신할 것인가?

   ![3-2](https://raw.githubusercontent.com/sanggi-wjg/micro_service_pattern_study/main/data/3-2.PNG)
   
   

#

MSA에서 사용되는 패턴

Saga 일관성 관리

MSA는 각자 DB를 갖고 있는 느슨한 결합 입니다. 따라서 Saga pattern 으로 데이터 일관성을 유지해야 합니다.

쿼리 패턴

서비스마다 DB를 가지고 있다면 데이터 조인에도 문제가 생기는데 이는 아래 두가지 패턴을 응용해 구현 합니다.

• API 조합
  API 조합 패턴은 하나 이상의 서비스를 호출해서 결과를 결합
• CQRS (Command Query Responsiblity Segregation, 커맨드 쿼리 책임 분리)
  CQRS는 하나이상의 데이터 레플리카를 유지해서 쉽게 커리하는 방법

관측성 패턴

MSA는 요청결과가 클라이언트에 반환 되기까지 어떤 서비스를 오갈지 파악이 힘들기 때문에 로그 파일로만으로는 문제의 원인을 찾고 해결하기가 힘들다.
따라서 관측 가능한 서비스를 설계를 할 필요가 있다.

• 헬스 체크
  서비스 가동 상태를 반환
• 로그 수집
  서비스 내역을 기록하고 중앙 로깅 서버에 로그를 출력하여 검색/경고 기능을 제공
• 분산 추적
  각 외부 요청마다 ID를 부여하여 추적 기능 부여
• 예외 추적
  예외 발생시 개발자에게 경고를 보내거나 추적 가능한 정보를 보냄
• 애플리케이션 지표
  카운터, 게이지 등의 지표를 측정하여 표출
• 감사 로깅
  사용자의 액션을 기록

서비스 테스트 자동화 패턴

MSA는 서비스들이 서로 잘 작동하는지 테스트하는 것이 중요하다.

• Consumer-driven Contract Test (컨슈머 주도 계약 테스트)
  클라이언트가 의도한 대로 동작 하는지
• Consumer-side Contract Test (컨슈머 쪽 계약 테스트)
  클라이언트와 서비스가 상호 통신 가능한지
• Service Component Test (서비스 컴포넌트 테스트)
  서비스별 테스트

횡단(공통) 관심사 처리 패턴

DB 증명(Credential) 같은 구성 매개변수를 런타임 서비스에 제공하는 외부화 구성 패턴을 적용 해야한다. 신규 서비스 구축시 횡단 관심사를 구현하기에는 시간이 오래 걸리기 때문에 마이크로서비스 섀시 패턴을 적용 하는 것이 좋다.

보안 패턴

API 게이트 웨이에서 사용자 정보를 인증한 후 서비스를 호출하는데 일반적으로
JWT(Json Web Token) 같은 Access Token을 적용 한다.