[MSA] MicroService Architecture
Monolith vs Microservice
Monolith
- 어플리케이션을 개발함에 있어서 모든 요소를 하나의 커다란 소프트웨어에 포함
하나의 큰 건축물(?) 분리를 못한다.
Microservice
- 어플리케이션을 구성하는 각각의 구성요소를 분리하여 개발하고 운영한는 방식
- 기능들이 독립적이고 최소화 되어있기 때문에 유지보수, 변경사항 적용하는데 유리
- 비지니스기능으로 구축되고 자동화된 배포시스템을 사용 CI/CD
각기능을 하는 레고들이 모여서 하나의 어플리케이션이 되는것이라고 생각하자
amazon 과 NETFLIX의 Microservice 예시
하나의 점이 모두 마이크로 서비스이다. 이러한 서비스들이 모두 연결되어 하나의 어플리케이션을 구성한다.
Microservice의 특징
- Challenges : 개발 방식을 상당수 바꿔야함
- Small Well Chosen Deployable Units : 각각의 서비스는 독립적으로 배포가능한 작은 서비스로 이루어져있음
- Bounded Context : 어플리케이션을 구성하는 전체 도메인의 지식에 의해 서비스 경계를 잘 구분 해야함 이러한 경계로 하나의 서비스가 여러개가되고 여러개가 단일화 될 수 있음
- RESTful : 각각의 서비스는 REST API로 통신
- Configuration Management : 환경 설정 정보를 외부의 시스템을 통해 관리 (RabbitMQ, Kafka 등 메세지큐잉 서비스로 관리가 가능함)
- Cloud Enabled : cloud native 기술을 활용
- Dynamic Scale Up and Scale Down : 서비스를 제공하는 인스턴스들은 부하분산 처리나 Scale Up, Scale Down이 동적으로 처리되야함
- CI/CD : 자동화 배포 관리
- Visibility : 시각화할수 있는 관리도구를 가지고 있어야함 (그라파나, 프로메테우스, ZipKin)
Microservice 는 Two Pizza team 으로 구성하는 것이 이상적이다. ( 4 ~ 5명)
커뮤니케이션 비용이 적게 발생하고 개발, 테스트, 배포를 하기위한 최소 단위이다.
각각의 서비스는 db도 다를수 있으며 이러한 data들은 kafka를 통해서 관리가 가능하다.
Client 와 다른 service가 API gateway를 통해 진입하게 되고 Service Router와 Service Discovery를 통해 어디로 접속해야 할지 정해진다. 각각의 서비스는 Container화 되어 있으며 설정 정보는 외부 파일로 통해 관리된다.(RabbitMQ)
사용해볼 기술
Frameworks : Spring Boot, Spring Cloud
Gateway : API Gateway
Resilient Service Mesh/Meta Services : Zookekper
Runtime : Docker
Backing Services: RabbitMQ, Kafka
Telemetry : Zipkin