이 기사를 참조하면 마이크로서비스 아키텍처와 이를 사용하는 경우에 대해 더 잘 이해할 수 있습니다. 또한 이 글은 다음과 같은 내용으로 구성되어 있습니다.

◼ 기사의 약어

◼ 소개

◼ 마이크로서비스 생태계

◼ 모놀리식 아키텍처와 마이크로서비스 아키텍처

◼ 마이크로서비스의 과제

◼ 마이크로서비스를 사용해야 하는 경우

약어

• API : 애플리케이션 프로그래밍 인터페이스
• MS : 마이크로서비스
• NoSQL : SQL뿐만 아니라
• RTE : 런타임 환경

마이크로서비스 아키텍처 는 대규모 애플리케이션이 모듈식 서비스 모음으로 구축되는 애플리케이션 개발에 대한 접근 방식입니다 (마이크로서비스는 애플리케이션이 서비스 모음으로 개발되는 일종의 애플리케이션 아키텍처임을 의미합니다). 각 모듈은 특정 비즈니스 목표를 지원하고 잘 정의된 간단한 인터페이스를 사용하여 다른 서비스 집합과 통신합니다. 또한 Java, Python 등과 같은 다양한 프로그래밍 언어로 작성되고 마이크로 서비스 아키텍처에서 관계형 및 NoSQL과 같은 다양한 데이터 스토리지 기술을 사용할 수 있는 최소한의 중앙 집중식 관리 서비스가 있습니다.

다음과 같은 마이크로 서비스의 몇 가지 주요 기능/특성이 있습니다.

• 높은 유지 보수 및 테스트 가능
• 느슨하게 결합됨(인터페이스를 통해 통신)
• 독립적으로 배포 가능
• 비즈니스 역량 중심으로 구성
• 소규모 팀 소유(다기능 팀)

일반적으로 마이크로서비스 시스템에는 다음과 같은 항목이 포함됩니다. 이러한 엔터티 중 일부는 표준 소프트웨어 개발의 단계이며 일부는 효율적인 마이크로서비스 시스템을 위한 백본을 제공하는 마이크로서비스 관련 프로세스입니다.

로드 밸런서

로드 밸런서의 주요 책임은 들어오는 로드를 여러 마이크로 서비스 인스턴스 간에 분산하는 것입니다. 주로 클라이언트 검색(클라이언트 측 로드 밸런서) 및 서버 검색(서버 측 로드 밸런서)이라는 두 가지 유형의 로드 밸런서가 있습니다. 클라이언트 검색에서 클라이언트는 서비스 레지스트리와 통신하고 부하 분산을 수행합니다. 해당 클라이언트 때문에 서비스 레지스트리를 인식해야 합니다. 서버 검색에서 클라이언트는 로드 밸런서와 통신하고 로드 밸런서는 서비스 레지스트리와 통신합니다. 따라서 클라이언트 서비스는 서비스 레지스트리를 인식할 필요가 없습니다. 다음 다이어그램을 보면 이 두 가지 유형의 로드 밸런서에 대해 더 잘 이해할 수 있습니다.

서비스 검색 서버

서비스 검색 기능을 사용하면 현재 배포된 마이크로 서비스와 필요한 호스트 및 포트를 수동으로 추적하는 대신 마이크로 서비스가 시작 시 자체 등록할 수 있습니다. 따라서 MS1이 MS2와 통신을 하고자 한다면 먼저 랜드스케이프에 속한 레지스트리 서비스에서 세부 정보를 가져와서 MS2와 통신을 해야 한다. 또한 동일한 환경에서 MS3라는 다른 MS가 업 또는 다운된 경우 레지스트리 서비스가 자동으로 업데이트됩니다.

API 게이트웨이

API 게이트웨이는 서버입니다. 시스템으로의 단일 진입점입니다. API Gateway는 내부 시스템 아키텍처를 캡슐화합니다. 클라이언트별 맞춤형 API를 제공합니다. 또한 인증, 모니터링, 로드 밸런싱, 캐싱, 요청 셰이핑 및 관리, 정적 응답 처리와 같은 다른 책임도 있습니다. API 게이트웨이는 요청 라우팅, 구성 및 프로토콜 변환도 담당합니다. 클라이언트의 모든 요청은 API 게이트웨이를 통과합니다. 그런 다음 API 게이트웨이는 적절한 마이크로서비스로 요청을 라우팅합니다.

API 게이트웨이는 다음 두 가지 방법 중 하나로 요청을 처리합니다.

• 요청을 적절한 서비스로 라우팅하거나 프록시했습니다.
• 여러 서비스에 대한 요청을 분산(확산)합니다.

이제 우리는 동일한 생태계의 서로 다른 노드에서 실행되는 많은 마이크로 서비스가 있다는 것을 알고 있습니다. 따라서 단일 시스템에서 함께 모니터링해야 합니다. Hystrix 대시보드 및 Spring 부트 관리 대시보드는 모니터링 도구의 몇 가지 예입니다. 마이크로 서비스 모니터링에는 다음과 같은 5가지 원칙이 있습니다.

• 컨테이너와 그 안에 무엇이 있는지 모니터링합니다.
• 서비스 성능에 대한 경고.
• 탄력적이고 다중 위치에 있는 서비스를 모니터링합니다.
• API를 모니터링합니다.
• 조직 구조 모니터링

우리가 마이크로서비스를 구현할 때 마이크로서비스 구현은 다양한 기술을 사용하여 수행할 수 있으므로 마이크로서비스는 JRE 및 Node.js와 같은 서로 다른 RTE에서 실행됩니다. 또한 이러한 마이크로 서비스가 다국어 방식으로 배포된다는 것을 알고 있습니다. 따라서 노드는 배포된 마이크로서비스의 RTE를 알지 못하므로 각 노드에 수동으로 설치해야 합니다. 그러나 컨테이너화의 경우 RTE를 마이크로서비스와 함께 패키징합니다. 따라서 RTE를 고려하지 않고 마이크로 서비스를 어디에서나 실행할 수 있으며 이러한 서비스를 쉽게 관리하고 업데이트할 수 있습니다.

회로 차단기

마이크로 서비스의 생태계에서 매우 중요한 엔터티입니다. 대부분의 경우 이것은 패턴으로 정의됩니다. 이해를 돕기 위해 가정의 회로 차단기와 매우 유사합니다. 재난으로부터 당신을 보호하고 발생한 문제의 전파를 막습니다. 마이크로 서비스와 관련하여 동일한 시나리오가 여기에서 발생합니다(MS의 회로 차단기). 클라이언트가 공급자 마이크로 서비스에 요청을 보내고 응답이 오는 동안 연결 문제가 있다고 가정해 보겠습니다. 그 클라이언트는 오랜 시간 동안 응답을 기다리고 있기 때문에 다른 서비스에도 영향을 미칠 수 있습니다. 회로 차단기 아키텍처이므로 문제가 있는 채널은 폐기되고 이전 대기 문제가 해결됩니다. 또한 Closed 라는 세 가지 회로 차단기 상태가 있습니다., 오픈 및 하프 오픈.

모놀리식 아키텍처와 마이크로서비스 아키텍처

가격

• 모놀리식: 프로젝트가 확장되면 더 높아짐
• Microservce : 초기 개발 단계에서 더 높음

• 모놀리식 : 전체 제품에 대한 통합 코드베이스 및 데이터베이스
• 마이크로서비스: 여러 코드 파일; 각 서비스는 기본 및 데이터 저장소를 처리합니다.

• 모놀리식: 전체 코드 기반을 배포해야 합니다.
• 마이크로서비스: 각 마이크로서비스는 개별적으로 배포됩니다.

• 모놀리식: 동일한 코드 스택
• 마이크로서비스: 다양한 스택(언어, 런타임 환경 등)

다음과 같이 마이크로서비스를 다룰 때 몇 가지 문제가 있습니다.

• 프로세스 간 통신(네트워크를 통해)
• 분산 트랜잭션
• 다수의 서비스
• 더 많은 자동화 필요

이제 우리는 마이크로서비스와 그 과제에 대해 잘 이해하고 있습니다. 마이크로 서비스에 적합한 시나리오를 살펴보겠습니다.

• 회사는 깨끗하고 읽기 쉬운 코드를 즉시 작성하고 기술적 부채를 피하고자 합니다.
• 회사는 마이크로 서비스 개발을 위한 인력을 보유하고 있습니다.
• 회사는 단기 이익보다 장기 이익을 우선시합니다.
• 개발자 팀이 다양한 기술 스택과 도구를 사용합니다.
• 플랫폼은 확장성이 뛰어나고 다른 시장으로 확장되어야 합니다.