[MSA] Spring Cloud Gateway

스프링 클라우드 게이트웨이 (Spring Cloud Gateway)

Spring Cloud Gateway는 API Gateway 중 하나이다.

[MSA] API Gateway

다시 말해, Spring Reactive 환경에 구현된 API Gateway다.

API Gateway의 구현체로는 Spring Cloud Gateway를 제외하고도 Zuul과 AWS API Gateway 등이 있다.

다만, 차이점에서 볼 수 있는 것처럼 Spring Cloud Gateway는 비동기 처리에 유리한 반면 Zuul은 그렇지 않다.

때문에 더 이상 Zuul을 지원하지 않고 Spring.io는 Spring Cloud Gateway를 권장한다.

 

Spring Cloud Gateway는 Spring webFlux 위에서 동작한다.

그 이유는 gateway는 많은 request를 받아 공통적인 작업을 처리하고 다른 service로 request를 전달한다.

다시 말해 동시에 처리할 수 있는 request는 많아야 하지만, 처리하는 작업이 대부분 간단하다.

이런 특징은 non-blocking server의 장점을 극대화할 수 있고, 단점은 최소화할 수 있다.

따라서 Spring Cloud Gateway는 논블로킹(non-blocking), 비동기(Asynchronous) 방식의 Netty Server를 사용한다.

 

API Gateway + Service Discovery

전체적인 과정은 다음과 같다.

1. Client 서버는 요청을 Gateway로 전달한다.
2. Gateway는 Service Discovery로 보내야 할 마이크로서비스의 정보를 discovery
3. Gateway가 마이크로서비스로 연결

이렇게 되면 다음과 같은 장점들이 존재한다.

• 각각의 마이크로서비스들은 서로의 포트 번호를 몰라도 된다.
• Front에서는 요청을 Gateway로만 보내면 되기 때문에 Gateway 포트만 알면 모든 요청을 수행할 수 있다.
• 모든 요청은 Gateway를 거치기 때문에 로그를 쉽게 다룰 수 있다.
• Gateway가 요청의 진입점이므로 통합 인증을 수행할 수 있다.

---

Spring Cloud Gateway의 3가지 옵션

• Route : 응답을 보낼 목적지 uri와 필터 항목을 식별하기 위한 ID로 구성되어 있고 라우팅 목적지를 의미한다.
• Predicate : 요청을 처리하기 전 HTTP 요청이 정의된 조건에 부합하는지 검사한다.
• Filter : 게이트웨이에서 받은 요청과 응답을 수정하는 역할이다.

1. Client는 Spring Cloud Gateway에 요청을 보낸다.
2. Gateway Handler Mapping에서 해당 요청에 대한 Route와 Predicates가 일치한다고 판단하면 해당 요청은 Gateway Web handler로 보내진다.
3. handler에서 Filter Chain을 이용해서 사전 필터 혹은 사후 필터로 나누어 동작한다.
4. 필터링이 된 후 실제 마이크로서비스에 전달된다.

 

application.yml 예시

위의 예시를 보면 eureka.client를 보면 Service Discovery를 연결해 놓았다. 

API Gate 또한 유레카 입장에서는 서비스 중의 하나다. 따라서 Eureka client 설정 코드를 추가해주어야 한다.

---

참고 자료:

https://velog.io/@gowjr207/%EC%8A%A4%ED%94%84%EB%A7%81-%ED%81%B4%EB%9D%BC%EC%9A%B0%EB%93%9C-%EA%B2%8C%EC%9D%B4%ED%8A%B8%EC%9B%A8%EC%9D%B4%EB%A5%BC-%EC%84%A4%EB%AA%85%ED%95%B4%EB%B3%B4%EB%8B%A4

스프링 클라우드 게이트웨이를 설명해보다.

https://wonit.tistory.com/497

Spring Cloud Gateway 를 이용해 API Gateway를 구성하고 실습해보자 (Eureka Server 를 이용해 Load Balancing 하