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 게이트웨이가 애플리케이션과 클라이언트 간을 중재하는 방법을 살펴 봤으므로 이제 마이크로 서비스 간 통신을 구현하는 방법을 살펴 보겠습니다.

이것은 약간 다른 의도로 위에서 언급 한 오케스트레이션 스타일과 매우 비슷하게 들립니다.이 경우 상호 작용의 성능과 단순화에 관한 것 같습니다.

---

답변