패턴 : Microservice 아키텍처

문맥

당신은 서버 측 엔터프라이즈 응용 프로그램을 개발하고있다. 그것은 데스크톱 브라우저, 모바일 브라우저 및 네이티브 모바일 애플리케이션을 포함하여 고객의 다양한 지원해야합니다. 이 응용 프로그램은 타사 사용을위한 API를 열 수 있습니다. 또한 다른 응용 프로그램과 웹 서비스 나 메시지 브로커를 통해 통합 할 수 있습니다. 다른 시스템과 메시지를 교환; 데이터베이스에 액세스, 비즈니스 로직 처리 요청 (HTTP 요청 및 메시지)를 실행하는 응용 프로그램 및 HTML / JSON / XML 응답을 반환합니다. 애플리케이션 로직 구성 요소에 대응하는 다른 기능 영역의 존재.

문제

응용 프로그램의 어떤 배포 아키텍처는 무엇입니까?

초점

개발자의 한 그룹은 응용 프로그램의 개발에있다
새로운 팀 구성원 신속하게 업무의 효율성을 개선해야한다
응용 프로그램은 쉽게 이해할 수 및 수정해야합니다
당신은 실제 응용 프로그램을 배포 계속하려면
당신은 확장 성 및 가용성 요구 사항을 충족하기 위해 여러 대의 컴퓨터에 여러 응용 프로그램 인스턴스를 실행해야합니다
당신은 (등, 프로그래밍 언어, 프레임 워크) 기술을 신흥 활용하려면

솔루션

아키텍처의 정의, 응용 프로그램은 느슨하게 결합 된 협업 서비스의 집합으로 내장되어 있습니다. 이 방법은 Y 축 스케일 큐브에 대응한다. 각 서비스는 다음과 같습니다

유지 보수 및 테스트 용이성의 높은 수준 -
느슨하게 다른 서비스와 결합의 빠른 자주 개발 및 배포
그것은 독립적으로 배포 할 수있는 다른 서비스에 영향을 미치지 않습니다 다른 서비스는 변화에 의해 영향을받지 않습니다 반면, 독립적으로 대부분의 시간을 작업 팀을 활성화합니다
그것은 작은 팀을 개발하기 위해 다른 팀과 협력하지 않고 자신의 서비스를 배포 할 팀 수
대규모 팀을 담당 높은 통신 사람을 피함으로써 생산성을 향상하는 것이 필수적입니다

HTTP / REST 프로토콜 등시 또는 비동기 AMQP 프로토콜을 사용하여 다른 서비스를 제공합니다. 서로 독립적으로 개발 및 서비스를 배포 할 수 있습니다. 각 서비스는 자체 데이터베이스가 다른 서비스에서 분리 될 수 있습니다. 서비스 간의 데이터 일관성을 유지하기 위해 사가 모드를 사용

서비스의 성격에 대해 자세히 알아보십시오, 이 문서를 읽을 .

예

가상의 전자 상거래 응용 프로그램

응용 프로그램은 고객, 검증 가능한 신용의 재고, 그 운송에서 주문을 받아, 이제 당신은 전자 상거래 응용 프로그램을 작성한다고 가정 해 보자. 응용 프로그램은 신용을 확인뿐만 아니라, StoreFrontUI 사용자 인터페이스의 실현 등 여러 구성 요소, 구성, 유지 보수 서비스에 대한 백엔드 재고 및 배송 주문의 일부. 응용 프로그램 서비스의 집합이 포함되어 있습니다.

코드 예제

크리스 리처드슨은 마이크로 서비스 예제를 개발 . Github에서의 이러한 예는 마이크로 서비스 아키텍처의 다양한 측면을 보여줍니다.

충격

이점

이 솔루션은 많은 장점을 가지고 :

큰 복잡한 응용 프로그램을 지속적으로 제공 및 배포를 지원합니다.
- 개선 된 유지 보수 - 각 서비스는 상대적으로 작고, 따라서 이해하기 쉽게 변경된다
- 더 나은 테스트 용이성 - 테스트 서비스 작고 빠른
- 더 나은 효율적 사용 - 서비스는 독립적으로 배포 할 수 있습니다
- 그것은 당신이 팀의 주위에 다수의 자율적 인 개발 작업을 구성 할 수 있습니다. 각 (두 개의 피자 소위)와 하나 개 이상의 서비스를 담당하는 팀이있다. 각 팀은 개발, 테스트, 배포 및 서비스를 확장 모든 다른 팀의 독립적이 될 수 있습니다.
각각의 마이크로 서비스는 상대적으로 작은 :
- 개발자가 이해하기 쉽게
- IDE 빠르게 개발자의 생산성을 향상시킬 수 있습니다
- 응용 프로그램은 높은 개발자의 생산성을 만드는, 빠른 시작 및 배포의 속도를 가속
향상된 장애 격리. 서비스에서 메모리 누수가있는 경우 예를 들어, 그것은 단지 서비스에 영향을 미칠 것입니다. 기타 서비스 요청을 처리 할 것입니다. 반면, 구성 요소의 단일 칩 아키텍처 부적절한 행동은 전체 시스템 충돌을 일으킬 수 있습니다.
기술 스택에 대한 장기적인 노력을 제거합니다. 새로운 서비스의 개발, 당신은 새로운 기술 스택을 선택할 수 있습니다. 마찬가지로 큰 변화가 기존의 서비스에, 당신은 새로운 기술 스택을 사용할 수있는 때를 다시 작성합니다.

결함

이 솔루션은 많은 단점이 있습니다 :

개발자는 분산 시스템의 추가 복잡성을 만들 처리해야합니다
- 개발자는 서비스 간 통신 메커니즘을 구현하고 부분적인 실패를 처리해야합니다
- 더 어려운 여러 서비스를 통해 구현 요청
- 더 어려운 시험 서비스 간의 상호 작용
- 여러 서비스를 통해 구현 요청하는 팀 간의 신중한 조정이 필요
- 개발자 도구는 / IDE는 하나의 응용 프로그램을 구축, 그것은 분산 응용 프로그램의 개발을위한 명시 적 지원을 제공하지 않습니다.
배포 복잡성. 제조에 여전히 시스템의 배치 및 관리 이루어진 서로 다른 서비스들에 의해 운영 복잡성있다.
증가 된 메모리 소비. 대안 단일체 N × M 개의 서비스 인스턴스를 사용하여 N 마이크로 아키텍처 서비스 애플리케이션 인스턴스. 각 서비스는 일반적으로 고립 된 인스턴스 필요하다 JVM 자신 (또는 이에 상응하는 서버)에서 실행중인 경우, M M 시간이 실행 오버 헤드 뷰를 생성합니다. , 비용도 높다 넷플릭스의 경우와 같이 또한, 경우 각 서비스 (예 : EC2 인스턴스)에 자신의 VM에서 실행됩니다.

문제

당신은 많은 문제를 해결해야합니다.

때 마이크로 서비스 아키텍처를 사용 하는가?

이 방법의 사용은 사용시기를 결정하기위한 도전이다. 응용 프로그램의 첫 번째 버전의 개발, 당신은 일반적으로하지이 방법으로 해결 경험 문제를 않습니다. 또한, 잘 설계된 분산 아키텍처의 사용은 개발의 속도가 느려집니다. 신생 기업의 경우,이 가장 큰 과제는 신속하게 포함 된 비즈니스 모델과 응용 프로그램을 개발하는 방법은 일반적으로 큰 문제가 될 수 있습니다. 빠른 반복 더욱 어렵게 될 수 있습니다 Y 축 분할을 사용합니다. 도전 확장하는 방법이며 기능적인 분해를 사용해야 할 때, 나중에, 얽힌 종속성 서비스의 집합으로 전체 응용 프로그램 당신을 위해 어렵게 만들 수 있습니다.

어떻게 서비스로 응용 프로그램?

또 다른 문제는 시스템이 마이크로 서비스로 구분하는 방법을 결정하는 것입니다. 이것은 예술이다,하지만 도움이 전략에는 여러 가지가 있습니다 :

비즈니스 능력에 의해 분해 및 서비스에 대응하는 비즈니스 기능을 정의합니다.
하위 도메인에 의해 분해 기반 디자인 도메인.
예 동사 또는 분해에 의해 정의 된 서비스는 특정 작업에 대한 책임이 있습니다. 이러한 전체 순서를 전송에 대한 책임 배달 서비스, 등.
명사 또는 리소스까지 서비스 중단을 정의함으로써, 서비스는 법인 / 자원의 특정 유형의 모든 작업에 대한 책임이 있습니다. 예를 들어, 서비스 계정의 사용자 계정을 관리합니다.

이상적으로, 각 서비스는 책임의 작은 부분이되어야한다. (삼촌) 밥 마틴은 단일 책임 원칙 (SRP) 디자인 과정에 온다. SRP는 변경하는 이유로 클래스의 책임을 정의하고, 클래스는 변경할 이유가 있어야 선언합니다. 서비스 디자인도 의미가에 SRP이 적용됩니다.

또 다른 비유는 서비스 디자인 유닉스 유틸리티를 수 있도록 설계되었습니다. 유닉스는 그렙, 고양이 찾기 등의 유틸리티를 제공합니다. 각 유틸리티는 일반적으로 매우 좋은 한 가지를 수행하고 복잡한 작업을 수행하는 다른 유틸리티와 함께 쉘 스크립트를 사용할 수 있습니다.

어떻게 데이터 일관성을 유지하기 위해?

느슨한 결합을 보장하기 위해, 각 서비스는 자체 데이터베이스가 있습니다. 분산 트랜잭션 제출 옵션 / 2 단계 많은 응용 프로그램이 아니기 때문에 서비스 간의 데이터 일관성을 유지하는 것은, 도전입니다. 응용 프로그램은 사가 모드를 사용해야합니다. 서비스 출판 이벤트 때 데이터가 변경됩니다. 기타 서비스는 데이터를 업데이트하기 위해이 이벤트를 사용합니다. 안정적으로 이벤트 조달 및 트랜잭션 로그 미행을 포함한 데이터 및 게시 이벤트를 업데이트하는 방법에는 여러 가지가 있습니다.

어떻게 쿼리를 구현하는 방법?

또 다른 문제는 여러 서비스에서 데이터 쿼리를 검색 할 필요를 실현하는 것입니다.

API 및 명령 책임의 조합은 분리 (CQRS) 모드를 쿼리합니다.

알려진 사용자

마이크로 서비스 아키텍처의 개발에서 단일 - 칩 아키텍처를 포함 넷플릭스, 아마존과 이베이를 포함한 대부분의 대형 사이트,.
넷플릭스는 매우 인기있는 비디오 스트리밍 서비스 인 인터넷 트래픽, 대규모, 서비스 지향 아키텍처의 최대 30 %를 담당하고 있습니다. 그들은 억 호출에 걸쳐 800 다른 장치에서 매일 비디오 스트림 API를 처리합니다. 각 API 호출은 여섯 배의 평균 백엔드 서비스를 호출됩니다.
Amazon.com 처음에 2 층 구조. 확대를 위해, 그들은 백엔드 서비스 지향 서비스의 수백 구성된 아키텍처로 마이그레이션 할 수 있습니다. 여러 응용 프로그램이 응용 프로그램 Amazon.com 웹 사이트와 웹 서비스 API의 실현을 포함하여, 이러한 서비스를 호출 할 수 있습니다. Amazon.com의 응용 프로그램은 웹 페이지를 작성하는 데 사용되는 데이터를 얻을 수 100 ~ 150 서비스를 호출합니다.
Ebay.com 경매 사이트는 서비스 지향 아키텍처 모 놀리 식 아키텍처로 진화. 개별 애플리케이션 복수의 성분으로 구성된 응용 층. 같은 구매 또는 판매 등 각 응용 프로그램의 비즈니스 로직은 특정 기능 영역. 각 어플리케이션이 X 축이 분할되어 사용 몇몇 애플리케이션 (예를 들면, 검색의 Z 축 나눗셈을 사용하여). Ebay.com 또한 X, Y 및 Z 조합 패턴은베이스 층을 확장.
마이크로 서비스 아키텍처 회사의 사용은 다른 많은 사례가 있습니다.

예

크리스 리처드슨이 예 microservices 기반 응용 프로그램을.

내보기 코드 프리즈 2018 기조 microservice 아키텍처에 좋은 소개를 제공합니다.

모드 : 마이크로 서비스 아키텍처