마이크로 서비스의 개념과 설계 원칙, 설계 방법, 리액티브 마이크로 서비스의 개념

마이크로 서비스의 이해

  • 마이크로서비스 아키텍처는 기업용 애플리케이션에서 가장 많이 사용하는 접근 방식중 하나가 됐다.

  • 마이크로 서비스는 모듈 방식으로, 세분화된 기능을 제공하는 느슨하게 결합된 서비스이다.

  • 마이크로 서비스는 관심 사항을 물리적으로 분리해 독립적으로 설계, 개발, 테스트 배포 할 수 있다.

  • 이런 모듈화 특성으로 인해, 애자일 방법론과 데브옵스 및 CI의 이상적인 후보가 된다.

  • MSA는 다른 서비스와 연결이 용이하기 때문에 복잡한 비즈니스 애플리케이션을 쉽게 통합 할 수 있으며, 각 모듈을 독립적으로 확장, 모니터링, 제어 할 수 있기 때문에 클라우드 아키텍처에 최대한 활용 가능하다.

  • 일반적으로 마이크로서비스를 위한 인프라가 더 단순하다. 이유는 관리, 구성, 모니터링, 제어해야 할 복잡한 서버가 많지 않고, 방대한 데이터베이스 스키마를 사용하지 않으며, 더 많은 것들을 쉽게 자동화 할 수 있기 때문이다. 이는 팀 내에 데브옵스 문화가 일반적인 관행이 되게 하고, 이를 통해 제품 내에 유연성을 더욱 높일 수 있다.

　

마이크로 서비스 설계 원칙

  • 비즈니스 역량 중심 모델
    • 서비스가 비즈니스 역량의 단순한 추상화가 아니라 원래 비즈니스 역량이 매핑되도록 함
  • 느슨한 결합
    • 상호작용을 구현 할 때 최대한 느슨하게 결합해야 함, 가능한 마이크로 서비스는 자신의 도메인 내에 있는 정보만 반환
  • 단일 책임
    • 모든 마이크로 서비스는 애플리케이션에서 제공하는 기능 중 단일한 부분에 대한 책임만 감당하며 캡슐화 돼야함
  • 구현 은닉
    • 다른 마이크로 서비스와의 커플링을 줄이고, 세부 사항의 변경이 다른 서비스에 영향을 주는 것을 줄임, 비즈니스 모델을 어디에 저장하는지부터 프로그래밍 언어나 프레임워크까지, 필요하다면 언제든지 변경이 가능해야 함
  • 격리 시스템의 인프라아 논리적으로나 물리적으로 분리 돼야 함, 아키텍처 일부에서의 장애가 다른 곳에 영향을 주지 않아야 함
  • 독립적인 배포 가능
    • 독립적인 배포가 불가능하다면 아키텍처 내에 해결해야 할 결합이 존재함, 다른 원칙은 충족 시키더라도 이 원칙에 실패한다면 장점을 경감 시키는 것
    • 마이크로서비스 아키텍처를 설계하는 초기 단계부터 배포를 염두에 두어야 함, 후반부에 이 영역에 대한 제약을 발견하면 전체 애플리케이션에 큰 영향을 미칠 수 있음
  • 장애를 고려
    • 장애가 발생한다면 이 장애를 최대한 매끄럽게 처리하도록 설계해야 하며 복구 방안을 정의해야 함
    • “잘못될 수 있는 일은 반드시 잘못된다.”
  • 확장성
    • 각 서비스는 독립적으로 확장 가능하도록 설계돼야 함
  • 자동화
    • 구축, 테스트, 배치, 모니터링에 이르기까지 자동화를 염두해 두고 설계해야 함
    • 서비스를 작게 만들고 격리시키기 때문에 자동화에 드는 비용은 낮아야 하며 이점은 높아야 함
    • 초기 단계부터 CI/CD를 염두 해야 함

마이크로 서비스에서의 도메인 주도 설계

  • 경계된 컨텍스트
    • 하나 이상의 경계된 컨텍스트를 포함하는 마이크로 서비스를 만들지 말아야 함
  • 유비쿼터스 언어
  • 컨텍스트 매핑
    • 마이크로 서비스간 의존성과 결합을 쉽게 이해하기 위해, 전체 시스템의 컨텍스트 매핑을 검토해야 함

　

리액티브 마이크로서비스란?

리액티브 프로그래밍은 최근 트랜디한 주제이며, 비동기 처리가 가능한 마이크로 서비스를 의미한다.

이 모델을 사용하면 기존의 블로킹 모델보다 더 많은 요청을 처리 할 수 있는 고성능 애플리케이션을 구현 할 수 잇다.

리액티브 모델은 다음과 같은 특징을 갖는다

  • 응답성
    • 문제나 오류에도 응답
  • 복원성
  • 탄력성
  • 메세지 기반
    • 매우 느슨하게 연결된 여러 컴포넌트를 통해 정보를 전달
    • 이를 통해 격리된 시스템을 상호 연결함