반응형
마이크로서비스에서 애플리케이션에서 컨텍스트를 구분하는 기준이 생각보다 애매하다. 어디서부터 어디 까지 정의해서 사용해야 하는지에 대한 기준을 정리해보자.
자율적인 기능 제공 서비스
- 암호화 유틸 서비스, 배송 조회 검색 기능 서비스 등 자율적인 동작이 가능한 서비스의 경우에는 마이크로서비스의 별도 컨텍스트로서 사용이 가능하다.
배포 단위의 크기
- 좋은 마이크로서비스가 될 수 있도록 배포 단위의 크기를 관리할 수 있는 수준 이내로 유지해야한다.
분리하기 가장 적합한 기능 또는 서브 도메인
- 일체형 서비스를 마이크로서비스로 분리하고자 할 때 자원 소모량, 소유 비용, 비즈니스 효율성, 유연성 측면에서 분석 기준을 나눠서 생각해야한다.
폴리그랏 아키텍쳐
- 다양한 비 기능/기능적 요구 사항을 충족시키기위해 컴포넌트 마다 서로 다른 아키텍처 다른 기술 다른 배포 방식을 사용할 수 있는 것을 말한다.
- 예를 들어 특정 서비스는 MySql을 사용하고 다른 쪽은 검색을 위한 Elasticsearch 등을 사용할 수 있다.
애자일팀과 협력 개발
- 마이크로서비스는 전 체중에서 서로 다른 일부를 개발하는데 집중할 수 있는 작고 집중력 있는 팀 구성을 통해 애자일 방식의 개발을 가능하게 해준다.
- 마이크로 서비스 세상에서 각 팀이 서로 다른 마이크로서비스를 만들고 나중에 하나로 조합할 수 있다.
단일 책임
- 단일 책임의 원칙은 소프트웨어 공학에서 특정 기능을 위해 만들어진 메서드나 클래스가 한 가지 이상의 역할을 해서는 안되는 원칙이다.
- 단일 책임 원칙에서 하나의 책임이 여러 마이크로서비스와 공유될 수 없는 것처럼 하나의 마이크로 서비스는 여러 책임을 담당해서는 안된다.
결합과 응집
- 서비스 경계를 결정 짓는데 가장 중요한 두 가지 기준은 결합(Coupling)과 응집(Cohesion)이다.
- 마이크로서비스 사이의 의존 관계 높은 결합도가 형성되지 않도록 해야한다.
- 너무 많은 정보 교환과 동기 요청을 사용한다면 시스템을 망가트리는 원인이 되기도 한다.
- 트랜잭션 범위가 하나의 마이크로서비스의 범위를 넘어서 여러 마이크로서비스에 걸치지 않게 하는 것도 중요하다.
마이크로서비스를 하나의 제품으로 생각하기
- DDD는 경계 지어진 컨텍스트를 하나의 제품과 짝짓는 것을 권장한다.
- 하나의 Context가 하나의 단독 제품으로써 구분되는 것이 가장 이상적이다.
- 마이크로서비스로 서비스가 구분되는 기준을 이와 비슷한 개념으로 하나의 서비스로써 구분되는 것으로 생각하는 것이 좋다.
반응형
'web > 마이크로서비스' 카테고리의 다른 글
마이크로서비스 조립성 및 정리 (0) | 2018.10.23 |
---|---|
마이크로 서비스 통신방식 결정 (0) | 2018.10.23 |
스프링 웹플럭스(spring webflux)를 활용한 간단한 리액티브 마이크로 서비스 (0) | 2018.10.04 |
리액티브 스트림의 이해 (0) | 2018.10.04 |
스프링 부트와 RabbitMQ를 사용한 리액티브 마이크로 서비스 (0) | 2018.10.04 |