API 게이트웨이 대 역방향 프록시

마이크로 서비스 아키텍처를 처리하기 위해 종종 역방향 프록시 (예 : nginx 또는 apache httpd)와 함께 사용되며 교차 절단 문제 구현을 위해 API 게이트웨이 패턴이 사용됩니다 . 때때로 역방향 프록시는 API 게이트웨이의 작업을 수행합니다.
이 두 가지 접근 방식의 명확한 차이점을 확인하는 것이 좋습니다. API 게이트웨이 사용의 잠재적 인 이점은 여러 마이크로 서비스를 호출하고 결과를 집계하는 것 같습니다. API 게이트웨이의 다른 모든 책임 은 리버스 프록시를 사용하여 구현할 수 있습니다.

• 인증 (nginx LUA 스크립트를 사용하여 수행 할 수 있음)
• 운송 보안. 자체 리버스 프록시 작업입니다.
• 부하 분산
• ....

따라서이를 바탕으로 몇 가지 질문이 있습니다.

1. API 게이트웨이와 역방향 프록시를 동시에 사용하는 것이 합리적입니까 (예 : request-> Api gateway-> reverse proxy (nginx)-> concrete mictoservice)? 어떤 경우에?
2. API 게이트웨이를 사용하여 구현할 수 있고 역방향 프록시로 구현할 수없는 다른 차이점은 무엇입니까?

상호 배타적이지 않다는 것을 알게되면 생각하기가 더 쉽습니다. API 게이트웨이를 특정 유형의 역방향 프록시 구현으로 생각하십시오.

질문과 관련하여 API 게이트웨이가로드 밸런싱 및 상태 확인을 위해 역방향 프록시 뒤에있는 애플리케이션 계층으로 취급되는 경우 둘 다 함께 사용되는 것을 보는 것은 드문 일이 아닙니다. 예를 들어 웹 애플리케이션 방화벽 / API 게이트웨이가 WAF 자체 용이고 다른 하나는 통신하는 개별 마이크로 서비스를위한 역방향 프록시 계층으로 샌드위치된다는 점에서 WAF 샌드위치 아키텍처와 같은 것입니다.

차이점은 매우 유사합니다. 단지 명명법 일뿐입니다. 기본 역방향 프록시 설정을 취하고 인증, 속도 제한, 동적 구성 업데이트 및 서비스 검색과 같은 더 많은 부분을 추가하기 시작하면 사람들은이를 API 게이트웨이라고 부를 가능성이 더 큽니다.

API Gateway는 API를 통해 잠재적으로 UI를 통해 동적으로 구성 할 수있는 역방향 프록시 인 반면, 기존 역방향 프록시 (예 : Nginx, HAProxy 또는 Apache)는 구성 파일을 통해 구성되며 구성이 변경되면 다시 시작해야합니다. 따라서 라우팅 규칙 또는 기타 구성이 자주 변경 될 때 API Gateway를 사용해야합니다. 귀하의 질문에 :

1. 이 시퀀스의 모든 구성 요소가 목적에 부합하는 한 의미가 있습니다.
2. 차이점은 기능 목록이 아니라 구성 변경 사항이 적용되는 방식에 있습니다.

또한 API Gateway는 Apigee 또는 Tyk 와 같은 SAAS 형태로 제공되는 경우가 많습니다 .

또한 Node.js https://memz.co/api-gateway-microservices-docker-node-js/ 를 사용하여 간단한 API 게이트웨이를 만드는 방법에 대한 자습서가 있습니다.

도움이되기를 바랍니다.

API 게이트웨이는 일반적으로 L7 구조로 작동합니다.

API 게이트웨이는 일반 역방향 프록시에 비해 추가 기능을 제공합니다. 포털 중 일부를 고려하면 다음을 제공 할 수 있습니다.

• 문서를 포함한 전체 API 수명주기 관리
• 다양한 클라이언트 애플리케이션의 정보 소스로 사용할 수 있고 클라이언트 거버넌스, 속도 제한 등을 제공 할 수있는 포털
• 카나리아 / 베타 버전을 포함한 다양한 버전의 API로 라우팅
• 사용 패턴 감지, 앱 등록, 클라이언트 자격 증명 검색 등

그러나 Istio와 같은 서비스 메시의 출현으로 Consul은 API 게이트웨이의 많은 기능이 메시에 포함됩니다.