monolithic architecture
장점
- end-to-end 테스트가 용이
- 빠르게 간단한 서비스 만들 수 있음.
단점
- 간단한 수정사항이 있어도 전체 다시 빌드하고 배포 필요
- 유지보수가 어려움
- 덩치가 커지면 구동시간이 늘어나 생산성이 떨어짐
- 일부분 오류가 생기면 전체 장애 발생
- 각 기능에 따라 다른 언어 선택 못함
microservice architecture
장점
- 서비스별 독립적인 배포 가능.
- 요구사항을 신속하게 반영하여 빠르게 배포 가능
- 특정 서비스에 대한 확장성이 쉽고 유지보수 용이
- 클라우드 사용에 적합함
- 장애가 전체 서비스로 확장될 가능성이 적어 부분 장애 처리가 수월함
- 각 기능에 따라 다른 언어 선택 가능
단점
- 서비스가 분리되어 있기 때문에 통신 비용(Latency)이 높음.
- 한번에 모니터링이 어려움
- end-to-end 서비스 구동 불편. 즉,테스트가 불편하고 트랜잭션의 복잡도가 증가하여 많은 자원이 필요함
- 데이터가 여러 서비스에 분산되어 한번에 조회가 어렵고, 데이터 정합성 어려움.
첫 서비스 구현시엔 모노로식!
추후 지속적으로 발전 가능성이 있다면 마이크로서비스 아키텍쳐!
마이크로서비스 통신 패턴
Synchronous solution
- 동기
- Rest api
- 서비스 A에서 서비스 B로 직접 요청을 보내고 동기적으로 응답을 기다림.
Asynchronous Messaging
- 비동기적
- 메세지 브로커를 사용하여 서비스A에서 서비스B로 메세지를 보냄
- 서비스 A는 응답을 기다리지 않음.
- 서비스B는 일반적으로 동일한 메시징 시스템을 통해 결과를 사용할 수 있을때 결과를 보냄
- RabbitMQ와 Apache Kafaka
서비스 A,B가 동기적으로 데이터를 요청하고 응답받을때,
만약 서비스 B가 장애가 있어 실패하는 경우 어떻게 해야될지에 대한 처리가 필요함.
Producer에서 Costomer로 메세지를 전달하고 B에서 A로 메세지를 전달할 때 중개자 역할을 하는 Message Broker로 해결 가능.
Message Broker는 Producer에서 메세지를 수신하여 Customer에게 메세지를 전달하여 작업을 수행, Customer의 연결이 끊어졌을때 임시 message 저장소를 제공하여 독립성 확보 가능.
Reference
https://martinfowler.com/articles/microservices.html
