Using an API Gateway (feat. API gateway를 사용하지 않을 경우)

Direct Client-to-Microservice Communication (마이크로서비스 직접 호출)

• 이 패턴에서는, 클라이언트는 각 마이크로서비스에 직접 호출할 수 있습니다.
• 각 마이크로스비스는 퍼블릭한 엔드포인트를 가지고 있을 수 있습니다. ex) https://serviceName.api.company.name
• 위 URL은 마이크로서비스의 로드밸런서에 맵핑되며, 사용가능한 인스턴스에 요청을 분산시킵니다.
• 모바일 클라이언트는 위 나열된 서비스에 요청합니다.
• 이 패턴의 문제점은 각 리퀘스트를 분리해서 작성해야 된다는것입니다.
• 더 복잡한 구조의 경우 작성하는 리퀘스트가 더많아질 수 있습니다.
• 다른 문제는 일부 프로토콜은 웹 친화적이지 않다는 것입니다. 한 서비스는 RPC를 사용하고 한서비스는 AMQP메세징 프로토콜을 사용할 수 있습니다. 일반적으로 애플리케이션은 방화벽 밖에서 HTTP 또는 웹소켓과 같은 프로토콜을 사용해야만 합니다.
• 이 방법의 또다른 단점은 리팩토링 하기가 어렵다는 것입니다.
• 우리는 시간이 지남에 따라 시스템에서 서비스를 분할할 수도 있습니다. 그러나 클라이언트와 직접 통신하는 서비스의 경우 리팩토링이 매우 어려워질 수 있습니다.

Using an API Gateway (마이크로서비스를 API Gateway를 통해 호출)

• 일반적으로 API Gatewaty를 사용하는 것이 더 나은 방법입니다.
• 게이트웨이는 시스템의 싱글 엔트리 포인트의 서버입니다. 그것은 객체지향디자인의 퍼사드 패턴과 유사합니다.
• API 게이트웨이는 내부 시스템 구조를 캡슐화하고, 각 클라이언트에게 맞는 API를 제공합니다.
• 게이트웨이는 인증, 모니터링, 로드밸런싱, 캐싱, request shaping(?), 관리, 정적 응답 처리 등의 다른 책임을 가지고 있을 수 있습니다.
• API 게이트웨이는 또한 각 클라이언트에게 커스텀 API를 제공할 수도 있습니다.
• 그것은 일반적으로 모바일 클라이언트를 위한 대략적인 API를 제공합니다. 예를들어 상품 상세 시나리오를 고려할 수 있습니다.
• 게이트웨이는 해당 엔드포인트(/productdetails?productId=xxx)를 사용하면 단일 요청으로 제품 상세 정보를 모두 검색할 수 있습니다. API 게이트웨이는 다양한 서비스를 호출하여 요청을 처리합니다. (- product info, recommendation, review, etc 등) 그리고 결과를 결합합니다.
• 대부분의 마이크로 서비스 기반 응용 프로그램의 경우 단일 진입점 역할을 하는 API 게이트웨이를 구현하는 것이 좋습니다.
• API 게이트웨이는 캐시 된 데이터 또는 기본 데이터를 반환하여 백엔드 서비스의 장애를 차폐할수 도 있습니다.
• API 게이트웨이는 요청 라우팅, 구성 및 프로토콜 변환을 담당하고, 각 애플리케이션의 클라이언트에 사용자 정의 API 를 제공합니다.

 

참고 : https://www.nginx.com/blog/building-microservices-using-an-api-gateway/