Direct Client-to-Microservice Communication

이론적으로, 클라이언트는 각 개별 microservice에 직접 요청할 수 있다. 각각의 microservice는 public endpoint(https://serviceName.api.company.name)를 가지고 있다. 이 URL은 이용할 수 있는 인스턴트들에 요청을 분산처리하는 microservice의 로드밸런서와 맵핑된다. 상품 상세 정보를 얻기 위하여, 모바일 클라이언트는 위에 나열된 각각의 service들에게 요청할 것이다.

불행하게도, 이 옵션에는 여러 가지 도전과 제한이 있다. 한가지 문제는 클라이언트의 필요와 각 microservice에 의해 노출된 잘 나누어진 API사이의 부조화다. 이 예제에서 클라이언트는 7개의 분리되어 있는 요청을 해야만 한다. 더 복잡한 어플리케이션에서는 더 많은 요청을 해야만 할 것이다. 예를 들면, 아마존은 수백개의 서비스들이 상품 페이지를 다루기 위해서 호출된다. 클라이언트에서 LAN을 통해 수많은 요청을 할 때, public internet에서 너무 비효율적이 되고, 분명히 모바일 네트워크에서는 비현실적이다. 이러한 접근법은 클라이언트 코드를 훨씬 더 많이 복잡하게 할 것이다.

클라이언트가 microservice를 바로 호출하는 경우에 발생하는 또다른 문제는 웹 친화적이지 않은 프로토콜을 사용하는 경우이다. 한 서비스는 Thrift binary RPC를 사용하고, 또다른 서비스는 AMQP 메시징 프로토콜을 사용한다고 해보자. 둘 다 특히 브라우저 친화적이거나 방화벽 친화적인 프로토콜이 아니다. 그리고 내부적으로 사용하기에 가장 좋은 것도 아니다. 어플리케이션은 방화벽 밖에서 HTTP나 웹소켓과 같은 프로토콜을 사용해야 한다.

이러한 접근법의 또다른 약점은 microservice를 리팩토링하기 어렵다는 것이다. 시스템이 얼마나 서비스로 분할되었는지에 따라 우리가 변경하고자 할 때 시간이 걸릴 것이다. 예를 들어, 2개의 서비스를 통합하고자 하거나, 하나의 서비스를 2개 이상으로 나누고자 하는 경우가 있다. 그러나, 클라이언트가 직접 서비스들과 통신하고 있다면 이러한 종류의 리팩토링을 수행하는 것은 극도로 어려워질 수가 있다.

이러한 문제들 때문에 클라이언트에서 직접 microservice를 호출하게 하는 것은 전혀 이치에 맞지 않다.

받은 트랙백이 없고, 댓글이 없습니다.

댓글+트랙백 RSS :: http://www.yongbi.net/rss/response/753

 여러분은 또한 Article들의 완전체인, NGINX Plus를 사용하여 microservice를 구현하는 추가적인 정보를 제공하는 ebook - Microservices: From Design to Deployment - 을 다운로드 받을 수 있다.

전체 7가지 Article중에 첫번째 article에서는 microservice들을 디자인하고, 빌드하고, 배포하는 Microservice Architecture pattern에 대해서 소개했다. Microservice를 사용했을 때의 장점과 단점에 대해서 논의했고, microservice의 복잡성에도 불구하고 일반적으로 복잡한 application에 대해 얼마나 이상적인 선택인지에 대해서도 논의했다. 이번 두번째 시리즈에서는 API Gateway를 사용한 microservice를 빌드하는 것에 대해서 논의할 것이다.

여러분이 microservce의 집합으로 application을 빌드하는 것을 선택할 때, 여러분의 application을 호출하는 client들이 microservice와 얼마나 상호작용하는지 결정할 필요가 있다. Monolithic application에서는 (일반적으로 복제되고, 부하 분산된) 단 하나의 endpoint들의 세트가 있다. 그러나 Microservice Architecture에서는 각 개별 microservice가 잘 나누어진 endpoint들의 집합을 노출한다.

이번 Article에서는, 이것이 client-to-application communication에 얼마나 영향을 주는지를 결정하고, API Gateway를 사용하는 접근법을 제안한다.

Introduction

여러분이 쇼핑 application을 위해 native mobile application을 개발하고 있다고 가정해 보자. 주어진 상품에 대한 정보를 보여주는 상품 상세 페이지를 개발해야만 할 것이다. 예를 들어, 다음 다이어그램은 아마존 안드로이드 모바일 application에서 상세한 상품 정보를 스크롤했을 때, 여러분이 무엇을 보는 지를 보여준다.
사용자 삽입 이미지

비록 스마트폰 어플리케이션이지만, 상품 상세 페이지는 많은 정보를 보여준다. 예를 들면, 기본적인 상품정보(이름이나 설명, 가격과 같은) 뿐만 아니라 이 페이지는 다음 내용을 보여주고 있다.

- 쇼핑 카트에 있는 상품 수
- 주문 이력
- 고객 리뷰
- 낮은 재고에 대한 경고
- 배송 방법
- 이 상품을 구매한 사람들이 자주 함께 구매한 다른 상품이나 보았던 다른 상품을 포함한 다양한 추천
- 다른 구매 방법

Monolithic application architecture를 사용할 경우, 모바일 클라이언트는 어플리케이션에 한번의 REST 호출(GET api.company.com/productdetails/productId)로 이 데이터를 얻어야 한다. 로드밸런서는 일반적으로 N개의 어플리케이션 인스턴스 중 하나로 요청을 전송한다. 어플리케이션은 다양한 데이터베이스 테이블에 질의하고, 그 결과를 클라이언트로 보낼 것이다.

반대로, microservice architecture에서는 상품 상세 페이지를 보여주는 데이터를 여러 개의 microservice가 소유하고 있다. 여기 상품 상세 페이지 예제로 소유한 데이터를 보여주는 몇가지 가능성이 있는 microservice가 있다.

- 쇼핑 카트 서비스 : 쇼핑 카트에 있는 상품 수
- 주문 서비스 : 주문 이력
- 카탈로그 서비스 : 상품의 이름과 이미지, 가격과 같은 기본 상품 정보
- 리뷰 서비스 : 고객 리뷰
- 재고 서비스 : 낮은 재고 상품에 대한 경고
- 배송 서비스 : 배송방법, 마감시간, 배송 제공하는 API로부터 별도로 뽑아내진 비용
- 추천 서비스 : 추천 상품

사용자 삽입 이미지



우리는 모바일 클라이언트에서 이러한 서비스들에 어떻게 접근할 수 있을지 결정해야만 한다.
몇 가지 옵션들에 대해서 살펴보자.
받은 트랙백이 없고, 댓글이 없습니다.

댓글+트랙백 RSS :: http://www.yongbi.net/rss/response/752