MSA란?

시스템을 여러개의 독립된 서비스로 나눠서, 이 서비스를 조합함으로서 기능을 제공하는 아키텍쳐 디자인 패턴
ex. 넷플릭스, 트위터, 아마존 등등

AMAZON에서 시작된 MSA ( 제프 베조스, 아마존의 CEO )

• 모든 팀들은 데이터와 기능들을 서비스 인터페이스로 연결해라
  팀들은 인터페이스로만 연락해야한다
• 다른 어떤 커뮤니케이션 방법도 안된다. 직접링크를 보내거나 다른 팀의 스토리지에 직접 엑세스 하는건 안된다. 공유메모리, 백도어도 안된다.
• 어떤 기술을 쓰든 상관없다. HTTP, Cobra, Pubsub, 독자 프로토콜... 그건 상관없다
• 모든 서비스 엔터페이스는 예외없이 외부에서 이용가능하게 만들어져야 한다. 외부 개발자들이 인터페이스를 이용할 수 있게 해야한다
  ( MSA의 가장 본질적인 부분... )

2006년 아마존 웹 서비스(AWS) 릴리즈 - 내부에서 사용한 것과 똑같은 플랫폼

넷플리스조차 AWS를..

• 2008년 데이터 베이스에 문제 발생 ( DVD를 고객에게 보낼 수 없음 )
• scale-up 확장만 가능한 인프라 스트럭쳐와 단일 장애지점 (SPOF)이라는 한계에서 벗어나길 선언
• 그 시작은 아파치 카산드라 데이터베이스
  2009년 AWS로 이관 시작
• 확장성(Scalability), 성능(Performance), 가용성(Availability) 세가지 목표에 집중
  '자체 보유 인프라와 솔루션으로는 이렇게 급증한 트래픽을 감당할 수 있는 확장성을 확보할 수 없었을 것'

MSA의 공통점

MSA는 공식적인 정의는 없다.
단지 다음과 같은 공감대가 있다

• 각 서비스간 Network를 통해 (보통 HTTP)
• 독립된 배포 단위
• 각 서비스는 쉽게 교체 가능
• 각 서비스는 기능중심으로 구성됨 ( ex. 프론트 엔드, 추천, 정산, 상품 등 )
• 각 서비스에 적합한 프로그래밍 언어, 데이터 베이스, 환경 으로 만들어짐 ( 만들어져도 상관 없음 )
• 서비스는 크기가 작고, 상황에따라 경계를 정하고, 자율적으로 개발되고, 독립적으로 배포되고, 분산되고, 자동화 된 프로세스로 구축되고 배포된다
• 마이크로 서비스는 한 팀에 개발할 수 있는 크기가 상한선

마이크로 서비스는 아직까지 아이디어 수준에서 크게 벗어나 있지 않다. 다양한 산업 분야에서 폭넓게 적용되고 있지만 그것이 좋은지 나쁜지 시간이 더 지나봐야 알 수 있다
_ 조쉬 롱, 케니 바스타니, 피보탈

monolithic에서 MSA로

• 각 MS별로 DB를 가짐 (공유되는 상태가 없음) - DB를 분리해야한다는 의미
• REST API인터페이스 외엔 호출할 방법이 없음
  

실습 ( 인텔리J ) - 공부필요

@RestController -> 스프링부트의 문법인가/ java의 문법인가... 무엇을 의미하는가 < annotation ????
@RestTemplate가 뭔지 알아보자
@Autowired ? final -> alt+enter -> add constructor parameter ? 뭐가 기능은 같은데 다르나보다
dependency injection??
ctrl + shift + A : action 검색기능
-> implement interface ( 인터페이스는 이걸 해서 impl머시기를 만들고 거기서 써야하나바... 아, 함수를 정의하는 파트를 따로 만드는건가? 아 그런갑다 )
-> constant 어쩌고 => 해당 값을 const 변수로 선언해주는 기능

DB 분리..? - 공부필요

• DB는 정말 분리하기 힘들다. 따라서 큰 DB를 각 MS로 분리하는게 사실 제일 어렵다 ( 이벤트 드리븐, 분산 트레젝션 등등 ... )