MSA

• 패턴: 문제를 해결하기 위한 제시 -> 구현할 때 필요한 해결 방법(프록시로 할 것인지, 빌더로 할 것인지 에 대한 디자인 패턴과 같은..)

• 스타일 : 그 문제에 접근하기 위한 방법 -> 아키텍쳐가 바라보는 관점

• MSA 아키텍처는 패턴(코딩)이 아닌 스타일이다.

• MSA : Micro Software 'Architecture' 이기 때문에 스타일을 얘기한다. -> 코딩영역 아님

• MSA를 공부했다? 코딩은 일부분이고 코딩을 하기 위해 전체적인 구조를 어떻게 만들 수 있는가의 능력이다.

모놀릭에서 마이크로로 변화하는 이유

• 모놀리스 아키텍처란 모든 업무 로직이 하나의 애플리케이션 형태로 패키지 되어 서비스되고, 데이터 또한 한곳에 모인 데이터를 참조하여 서비스하는 것이 일반적
• 클라이언트 요청에 대한 처리 반응 속도가 중요한 요소인데 이에 치명적이다. 또한 데이터 조회에 대한 부하나 이를 처리하는 앱에 문제가 생기면, 이에 대응하기 위해 로드밸런서, 2중화 3중화 백업 및 복구방안이 아주 중요한 아키텍처 결정사항이다.
• 시스템이 받을 부하를 사전에 분석, 예측하는 하드웨어 스케일업 과정과 애플리케이션의 빠른 대응과 데이터 조회의 성능을 개선하기 위한 튜닝 활동 등이 아키텍트의 주요한 관심사였다.
• 한 애플리케이션만 수정하려 해도 관련없는 단일 애플리케이션 100개가 빌드되어 다시 배포돼야 할 수 있다. -> 변화에 대한 민첩한 대응이 부적합한 구조이다.

MSA?

• 하나의 애플리케이션이 아닌 기능이랑 데이터까지 분리하여 격리된 독립환경으로 구성하는 것이 가장 큰 차이점이다.
  
  
• EC2가 PaaS 환경, 우리는 애플리케이션 & 데이터만 만들면 된다.

↳ 회로차단하는 서킷브레이커 처럼 클라이언트가 msa서비스를 요청하면 안쪽에서 db와 일하느라 딜레이가 너무 많이됨 -> 오래걸림 -> 경우에 따라서는 비동기 요청을 한다.
일반적으로는 요청보내고 응답이 올때까지 서비스 사용자는 기다림
-> 이러지말고 요청을 비동기로 보내놓고 자기할일을 서비스 사용자가 함
-> ajax 요청하듯 비동기 요청을 할 수 있음
-> 응답이 오면 받아옴 (비동기 요청과 관련된 시스템을 사용해야함. 대표, 카프카 메시지 서버)
-> 카프카 메시지 서버에 비동기 요청을 하고 응답된 내용은 카프카 서버에 쌓아놓음 -> 사용자에게 응답왔다고 알려줌 -> 사용자입장에서는 메시지 서버에게 데이터를 보내는 일만 하면 알아서 결과응답을 받아왔을 때 보내줌 (메시지 큐 토픽)

그럼 언제 동기요청? 비동기 요청? 해야할까

• 조회 (그 즉시 데이터를 가져와서 보여줌) : 주로 동기 요청을 한다. (DDL)
• 자료를 추가, 수정, 삭제 : 주로 비동기 요청 (DML)
  • 응답이 실패됐을 경우에도 메시지 서버에 쌓여서 사용자에게 알려줌

클라우드 네이티브 인프라

• 클라우드 환경에 적합한 인프라로는 컨테이너로 패키지 된 단위가 실행단위이다.
• 즉, 컨테이너 단위로 독립적인 인터페이스와 물리적으로 접속이 가능한 IP와 port를 가진다.(웹서버)
  • 컨테이너 단위로 웹서버도 제공, 서비스도 제공돼야 한다.
  • 웹서버 + 서비스 = 컨테이너, 웹서버와 서비스를 한데 압축시켜서 배포해야함.
    
• 스프링 부트를 보면, SpringWebMvc프로젝트-jar, 서비스, 내장 톰캣서버를 압축해서 스프링이아닌 스프링부트로 압축파일하여 MSA로 배포 하는 목적이 그 안에 내장돼있는 톰캣서버가 있기 때문에 (스프링에는 내장 서버 없음) 컨테이너 사이에서
  서로 데이터를 주고 받을 수 있는 요청이 또다른 애플리케이션에서 일어난것이기 때문에 웹 서버한쪽의 서비스 에서 응답을 html형태로 하면 안됨.
• 응답된 내용을 해석하려면 json으로 해야함 -> json이 익숙해져야하는 이유는 스프링부트 뿐만 아니라 msa도 기획하는 능력이 있어야하는데 그러면 응답,요청에 대해 알아야하는데 다른 서비스에서 이해할 수 있는 형태 즉 json으로 해야한다.
• 요청을 할 때도 마찬가지. 요청이 심플해야함. ajax요청이 아니라 js해석기가 있어야 ajax를 해석할 수 있는데 서비스간의 요청은 웹브라우저(렌더링엔진, js해석기가 있음)가 없는 상태에서 하는 요청이기 때문에 단순화된 요청이여야 한다. 이 단순한 요청에 모든 정보가 들어가야함
  • 요청의 의도(추가, 수정 등의 기능)가 무엇인지, URI(자원지정) ➡︎➡︎ RESTFUL 형태로 해야함 -> ajax로 데이터를 보내는 것이 아니라 URI를 적극 활용
    ➡︎➡︎➡︎➡︎ 왜 JSON을 사용해야하는지가 이렇게 나온다.!!!!!!
• MSA를 안하면 굳이 Restful을 사용하지 않아도 되지만, 위와 같이 간단한 요청을 하기 위해서는 Restful을 사용해야 한다.
• 내장된 톰캣서버를 이용하면 간단하게 컨테이너를 관리할 수 있기 때문에 사용하는 것이다.

• MSA에는 UML이 적절하지 않음 -> 이벤트 스토밍이 더 적절함

• 서비스들간 호출 시 지연이 될때 '지연중입니다' 라는 메시지를 띄우는 것 과 같은 것이 서킷브레이커. 가장 많이 마주친다.
  -> hystrix, resilience4j 라이브러리 사용

• 라이브러리를 이용해서 적용할 기술이 무엇인지가 중요
• 서킷브레이커(기술) : 서비스가 유연하게 동작할 수 있도록 도와줌 (서비스 지연, 에러가 전파되는 문제 등) ➡︎ 다른건 몰라도 MSA에서 서킷브레이커는 무조건 필수!