마이크로 서비스 오케스트레이션의 표준 패턴은 무엇입니까?
마이크로 서비스가 자신의 도메인에 대해서만 알고 있지만 여러 서비스가 어떤 방식으로 상호 작용해야하는 데이터 흐름이있는 경우 어떻게해야합니까?
다음과 같은 것이 있다고 가정 해 봅시다.
그리고 인수를 위해 주문이 배송되면 송장이 생성되어야한다고 가정 해 봅시다.
어딘가에서 누군가의 버튼을 누르면 GUI"완료되었습니다." 고전적인 모놀리스 서비스 아키텍처에서 이것을 ESB처리하거나 배송 서비스가 송장 서비스에 대한 지식을 가지고 있다고 말합니다.
그러나이 용감한 새로운 마이크로 서비스 세계에서 사람들이이 문제를 다루는 방법은 무엇입니까?
나는 이것이 의견에 근거한 것으로 간주 될 수 있다고 생각한다. 그러나 마이크로 서비스는 위와 같이하지 않기 때문에 구체적인 측면이 있습니다. 따라서 의견 기반이 아닌 "정의 적으로해야 할 일"이 있어야합니다.
사격.
답변:
Book Building Microservices 는 @RogerAlsing이 언급 한 스타일을 자세하게 설명합니다.
오케스트레이션 대 안무에서 43 페이지에이 책은 다음과 같이 말합니다.
점점 더 복잡한 논리를 모델링하기 시작하면서 개별 서비스의 경계를 넘어 비즈니스 프로세스를 관리하는 문제를 해결해야합니다. 마이크로 서비스를 사용하면 평소보다 더 빨리이 한도에 도달 할 것입니다. [...] 실제로이 흐름을 구현할 때 따라야 할 두 가지 스타일의 아키텍처가 있습니다. 오케스트레이션을 통해 오케스트라의 지휘자와 마찬가지로 프로세스를 안내하고 추진하기 위해 중앙 두뇌에 의존합니다. 안무를 통해 우리는 시스템의 각 부분에 작업을 알려주고 댄서들이 자신의 길을 찾고 발레로 주변의 다른 사람들과 반응하는 것처럼 세부 사항을 해결하게합니다.
그런 다음이 책은 두 가지 스타일을 설명합니다. 오케스트레이션 스타일은 오케스트레이션 / 태스크 서비스 에 대한 SOA 아이디어에 더 부합 하지만, 안무 스타일 은 Martin Fowler의 기사에서 언급 한 멍청한 파이프와 스마트 엔드 포인트에 해당합니다 .
오케스트레이션 스타일
이 스타일에서 위의 책은 다음을 언급합니다.
이 흐름에 오케스트레이션 솔루션이 어떻게 보일지 생각해 봅시다. 여기서 가장 간단한 방법은 고객 서비스가 중앙 두뇌 역할을하는 것입니다. 작성시, 일련의 요청 / 응답 호출을 통해 충성도 포인트 은행, 이메일 서비스 및 우편 서비스 [...]와 대화합니다. 그런 다음 고객 서비스 자체는 고객이이 프로세스에서 어디에 있는지 추적 할 수 있습니다. 고객의 계정이 설정되어 있는지, 이메일이 발송되었는지 또는 전달 된 게시물인지 확인할 수 있습니다. 플로우 차트 [...]를 가져 와서 코드로 직접 모델링합니다. 적절한 규칙 엔진을 사용하여이를 구현하는 툴링을 사용할 수도 있습니다. 이러한 목적을 위해 상용 프로세스 도구는 비즈니스 프로세스 모델링 소프트웨어 형태로 존재합니다. 동기 요청 / 응답을 사용한다고 가정하면, 우리는 심지어 각 단계가 효과가 있었는지 알 수있었습니다. [...]이 오케스트레이션 접근법의 단점은 고객 서비스가 너무 많은 중앙 관리 기관이 될 수 있다는 것입니다. 웹 한가운데의 허브이자 논리가 시작되는 중심점이 될 수 있습니다. 이 접근 방식을 통해 빈약 한 CRUD 기반 서비스에 수행 할 작업을 알려주는 적은 수의 스마트“신”서비스가 등장했습니다.
참고 : 저자가 툴링을 언급 할 때 BPM 과 같은 것을 언급한다고 가정합니다 (예 : Activity , Apache ODE , Camunda ). 실제로 워크 플로 패턴 웹 사이트 에는 이러한 종류의 오케스트레이션을 수행 할 수있는 멋진 패턴 세트가 있으며 이러한 방식으로 구현하는 데 도움이되는 여러 공급 업체 도구에 대한 평가 세부 정보도 제공합니다. 필자는 저자가 이러한 도구 중 하나를 사용하여 이러한 스타일의 통합을 구현해야한다고 생각하지는 않지만 다른 경량 오케스트레이션 프레임 워크 (예 : Spring Integration )를 사용할 수 있습니다 . Apache Camel 또는 Mule ESB
그러나 다른 책들 Microservices 주제에 대해 읽은 과 일반적으로 웹에서 찾은 대부분의 기사는 이러한 오케스트레이션 접근 방식 을 선호 하지 않고 다음 책을 사용하는 것이 좋습니다.
안무 스타일
안무 스타일에서 저자는 다음과 같이 말합니다.
안무적인 접근 방식을 사용하면 고객 서비스가 비동기 방식으로 이벤트를 생성하여 고객이 생성했다고 말할 수 있습니다. 전자 메일 서비스, 우편 서비스 및 충성도 포인트 은행은 이러한 이벤트에 가입하고 이에 따라 반응합니다 ...]이 방법은 훨씬 더 분리되어 있습니다. 다른 서비스가 고객 생성에 도달해야하는 경우 이벤트를 구독하고 필요할 때 작업을 수행하면됩니다. 단점은 [워크 플로]에서 볼 수있는 비즈니스 프로세스에 대한 명시적인 관점이 이제 시스템에 암시 적으로 만 반영된다는 것입니다 ... [...] 이는 올바른 일을 모니터링하고 추적 할 수 있도록 추가 작업이 필요하다는 것을 의미합니다. 일어난. 예를 들어 포인트 포인트 은행에 버그가 있는지, 어떤 이유로 올바른 계정을 설정하지 않았는지 알고 있습니까? 이 문제를 다루는 방법 중 하나는 [워크 플로]에서 비즈니스 프로세스의 관점과 명시 적으로 일치하는 모니터링 시스템을 구축 한 다음 각 서비스가 독립 엔터티로 수행하는 작업을 추적하여 이상한 예외가 보다 명확한 프로세스 흐름. [flowchart] [...]는 원동력이 아니라 시스템이 어떻게 동작하는지 볼 수있는 하나의 렌즈입니다. 일반적으로, 나는 안무 접근법으로 향하는 경향이있는 시스템이 더 느슨하게 결합되어 있고, 더 유연하고 변화하기 쉽다는 것을 발견했다. 그러나 시스템 경계에 걸쳐 프로세스를 모니터링하고 추적하려면 추가 작업이 필요합니다. 가장 많이 조정 된 구현은 변경 비용이 높을수록 취성이 매우 높은 것으로 나타났습니다. 그런 점을 염두에두고 안무 시스템을 목표로하는 것이 좋습니다. 각 서비스는 전체 무용에서의 역할을 이해할만큼 똑똑합니다.
참고 : 오늘날까지 안무가 EDA ( Event-Driven Architecture)의 또 다른 이름인지는 확실하지 않지만 EDA가 그것을 수행하는 한 가지 방법이라면 다른 방법은 무엇입니까? (또한 참조 하면 "이벤트 구동 형"에 의해 무슨 뜻 이죠? 와 이벤트 중심 아키텍처의 의미 ). 또한 CQRS 및 EventSourcing과 같은 것들이이 아키텍처 스타일에서 많은 공명을하는 것 같습니다.
이제 재미가 온다. 마이크로 서비스 책은 마이크로 서비스가 REST로 구현 될 것이라고 가정하지 않습니다. 실제로이 책의 다음 섹션에서는 RPC 및 SOA 기반 솔루션을 고려하고 마지막으로 REST를 고려합니다. 여기서 중요한 점은 마이크로 서비스가 REST를 의미하지 않는다는 것입니다.
그렇다면 HATEOAS는 어떻습니까? (응용 프로그램 상태 엔진으로서의 하이퍼 미디어)
RESTful 접근 방식을 따르고 싶다면 HATEOAS를 무시할 수 없으며 Roy Fielding은 그의 블로그에서 솔루션이 진정으로 REST가 아니라는 것을 매우 기쁘게 생각합니다. 그의 블로그 게시물을 참조하십시오 REST API는 하이퍼 텍스트가 구동되어야한다 :
HTTP 기반 인터페이스를 REST API로 호출하는 사람들의 수에 좌절하고 있습니다. 하이퍼 텍스트가 제약 조건이라는 개념에서 REST 아키텍처 스타일을 명확하게하려면 무엇을해야합니까? 다시 말해, 애플리케이션 상태 엔진 (및 API)이 하이퍼 텍스트에 의해 구동되지 않으면 RESTful이 될 수없고 REST API가 될 수 없습니다. 기간. 수정해야 할 어딘가에 깨진 매뉴얼이 있습니까?
보시다시피 Fielding은 HATEOAS가 없으면 진정으로 RESTful 응용 프로그램을 작성하지 않는다고 생각합니다. Fielding의 경우, HATEOAS는 오케스트레이션 서비스를 수행 할 때 사용하는 방법입니다. 나는이 모든 것을 배우고 있지만, HATEOAS는 실제로 링크를 따라가는 원동력이 누구인지 또는 무엇인지 명확하게 정의하지 않습니다. 사용자가 될 수 있지만 컴퓨터 대 컴퓨터 상호 작용의 UI에서는 더 높은 수준의 서비스가 필요하다고 생각합니다.
HATEOAS에 따르면 API 소비자가 진정으로 알아야 할 유일한 링크는 서버와의 통신을 시작하는 링크 (예 : POST / order)입니다. 이 시점부터 REST는 플로우를 수행합니다.이 엔드 포인트의 응답으로 리턴 된 자원에는 다음 가능한 상태에 대한 링크가 포함되기 때문입니다. 그런 다음 API 소비자는 따라야 할 링크를 결정하고 응용 프로그램을 다음 상태로 옮깁니다.
소리가 얼마나 멋진 지에도 불구하고 클라이언트는 링크를 POST, PUT, GET, PATCH 등으로해야하는지 알아야합니다. 클라이언트는 여전히 어떤 페이로드를 전달해야하는지 결정해야합니다. 클라이언트는 여전히 실패한 경우 수행 할 작업 (재시도, 보상, 취소 등)을 알고 있어야합니다.
나는이 모든 것에 상당히 익숙하지만, HATEOA의 관점에서 볼 때,이 클라이언트 또는 API 소비자는 높은 수준의 서비스입니다. 우리가 인간의 관점에서 생각한다면, 웹 페이지에서 최종 사용자가 어떤 링크를 따라야하는지 상상할 수 있지만 여전히 웹 페이지의 프로그래머는 링크를 호출하는 데 사용할 방법을 결정해야했습니다. 전달할 페이로드 따라서 컴퓨터 간 상호 작용에서 컴퓨터는 최종 사용자의 역할을합니다. 다시 한 번 이것을 오케스트레이션 서비스라고합니다.
오케스트레이션이나 안무와 함께 HATEOAS를 사용할 수 있다고 가정합니다.
API 게이트웨이 패턴
Chris Richardson은 API Gateway Pattern 이라고 제안한 또 다른 흥미로운 패턴을 제안합니다 .
모 놀리 식 아키텍처에서 웹 브라우저 및 기본 애플리케이션과 같은 애플리케이션 클라이언트는로드 밸런서를 통해 애플리케이션의 동일한 N 개 인스턴스 중 하나에 HTTP 요청을합니다. 그러나 마이크로 서비스 아키텍처에서 단일체는 서비스 모음으로 대체되었습니다. 결과적으로, 우리가 대답해야 할 중요한 질문은 고객이 무엇과 상호 작용 하는가입니다.
기본 모바일 응용 프로그램과 같은 응용 프로그램 클라이언트는 개별 서비스에 RESTful HTTP 요청을 할 수 있습니다 ...] 표면적으로 이것은 매력적으로 보일 수 있습니다. 그러나 개별 서비스의 API와 클라이언트가 필요로하는 데이터간에 세분성이 크게 일치하지 않을 수 있습니다. 예를 들어, 하나의 웹 페이지를 표시하려면 많은 서비스에 대한 호출이 필요할 수 있습니다. 예를 들어 Amazon.com은 다음과 같이 설명합니다. 일부 페이지에서 100 개 이상의 서비스를 호출하는 방법을 합니다. 대역폭이 낮고 대기 시간이 긴 모바일 네트워크는 물론 고속 인터넷 연결을 통해서도 많은 요청이 매우 비효율적이며 사용자 경험이 좋지 않습니다.
훨씬 더 나은 방법은 클라이언트가 인터넷을 통해 페이지 당 적은 수의 요청을 인터넷을 통해 API 게이트웨이라고하는 프런트 엔드 서버에 만드는 것입니다.
API 게이트웨이는 애플리케이션의 클라이언트와 마이크로 서비스 사이에 있습니다. 클라이언트에 맞는 API를 제공합니다. API 게이트웨이는 모바일 클라이언트에 굵은 API를 제공하고 고성능 네트워크를 사용하는 데스크탑 클라이언트에 더 세분화 된 API를 제공합니다. 이 예에서 데스크탑 클라이언트는 제품에 대한 정보를 검색하기 위해 여러 요청을하는 반면 모바일 클라이언트는 단일 요청을합니다.
API 게이트웨이는 고성능 LAN을 통해 몇 개의 마이크로 서비스에 요청함으로써 들어오는 요청을 처리합니다. 예를 들어, Netflix는 각 요청이 평균 6 개의 백엔드 서비스로 팬 아웃되는 방식을 설명 합니다. 이 예에서 데스크톱 클라이언트의 세분화 된 요청은 해당 서비스로 프록시되는 반면 모바일 클라이언트의 각 세분화 된 요청은 여러 서비스 호출 결과를 집계하여 처리됩니다.
API 게이트웨이는 클라이언트와 애플리케이션 간의 통신을 최적화 할뿐만 아니라 마이크로 서비스의 세부 사항을 캡슐화합니다. 이를 통해 클라이언트에 영향을주지 않고 마이크로 서비스를 발전시킬 수 있습니다. 예를 들어, 두 개의 마이크로 서비스가 병합 될 수 있습니다. 다른 마이크로 서비스는 두 개 이상의 서비스로 분할 될 수 있습니다. 이러한 변경 사항을 반영하려면 API 게이트웨이 만 업데이트하면됩니다. 클라이언트는 영향을받지 않습니다.
API 게이트웨이가 애플리케이션과 클라이언트 간을 중재하는 방법을 살펴 봤으므로 이제 마이크로 서비스 간 통신을 구현하는 방법을 살펴 보겠습니다.
이것은 약간 다른 의도로 위에서 언급 한 오케스트레이션 스타일과 매우 비슷하게 들립니다.이 경우 상호 작용의 성능과 단순화에 관한 것 같습니다.
다른 접근법을 모 으려고합니다.
이에 대한 지배적 인 접근 방식은 도메인 이벤트를 사용하는 것으로 보이며, 각 서비스는 발생한 상황에 대한 이벤트를 게시하고 다른 서비스는 해당 이벤트를 구독 할 수 있습니다. 이것은 Martin Fowler가 설명하는 스마트 엔드 포인트, 멍청한 파이프 의 개념과 밀접한 관련이있는 것 같습니다 .
일반적으로 보이는 또 다른 접근 방식은 비즈니스 흐름을 자체 서비스로 래핑하는 것입니다. 프록시가 아래 그림과 같이 마이크로 서비스 간의 상호 작용을 오케스트레이션하는 경우 :
.
이 페이지 에는 다양한 컴포지션 패턴 이 포함되어 있습니다.
그렇다면 마이크로 서비스 오케스트레이션은 "마이크로"가 아닌 기존 SOA 서비스 오케스트레이션과 어떻게 다릅니 까? 별로.
마이크로 서비스는 일반적으로 http (REST) 또는 메시징 / 이벤트를 사용하여 통신합니다. 오케스트레이션은 종종 서비스 간 스크립트 상호 작용을 만들어 워크 플로를 자동화 할 수있는 오케스트레이션 플랫폼과 연결됩니다. 이전 SOA 시대에 이러한 플랫폼은 WS-BPEL을 사용했습니다. 오늘날의 도구는 BPEL을 사용하지 않습니다. 최신 오케스트레이션 제품의 예 : Netflix Conductor, Camunda, Zeebe, Azure Logic Apps, Baker.
오케스트레이션은 복잡한 서비스 구성을 생성 할 수있는 여러 기능을 제공하는 복합 패턴입니다. 마이크로 서비스는 복잡한 구성에 참여하지 않고보다 자율적 인 서비스로 간주되는 경우가 많습니다.
간단한 처리를 수행하기 위해 오케스트레이션 워크 플로에서 마이크로 서비스가 호출되는 것을 볼 수 있지만 트랜잭션 및 상태 저장소 (탈수) 보정과 같은 메커니즘을 사용하는 오케 스트레이터 서비스 인 마이크로 서비스는 보이지 않습니다.
따라서 두 가지 서비스가 있습니다.
실제로는 주문 상태를 유지할 수있는 무언가가 있습니다. 주문 서비스라고합시다. 다음으로 주문 처리 유스 케이스가 있는데, 주문이 한 상태에서 다른 상태로 전환 될 때 수행 할 작업을 알고 있습니다. 이 모든 서비스에는 특정 데이터 세트가 포함되어 있으므로 이제 모든 조정을 수행하는 다른 것이 필요합니다. 이것은 다음과 같습니다.
이것의 핵심은 컨트롤이 외부라는 것입니다. 모든 애플리케이션 구성 요소가 느슨하게 연결된 개별 빌딩 블록이기 때문입니다. 사용 사례가 변경되면 오케스트레이션 구성 요소 인 한 구성 요소를 한 곳에서 변경해야합니다. 다른 주문 흐름을 추가하면 첫 번째 주문을 방해하지 않는 다른 오케 스트레이터를 쉽게 추가 할 수 있습니다. 마이크로 서비스 사고는 확장 성 및 멋진 REST API 수행뿐만 아니라 명확한 구조, 구성 요소 간의 종속성 감소, 비즈니스 전체에서 공유되는 공통 데이터 및 기능의 재사용에 관한 것입니다.
HTH, 마크
나는이 주제에 대한 몇 가지 게시물을 작성했습니다 :
이 게시물이 도움이 될 수도 있습니다.
API Gateway 패턴-코스 그레인 API 및 세분화 된 API
https://www.linkedin.com/pulse/api-gateway-pattern-ronen-hamias/ https://www.linkedin.com/pulse/successfulapi-ronen-hamias/
대략적인 서비스와 미세한 서비스 API
정의에 따르면, 대략적인 서비스 작업은 세부적인 서비스보다 범위가 넓지 만 용어는 상대적입니다. 설계 복잡성이 거칠지 만 작업을 완료하는 데 필요한 호출 수를 줄일 수 있습니다. 마이크로 서비스 아키텍처에서 굵은 단위는 API 게이트웨이 계층에 상주하여 특정 비즈니스 운영을 완료하기 위해 여러 마이크로 서비스를 조정합니다. 서로 다른 전문 영역을 관리하면 단일 API에서 혼합 문제가 발생하여 위에서 설명한 규칙을 위반할 위험이있는 여러 마이크로 서비스가 포함되도록 굵은 API를 신중하게 설계해야합니다. 거친 API는 달리 존재하지 않는 비즈니스 기능에 대해 새로운 차원의 세분성을 제안 할 수 있습니다. 예를 들어, 고용 직원은 직원 ID를 작성하기 위해 HR 시스템에 대한 두 개의 마이크로 서비스 호출과 사용자 계정을 작성하기 위해 LDAP 시스템에 대한 다른 호출을 포함 할 수 있습니다. 또는 클라이언트가 동일한 태스크를 달성하기 위해 두 개의 세분화 된 API 호출을 수행했을 수 있습니다. 굵은 단위는 비즈니스 사용 사례 작성 사용자 계정을 나타내는 반면, 세분화 된 API는 이러한 작업과 관련된 기능을 나타냅니다. 더욱 세분화 된 API는 서로 다른 기술과 통신 프로토콜을 포함 할 수 있지만, 거친 세분화 된 API는 통합 된 흐름으로 추상화됩니다. 시스템을 설계 할 때 모든 것을 해결하는 황금 접근 방식이 없으며 각각에 대한 절제가 있습니다. 굵은 단위는 특히 다른 응용 프로그램과 같은 다른 비즈니스 상황에서 사용되는 서비스로 적합합니다.
원래 질문에 대한 대답은 SAGA 패턴입니다.