모놀리식

• 작은 크기에서 용이
• 규모 크면 불리한점이 많다
  • 결합도가 높다
  1. 특정 컴포넌트의 오류가 다른 컴포넌트에 영향을 미칠 가능성이 높아짐
  2. 시스템 구조 커질수록 이해하기가 어려워짐
  3. 컴포넌트 하나 수정해도 재 배포시 전체 애플리케이션 재 컴파일해야함
     1. 잦은 배포해야하는 경우 매우 느림
  4. 차후 IO작업이 많은 컴포넌트를 개발해야할 때 node js를 사용하는 것이 유리할 수 있으나 자바로 개발되어 다른 기술 집어넣기 매우 힘들어짐

MSA

• SOA에 근간을 두고 있음
• 각 컴포넌트를 “서비스”라는 개념으로 정의
• 데이터, 비즈니스 로직까지 독립저그로 상호 컴포넌트 간 의존성 없이 개발된 컴포넌트를 가지고 REST API와 같은 인터페이스로 그 기능을 외부로 제공
• 배포관점에서 변경된 컴포넌트 파트만 재배포를 하면 됨
• 로드밸런서를 활용해 서비스간의 로드를 분산시킴
• 데이터베이스까지 분리함
  • 샤딩
  • 이렇게 하면 조인을 못하니 다른 방식으로 해야함
  • 반정규화 데이터베이스를 가져다 놓던가 아니면 따로따로 가져오던가

API gateway

• MSA 아키텍쳐에서 많이 언급되는 컴포넌트
• 프록시 서버처럼 api 앞에서 모든 api에 대한 end point를 통합하고, 몇가지 추가적인 기능을 제공
• SOA의 ESB 경량화 버전

기능

1. Endpoint 통합, 토폴로지 정리

• MSA는 각 서비스가 다른 서버에 분리 배포되므로 API의 endpoint. 즉, 서버의 URL이 각각 다름
  • 사용자 경험 관점에서도 사용하기가 불편해짐
  • MSA는 서비스를 잘게 쪼개기때문에 서버의 URL이 다 달라질 것
• 향후 토폴로지가 매우 복잡해지고 거미줄 모양의 서비스 컴포넌트간의 호출 구조는 향후 관리의 문제를 일으킬 수 있다
• API gateway를 사용해 서비스 버스와 같은 역할을 하는 채널을 배치시켜 전체 토폴로지를 p2p가 아닌 hub & spoke 방식으로 변환