Microservices Architecture
- 비즈니스 로직을 나누었다.
- 큰 프로그램 대신 몇몇의 작은 어플리케이션이다.
- 잘 정의된 API로 소통한다.(HTTP, AMQP 활용)
- 하나의 서비스가 정지될경우 다른것에 영향을 미치지 않는다
What is Microservice Architecture?
- 각각의 컴포넌트를 시스템에 집어넣는것이며 각각 빌드되고 배포될수 있다.
- Microservice 는 vertical 하며 layered하다. 또한 Process driven 형태이다.
- Microservice를 잘 정의하면 TDD가 가능하다.
- 엔터프라이즈 아키텍처가 아니다. Microservice Architecture는 SOA와 유사하다.
- 단일 비즈니스 기능을 구현한다.
- 자신만의 데이터베이스를 갖는것이 일반적이나 데이터베이스를 갖지않는경우도 있다.
- HTTP, AMQP 로 통신한다.
- 독립적으로 배포가 가능하다.
- 각각의 레파지토리를 갖는다.
- 마이크로 서비스 팀은 몇명이 적당할까? 피자 두판을 먹을 수 있을만한 인원수! 6명 ? 좋다!
Microservice의 구성
- Data Store
- Application/Logic
- Public API(POST, GET )
Microservices application의 전형적인 생태계
원칙1. Microservices들은 각 public API에 서로 의존한다.
- 백엔드의 마이크로 서비스는 노출되면 안된다. 오직 프론트 마이크로 서비스만 노출되어야 한다.
원칙2. 작업에 적합한 tool(ex. 프레임워크)을 사용하라.
원칙3. 서비스 보안에 신경써라
원칙4. 생태계에서 좋은 시민이 되어라!
- 모니터링, 로깅, 추적을 분산하라
원칙5. 기술 변화 이상의 것이다.
- 조직 변화를 수용하라
원칙6. 모든것을 자동화하라(DevOps!)
Micro Service를 위해서…
- 비즈니스 도메인을 이해하자
- 일관성 유지하자
- 서비스 발견해보자
- 불필요한 상호통신이 많다면 조정해보자
Microservice 계획하기
- 정말 옳은 선택인가?(트레이드 오프 고려)
- 시스템의 주요기능을 식별하자
- 서비스 컴포넌트의 스코프를 세부적으로 결정하라(Function의 크기, 타입, 복잡성)
- API들을 디자인하라
- 커뮤니케이션의 메커니즘을 결정하라
- 데이터 모델을 결정하라(중앙 데이터베이스 vs 여러 데이터 저장소)
Benefits of microservices
- 각각의 microservices를 쉽개 확장할 수 있다
- 빠른 빌드, 테스트, 릴리즈의 싸이클
- agility의 증가
- 빠른혁신이 가능하다.
- 명확한 소유권 그리고 책임의 분배.
Microservice Architecture
- 각 microservice는 컨테이너에 할당된다. 컨테이너는 microservice 기반 어플리케이션을 개별적으로 개발, 배포하기 좋은 방법이다.
- microservice 간 stateless server 형태로 소통한다.
- 클라이언트는 서비스를 바로 호출할수 없고 API 게이트웨이가 클라이언트의 요청을 적절한 microservice로 전달한다.
(API 게이트웨이는microservice로인가요? 하드웨어나 소프트웨어로 볼 수 있다. microservice로 일수도 있지만 아닐수도 있다.) - 각 서비스는 상호 독립적이다.
- Single-responsibility 원칙을 따름
- 아무것도 공유하지 않는다.
- 비동기가 가능하다.
- configuration의 외부화
- 결합도가 느슨하다.
- 하나의 서비스가 문제를 일으켜도 나머지는 상관없다.
Microservices - Disadvantages
Complex networking으로 인해 데이터베이스, 서버의 오버헤드 발생
Monolithic Architecture vs Microservice Architecture
Monolithic Architecture : 모든 기능이 단일 코드베이스에 위치하고 하나의 DB를 사용한다. 또한 한 기능이 마비되면 전체가 마비되며 크고 복잡한 어플리케이션형태
Microservices vs SOA
SOA 컨센은 centrallize이다.
MS는 not centrallize이다.
즉 SOA는 오케스트라와 같다. (한 지위자가 전체를 통솔한다) Microservices는 발레와 같다. (각 댄서가 각자 율동한다)
Monolithic Architecture vs SOA vs Microservices
coarse-grained : 특정 프로세스(서비스)를 큰 덩어리로 나누는것fine-grained : 특정 프로세스(서비스)를 잘게 쪼개는 것
Microservices를 구현해야 하는 9가지 이유
- Easy To Build & Maintain
- Continuous Delivery
- Hybrid Technologies
- Cross Team Coordination
- Higher Quality Code
- Smarter Scaling
- Risk Reduction
- Promote Big Data Best Practices
- Improved ROI with reduced TCO
Illustration of Monolithic Module Refactoring
Microservice Architecture는 3계층이다.Container/ Orchestration /Application
The twelve Factors
I. Codebase: One codebase that is tracked in revision control, with many deployments
II. Dependencies: Explicitly declare and isolate dependencies
III.Configuration: Store Configuration in the environment
IV.Backing services: Treat backing services as attached resources
V. Build, release, run: Strictly separate build and run stages
VI.Processes: Execute the app as one or more stateless processes
VII.Port binding: Export services with port binding
VIII.Concurrency: Scale out using the process model
IX.Disposability: 빠른 시작 및 효율적인 종료가 가능하다.
X. Development and production parity: Keep development, staging, and production as similar as possible
XI.Logs: Treat logs as event streams
XII.Admin processes: Run administrative and management tasks as one-off processes