컨텍스트

서버 측 엔터프라이즈 애플리케이션을 개발 중입니다. 데스크톱 브라우저, 모바일 브라우저 및 기타 다양한 클라이언트를 지원해야합니다. 네이티브 모바일 애플리케이션. 애플리케이션은 타사에서 사용할 수있는 API를 노출 할 수도 있습니다. 웹 서비스 또는 메시지 브로커를 통해 다른 애플리케이션과 통합 할 수도 있습니다. 애플리케이션은 비즈니스 로직을 실행하여 요청 (HTTP 요청 및 메시지)을 처리합니다. 데이터베이스 액세스; 다른 시스템과 메시지 교환; HTML / JSON / XML 응답을 반환합니다. 애플리케이션의 다양한 기능 영역에 해당하는 논리적 구성 요소가 있습니다.

문제

애플리케이션의 배포 아키텍처는 무엇입니까?

Forces

• 애플리케이션을 작업하는 개발자 팀이 있습니다.
• 신규 팀원은 신속하게 생산성을 높여야합니다.
• 애플리케이션은 이해하기 쉬워야합니다. 및 수정
• 애플리케이션의 지속적인 배포를 연습하려는 경우
• 확장 성 및 가용성 요구 사항을 충족하려면 여러 시스템에서 애플리케이션의 여러 인스턴스를 실행해야합니다.
• 새로운 기술 (프레임 워크, 프로그래밍 언어 등)을 활용하려는 경우

솔루션

응용 프로그램을 느슨하게 결합 된 집합으로 구조화하는 아키텍처를 정의합니다. 협업 서비스.이 접근 방식은 Scale Cube의 Y 축에 해당합니다. 각 서비스는 다음과 같습니다.

• 높은 유지 관리 및 테스트 가능-ra pid 및 빈번한 개발 및 배포
• 다른 서비스와 느슨하게 결합-팀이 다른 서비스의 변경에 영향을받지 않고 다른 서비스에 영향을주지 않고 대부분의 시간 동안 독립적으로 작업 할 수 있도록합니다.

li>

• 독립적으로 배포 가능-팀이 다른 팀과 협력하지 않고도 서비스를 배포 할 수 있습니다.
• 소규모 팀에서 개발 가능-대규모의 높은 커뮤니케이션 책임자를 피하여 높은 생산성에 필수적 팀

서비스는 HTTP / REST와 같은 동기 프로토콜 또는 AMQP와 같은 비동기 프로토콜을 사용하여 통신합니다. 서비스는 서로 독립적으로 개발 및 배포 할 수 있습니다. 각 서비스에는 자체 데이터베이스가 있습니다. 서비스 간의 데이터 일관성은 Saga 패턴을 사용하여 유지됩니다.

서비스의 특성에 대해 자세히 알아 보려면이 기사를 읽어보세요.

예

가상 전자 상거래 애플리케이션 on

고객의 주문을 받아 재고 및 사용 가능한 크레딧을 확인하고 배송하는 전자 상거래 애플리케이션을 구축한다고 가정 해 보겠습니다. 애플리케이션은 사용자 인터페이스를 구현하는 StoreFrontUI를 포함한 여러 구성 요소로 구성됩니다. , 신용 확인, 재고 유지 및 주문 배송을위한 일부 백엔드 서비스와 함께 애플리케이션은 서비스 세트로 구성됩니다.

코드보기

Chris Richardson이 개발 한 예제 애플리케이션을 참조하십시오. Github의 이러한 예제는 마이크로 서비스 아키텍처의 다양한 측면을 보여줍니다.

결과 컨텍스트

이점

이 솔루션에는 다음과 같은 여러 가지 이점이 있습니다.

• 대규모의 복잡한 애플리케이션을 지속적으로 배포하고 배포 할 수 있습니다.
  • 향상된 유지 보수성-각 서비스는 상대적으로 작기 때문에 이해하고 변경하기가 더 쉽습니다
  • 더 나은 테스트 가능성-서비스는 더 작고 테스트하기 더 빠릅니다
  • 더 나은 배포 가능성-서비스 독립적으로 배포 할 수 있습니다.
  • 여러 자율적 인 팀을 중심으로 개발 노력을 구성 할 수 있습니다. 각 팀 (소위 피자 2 개)은 하나 이상의 서비스를 소유하고 담당합니다. 각 팀은 다른 모든 팀과 독립적으로 서비스를 개발, 테스트, 배포 및 확장 할 수 있습니다.
• 각 마이크로 서비스는 상대적으로 작습니다.
  • 개발자의 이해
  • IDE가 더 빨라져 개발자의 생산성 향상
  • 애플리케이션이 더 빨리 시작되어 개발자의 생산성이 높아지고 배포 속도가 빨라집니다
• 개선 된 오류 격리. 예를 들어, 한 서비스에서 메모리 누수가 발생하면 해당 서비스 만 영향을 받고 다른 서비스는 계속 요청을 처리합니다. 이에 비해 모 놀리 식 아키텍처의 오작동 구성 요소 중 하나는 전체 시스템을 중단시킬 수 있습니다.
• 기술 스택에 대한 장기적인 약속을 제거합니다. 새로운 서비스를 개발할 때 새로운 기술 스택을 선택할 수 있습니다. 마찬가지로 기존 서비스를 크게 변경할 때 새로운 기술 스택을 사용하여 다시 작성할 수 있습니다.

결점

이 솔루션에는 다음과 같은 여러 가지 단점이 있습니다.

• 개발자는 분산 시스템 생성의 추가적인 복잡성을 처리해야합니다.
  • 개발자는 서비스 간 통신 메커니즘을 구현하고 부분적인 실패를 처리해야합니다.
  • 여러 서비스에 걸친 요청을 구현하는 것이 더 어렵습니다.
  • 서비스 간의 상호 작용을 테스트하는 것이 더 많습니다. 어려움
  • 여러 서비스에 걸친 요청을 구현하려면 팀 간의 신중한 조정이 필요합니다.
  • 개발자 도구 / IDE는 모 놀리 식 애플리케이션 구축을 지향하며 분산 애플리케이션 개발에 대한 명시적인 지원을 제공하지 않습니다.
• 배포 복잡성. 프로덕션 단계에서는 다양한 서비스로 구성된 시스템을 배포하고 관리하는 작업의 복잡성도 있습니다.
• 메모리 소비 증가. 마이크로 서비스 아키텍처는 N 개의 모 놀리 식 애플리케이션 인스턴스를 NxM 서비스 인스턴스로 대체합니다. 각 서비스가 일반적으로 인스턴스를 분리하는 데 필요한 자체 JVM (또는 이와 동등한)에서 실행되는 경우 JVM 런타임보다 M 배 많은 오버 헤드가 발생합니다. 또한 Netflix의 경우처럼 각 서비스가 자체 VM (예 : EC2 인스턴스)에서 실행되는 경우 오버 헤드가 훨씬 더 높습니다.

문제

있습니다. 해결해야 할 많은 문제가 있습니다.

마이크로 서비스 아키텍처를 언제 사용해야합니까?

이 접근 방식을 사용하는 데있어 한 가지 과제는 사용이 적절한시기를 결정하는 것입니다. 응용 프로그램의 경우 이러한 접근 방식으로 해결할 수있는 문제가없는 경우가 많습니다. 또한 정교한 분산 아키텍처를 사용하면 개발 속도가 느려질 수 있습니다. 이는 비즈니스 모델을 신속하게 발전시키는 방법과 그에 수반되는 방법이 가장 큰 문제인 스타트 업에게는 큰 문제가 될 수 있습니다. Y 축 분할을 사용하면 빠르게 반복하기가 훨씬 더 어려워 질 수 있지만 나중에 문제가 확장 방법이고 함수 분해를 사용해야하는 경우 얽힌 종속성으로 인해 모 놀리 식 애플리케이션을 다음으로 분해하기가 어려울 수 있습니다. 서비스 세트

어플 리카 분해 방법 서비스로 전환 하시겠습니까?

또 다른 문제는 시스템을 마이크로 서비스로 분할하는 방법을 결정하는 것입니다. 이는 매우 예술적이지만 도움이 될 수있는 여러 전략이 있습니다.

• 비즈니스 기능별로 분해하고 비즈니스 기능에 해당하는 서비스를 정의합니다.
• 도메인 기반 설계 하위 도메인으로 분해합니다.
• 동사 또는 사용 사례별로 분해하고 특정 작업을 담당하는 서비스를 정의합니다. . 예 : 전체 주문 배송을 담당하는 Shipping Service
• 특정 개체 / 리소스에 대한 모든 작업을 담당하는 서비스를 정의하여 명사 또는 리소스별로 분해합니다. 유형. 예 : 사용자 계정 관리를 담당하는 Account Service

이상적으로 각 서비스에는 작은 책임 세트 만 있어야합니다. (삼촌) Bob Martin SRP (Single Responsibility Principle)를 사용하여 클래스를 설계하는 방법에 대해 설명합니다 .SRP는 클래스의 책임을 변경 이유로 정의하고 클래스가 변경해야하는 이유는 하나만 있어야한다고 명시합니다 .SRP를 서비스 설계에 적용하는 것이 합리적입니다.

서비스 설계에 도움이되는 또 다른 비유는 Unix 유틸리티의 설계입니다 .Unix는 grep, cat 및 find와 같은 많은 유틸리티를 제공합니다. 각 유틸리티는 정확히 한 가지 작업을 수행하며 종종 예외적으로 잘 수행합니다. 복잡한 작업을 수행하기 위해 쉘 스크립트를 사용하는 다른 유틸리티와 결합되도록 고안되었습니다.

데이터 일관성을 유지하는 방법

느슨한 결합을 보장하기 위해 각 서비스에는 고유 한 2 단계 커밋 / 분산 트랜잭션이 수행되지 않기 때문에 서비스 간 데이터 일관성 유지가 어렵습니다. 많은 애플리케이션에 대한 옵션. 애플리케이션은 대신 Saga 패턴을 사용해야합니다. 서비스는 데이터가 변경 될 때 이벤트를 게시합니다. 다른 서비스는 해당 이벤트를 사용하고 데이터를 업데이트합니다. 데이터를 안정적으로 업데이트하고 이벤트 소싱 및 이벤트를 게시하는 여러 가지 방법이 있습니다. 트랜잭션 로그 테일링.

쿼리 구현 방법

또 다른 문제는 여러 서비스에서 소유 한 데이터를 검색해야하는 쿼리를 구현하는 것입니다.

• API CQRS (Composition and Command Query Responsibility Segregation) 패턴

마이크로 서비스 패턴과 관련된 많은 패턴이 있습니다. 모 놀리 식 아키텍처는 마이크로 서비스 아키텍처의 대안이며 다른 패턴은 마이크로 서비스 아키텍처를 적용 할 때 발생할 수있는 문제를 해결합니다.

• 분해 패턴
  • 비즈니스 기능별 분해
  • 하위 도메인 별 분해
• 서비스 별 데이터베이스 패턴은 각각의 서비스에는 느슨한 결합을 보장하기 위해 자체 데이터베이스가 있습니다.
• API 게이트웨이 패턴은 클라이언트가 마이크로 서비스 아키텍처의 서비스에 액세스하는 방법을 정의합니다.
• 클라이언트 측 검색 및 서버 측 검색 패턴은 클라이언트에 대한 요청을 클라이언트로 라우팅하는 데 사용됩니다. 마이크로 서비스 아키텍처에서 사용 가능한 서비스 인스턴스입니다.
• 메시징 및 원격 프로 시저 호출 패턴은 서비스가 통신 할 수있는 두 가지 다른 방법입니다.
• 호스트 당 단일 서비스 및 호스트 당 다중 서비스 패턴은 다음과 같습니다. 두 가지 배포 전략.
• 교차적인 관심사 패턴 : 마이크로 서비스 섀시 패턴 및 외부화 된 구성
• 테스트 패턴 : 서비스 구성 요소 테스트 및 서비스 통합 계약 테스트
• 회로 차단기
• 액세스 토큰
• 관측 성 패턴 :
  • 로그 집계
  • 애플리케이션 측정 항목
  • 감사 로깅
  • 분산 추적
  • 예외 추적
  • 상태 확인 API
  • 로그 배포 및 변경
• UI 패턴 :
  • 서버 측 페이지 조각 구성
  • 클라이언트 측 UI 구성

알려진 용도

Netflix, Amazon 및 eBay를 포함한 대부분의 대규모 웹 사이트는 모 놀리 식 아키텍처에서 마이크로 서비스 아키텍처로 발전했습니다.

Netflix는 매우 인기있는 동영상 스트리밍 서비스입니다. 인터넷 트래픽의 최대 30 %에 해당하는 대규모 서비스 지향 아키텍처를 갖추고 있으며 800 개가 넘는 다양한 장치에서 비디오 스트리밍 API에 대한 하루 10 억 건 이상의 호출을 처리합니다. 백엔드 서비스에 대한 호출.

Amazon.com은 원래 2 계층 아키텍처를 사용했습니다. 확장을 위해 수백 개의 백엔드 서비스로 구성된 서비스 지향 아키텍처로 마이그레이션했습니다. 애플리케이션을 포함한 여러 애플리케이션에서 이러한 서비스를 호출합니다. Amazon.com 웹 사이트 및 웹 서비스 API를 구현하는 Amazon.com 웹 사이트 애플리케이션은 100-150 서비스를 호출하여 웹 페이지를 구축하는 데 사용 된 데이터

경매 사이트 ebay.com도 모 놀리 식 아키텍처에서 서비스 지향 아키텍처로 발전했습니다. 애플리케이션 계층은 여러 독립 애플리케이션으로 구성됩니다. 각 애플리케이션은 비즈니스 로직을 구현합니다. 구매 또는 판매와 같은 특정 기능 영역에 대해 각 애플리케이션은 X 축 분할을 사용하고 검색과 같은 일부 애플리케이션은 Z 축 분할을 사용합니다 .Ebay.com은 또한 X, Y 및 Z 스타일 스케일링의 조합을 데이터베이스 계층입니다.

마이크로 서비스 아키텍처를 사용하는 회사의 다른 예가 많이 있습니다.

Chris Richardson은 마이크로 서비스 기반 애플리케이션의 예를 가지고 있습니다.

참조 h2>

마이크로 서비스 아키텍처에 대한 좋은 소개를 제공하는 내 Code Freeze 2018 기조 연설을 참조하십시오.