📓 Monolithic VS MSA
🏷️ Monolithic
모든 도메인, 비즈니스 로직들이 한 어플리케이션에 다 있는 구조.
하나의 서버가 모든 서비스를 관장.
사용 이유 : 전체 어플리케이션을 하나로 처리하기 때문에 개발 도구에서 하나의 어플리케이션만 개발하면 되고 배포 간편하고 테스트도 하나의 어플리케이션만 수행하면 되기 때문에 편리하다.
⛔ 문제점
한쪽 서비스가 문제가 생기면 모든 서버에 영향을 주어 기타 서비스들 모두 사용 불가.
크기가 커서 빌드 및 배포의 시간이 오래 걸린다.
일부의 실수가 전체 시스템의 빌드 실패가 발생시켜 여러 사람이 협업 개발하기 어렵다.
🏷️ MSA
비즈니스 요구사항 별로 서비스들을 각각 쪼개놓은 구조.
하나의 서버는 하나의 서비스만 관장.
그래서 대기업에서는 비즈니스 로직별로 결제팀, ~팀 별로 쪼개놓음.
서비스들이 많아지기 때문에 게이트웨이가 필요하다.
사용 이유 : 일부 서버, 서비스가 실패하더라도 전체 서버에 영향이 가지 않는다.
확장성과 유연성이 높아진다.
독립적인 서비스이므로 전체적인 구조 파악이 쉽다.
그래서 대규모 및 복잡한 프로젝트나 시스템을 독립적으로 개발하고 확장해야 하는 경우 주로 사용한다.
참조 : 편의 상 ‘하나의 서버’ 라고 설명한 것 (로드밸런서 + 다중 서버 구성 가능)
서비스마다 서버가 많아지면 수백개도 충분히 가능
⛔ 문제점
수많은 서버 속 어떤 서버의 어떤 API를 사용해야할지 정리정돈, 버전관리 안됨
그래서 등장한 것이 API GW(Gateway) -> 모든 서버에 대한 모든 API 호출을 중앙화.
- 특징 1 : 각 서버마다 어떤 API 를 제공하는지 Swagger 를 통해 버전 관리
- 특징 2 : 어떤 서버의 API 를 어떤 서버가 사용할지 Consumer - Producer 관리
(Consumer는 API 호출하는 사람)
Reference
🔗 https://velog.io/@dmchoi224/Microservice-Architecture-MSA-%EA%B7%B8%EB%A6%AC%EA%B3%A0-Monolithic - Microservice Architecture (MSA) 그리고 Monolithic
🔗 https://medium.com/@Dopedev/microservice-architecture%EB%9E%80-ca9825087050 - Microservice Architecture란?
🔗 https://ssungkang.tistory.com/entry/MSA-Monolithic-Architecture-VS-Micro-Service-Architecture - Micro Service Architecture
🔗 https://seungh1024.tistory.com/64, https://skstp35.tistory.com/368 - 사용 이유, 장단점
