RestTemplate, FeignClient / WebClient 차이, 소개

Archives

Today

Total

관리 메뉴

지나공 : 지식을 나누는 공간

RestTemplate, FeignClient / WebClient 차이, 소개 본문

지식 간단 정리!

RestTemplate, FeignClient / WebClient 차이, 소개

해리리_ 2023. 2. 12. 18:34

서론

우리 회사 프로젝트는 MSA 구조를 이루고 있는데 그동안 나는 다른 MS를 호출할 업무가 없었어서 직접 써본 적은 없었다. 근데 이번에 FeignClient로 다른 MS의 API를 호출할 일이 생겨서, 외부 API를 호출하는 여러가지 통신 방법들과 간단하게 비교하려고 한다. 이번 포스팅은 스윽 훑어보는 거라 아직 제대로 흡수하지 못한 특징들도 있는데, 앞으로 구체적인 사용법을 공부할 예정이다.

Spring Cloud

MSA의 개발, 배포, 운영에 필요한 아키텍처를 쉽게 구성할 수 있도록 지원하는 Spring Boot 기반의 프레임워크.

MSA를 위한 환경설정, 서비스 검색, 라우팅, 프록시 등 분산시스템 설정을 빠르게 할 수 있도록 도와준다.

여기서 지원하는 요소들은 대표적으로 아래와 같은데 이번 포스팅의 주인공은 서비스 간 통신 방식이어서 일단 다른 설명은 넣어둔다..!

Config Server
Naming Server(Eureka) & Spring Cloud Gateway
서비스 간 통신 방식 (API를 호출해야지 서로!) : RestTemplate, Open Feign
모니터링 방식

우리가 보려는 애들은 서비스 간 통신 방식이다.

결론부터! Open Feign(Feign Client) vs RestTemplate vs WebClient

일단 Open Feign이랑 RestTemplate은 둘다 동기/블로킹이고, WebClient는 비동기 논블로킹이다. 그래서 Feign & RestTemplate은 WebClient랑 결이 좀 다르다. 아무래도 WebClient가 비동기이다 보니 트래픽이 많아지면 성능이 다른 애들보다 좋은데, 비동기라서 러닝커브도 크니까 아주 크나큰 프로젝트인게 아닌 이상 그냥 Open Feign을 쓴다고 한다.

그럼 이제 WebClient는 떼어냈고, 같은 결인 Open Feign이랑 RestTemplate을 비교해보자.

	RestTemplate	OpenFeign
기본 코드 예제	대충 봐도 호출하는 메소드 안에서 적는 정보가 많다. 설정 정보를 호출하는 메소드가 다 가지고 있다.	인터페이스에 따로 빼두고, 호출을 원하는 쪽에서는 메소드만 호출한다. 설정 정보는 알 바 아니다.
관심사의 분리	둘다 Login Response에서 NaverProfile API를 호출하고 있다. 만약 NaverProfile의 API의 URI가 바뀔 때 RestTemplate은 직접 호출하는 메소드 부분에 헤더 같은 설정정보가 다 있으니 Login Response가 같이 책임지게 된다. 반면 Open Feign은 주요 관심사가 아닌 설정 정보들은 인터페이스에서 설정하고, 직접 호출하는 부분은 그냥 메소드만 적혀 있으니까 LoginResponse는 본인이 반환 받을 객체에 대해서만 책임을 가져간다.
예외 처리	만약 Login Responese가 NaverProfile 호출할 때 없는 유저에 대한 정보로 요청한다고 가정하자. NaverProfile 측에서는 없는 유저에 대한 요청이므로 서버가 요청받은 리소스를 찾을 수 없다는 404 Not Found 를 준다. 근데 RestTemplate을 쓰면 Login Response 입장에서는 NaverProfile의 내부 문제로 인해 응답을 못 받은 거니까 Internal Server Error가 발생했나보다 하며 500을 준다. 실제론 500이 아니라 404를 반환하는게 맞잖아?? 이런 문제를 대처할 때 Rest Template은 try-catch로 예외처리를 하지만, Open Feign은 예외 핸들링을 위한 Error Decoder를 제공한다.
테스트 용이성	단위테스트를 위해서는 외부 모듈과의 의존 관계를 끊는 게 좋다. 그래서 보통은 의존 관계를 끊고 mock 객체를 만들어서 stubbing 한다. 근데 RestTemplate을 주입받게 되면 그 내부의 exchange를 어떻게 stubbing 할 때 uri 추가되면 그것대로 또 매핑을 추가해주고 번거롭다. 그러나 feign은 호출하는 측이 가져가는 책임이 feign 인터페이스가 반환하는 객체 타입 뿐이니까 uri 바뀌고 추가되고 이런거는 몰라도 된다. 테스트하기 용이함.
최종 의견	호출하는 메소드가 들고 다니는 정보가 참 많다. 핵심은 그냥 내가 널 호출하는 건데.. 설정 정보를 호출하는 측에서도 다 들고 다닌다.	사용하는 메소드 측에서는 한 줄로 끝날 정도로 간단하다. 고치고 바뀌고 하는 설정 정보는 다 인터페이스가 책임지니까.

비교는 여기까지고 아래는 구체적인 특징을 적었다.

OpenFeign

Netflix에 의해 처음 만들어진 Declarative(선언적인, 어노테이션만 써놔도 알아서 구현체가 생기는) HTTP Client 도구로, 외부 API를 호출할 때 사용한다.

Netflix에서 개발한 HTTP Client Binder
웹서비스 클라이언트를 좀 더 쉽게 작성할 수 있다.
인터페이스를 작성하고 어노테이션 선언만 하면 된다. Spring Data JPA에서 실제 쿼리를 쓰지 않더라도 인터페이스만 지정할 때 쿼리 실행 구현체를 자동으로 만들어주는 것과 비슷하다.

등장배경

OpenFeign의 초기모델인 Feign은 Netflix OSS(?? 이게 뭔지 나중에..) 프로젝트의 일부인데 Netflix OSS가 공개되고 나서 Spring Cloud 진영은 Spring Cloud Netflix라는 프로젝트를 통해서 넷플릭스를 자기네 생태계를 포함시켰다. 여기서 Feign이 단독으로 쓰일 수 있도록 별도의 starter가 제공됐는데, 이후 넷플릭스가 내부적으로 feign의 사용 및 개발을 중단했고, feign은 OpenFeign이라는 새 이름으로 오픈소스 커뮤니티에 공개되었다. 이후 차차 Spring에서 사용되는 것과 동일한 HttpMessageConverter를 사용하도록 확장되고 다른 spring cloud 기술인 eureka나 circuit breaker나 load balancer도 통합한 http client로 성장했다.... 고 한다.

netflix oss -> spring cloud netflix -> open feign -> spring cloud open feign

RestTemplate

얘도 똑같이 REST API를 호출할 수 있는 Spring 의 내장 클래스다.
Spring 3.0부터 지원됐고 json, xml을 모두 지원하며 멀티스레드 방식을 사용한다. Spring 5.0부터는 deprecated 됐다.
앞서 말한 것처럼 Blocking 동기 방식이다. Spring 5.0부터 WebFlux와 함께 기존의 동기 방식 외에도 비동기까지 지원해버리는 WebClient 가 소개됐다. 이때부터 rest template 은 derecated 된다.