개념이 나오기 전, 대부분의 웹 기반 애플리케이션은 모놀리식 아키텍처 형태로 개발되었다.
모놀리식 아키텍쳐
배포 가능한 단일 소프트웨어 산출물로 전달된다
UI 및 비즈니스 로직, 데이터베이스 액세스 로직 모두가 하나의 애플리케이션 산출물로 패키징되고 애플리케이션 서버에 배포되는 것 (단일 코드 베이스)
-장점
- 단일 코드 베이스로 서비스의 환경이 동일하여 복잡하지않다.
- end-to-end 테스트가 용이하다.
-단점
- 프로젝트 덩치가 커져서 애플리케이션 구동 시간이 늘어나고, 빌드 배포시간도 길어진다.
- 작은 수정사항이라도 전체를 다시 빌드/테스트/배포 해야한다.
- 많은 양의 코드로 개발자 모두가 이해할 수 없고 유지보수도 힘들다.
마이크로서비스
모놀리식 아키텍쳐 문제점에 대한 대안
느슨히 결합된 작은 분산 서비스
-핵심개념 : 애플리케이션 기능을 분해하고 분리해서 완전히 상호 독립적이어야 함
-장점
- 대형 애플리케이션 관리 쉬움
- 제한된 책임을 담당하는 컴포넌트로 분해가능.
- 새로 추가되거나 수정사항이 있는 서비스만 빠르게 빌드/테스트/배포가 가능하다.
이때 다른 서비스에는 영향을 미치지않는다.
- 해당 서비스에 적합한 기술, 언어, 버전, DB 등을 선택하여 구현할 수 있다.
-단점
- 여러 서비스들이 분산되어있기 때문에 모니터링이 힘들다
- 모놀리식보다 통신관련 오류가 잦을 수 있다.
- 모놀리식보다 end-to-end 테스트시 과정이 더 많다.
- 서비스 소비자와 서비스 제공자 사이의 데이터 교환을 위해 HTTP와 JSON 같은 경량 통신 프로토콜을 사용한다.
- 서비스가 작기 때문에 클라우드에서 많은 서비스 인스턴스를 쉽게 시작할 수 있다.
때문에 애플리케이션 확장성을 높일 수 있고, 사전 계획으로 회복성도 향상할 수 있다.
- 작고 단순하며 분리된 서비스 = 확장 가능하고 회복적이며 유연한 애플리케이션
(참고)
[스프링 마이크로서비스 코딩 공작소 - 길벗출판사]
https://lion-king.tistory.com/entry/마이크로-서비스-vs-모놀리식-아키텍처-MicroService-vs-Monolithic-Architecture-간단-소개-및-주관적-의견