FeignClient - Spring Cloud 에서 제공하는 HTTP 클라이언트

 

 

포스팅 목적 !! - Fegin Clien 정리할 것  

1.개념
2.사용법 
3.인터페이스로 구현된 이유 

 

 

 

Feign Client 란 ? 

 

- Spring Cloud 에서 제공하는 HTTP 클라이언트

- 다른 서버의 REST API 를 인터페이스만으로 쉽게 호출할 수 있는 도구 

 

 

특징 + 사용 예시 

 

Fegin Client 의 장점에 대해 다른 HTTP 클라이언트와 비교 ! 

 

1. 인터페이스만 정의하면 사용 가능하다

 

# 예시 

RestTemplate 를 사용하여 HTTP 요청 

RestTemplate restTemplate = new RestTemplate();
UsetDto user = restTemplate.getForObject(
	"http://api.example.com/users/1", UserDto.class
};

 

 

FeignClient사용

- 인터페이스 정의만으로 Spring 이 내부적으로 구현체 자동 생성  ( 프록시 기반 )

@FeignClient(name="user-api", url="https://api.example.com")
public pinterface UserClient {
    @GetMapping("/user/{id)")
    UserResponse getUserById(@PathVariable("id") Long id);  
}

 

 

 

2. 간결한 코드 

- RestTemplate, WebClient 에 비해 훨씬 짧고 간결한 코드로 API를 호출가능함 

 

# 예시

RestTemplate 로 외부 API 호출 시 매번 HTTP 요청, 응답 처리, 예외 처리 코드를 반복해야 함 

HttpHeaders headers = new HttpHeaders();
headers.setContentType(MediaType.APPLICATION_JSON);

HttpEntity<Void> request = new HttpEntity<>(headers);

ResponseEntity<UserDto> response = restTemplate.exchange(
	"http://api.excample.com/users/1",
    HttpMethod.GET,
    request,
    UserDto.class
);

UserDto user = response.getBody();

 

 

FeginClient는 메소드 호출하듯 작성 가능 

UserDto user = userClient.getUser(1L);

 

 

 

3. 서비스 간 통신에 유리하다

- 마이크로서비스 아키텍처에서 자주 사용된다

 

# 예시 

 

서비스가 여러 개로 분리되어 있을 때, 각 서비스끼리 HTTP 통신을 자주해야 한다고 하자

매번 API 호출 코드를 작성해야하는데 번거로울 뿐더러 에러 발생 가능성이 그만큼 많아진다.

( 위의 예시 2번 에서 RestTemplate 를 사용해서 요청을 보내는걸 100개 한다고 생각하면 ㄷㄷ ) 

 

FeginClient 는 그에 반해 간결하게 사용할 수 있다는 것이 장점이다. 

 

 

 

4. Load Balancer, Retry, Fallback 등과 연동 가능하다

- Spring Cloud Netflix, Resilience4j 등과 함께 사용하면 기능 확장이 쉽다 

 

# 예시 

서버 여러개가 떠있는데 하나는 응답이 느리고 어떤 서버는 일시적으로 다운되어있다고 가정해보자

이런 상황에서도 사용자에게 안정적인 응답을 줘야한다

 

이때 FeginClient 를 사용하면 확장성이 높아 장애 대응에 유리하다는 것 같은데.. 이부분은 이해가 잘 가지 않아서 각각의 개념에 대해서만 간단히 정리할까 한다 

 

# FeginClient 확정성 관련 주요 개념 설명

• Load Balancer (로드 밸런서)
  • 여러 서버(인스턴스) 중 하나를 자동으로 선택해서 요청을 보내주는 기능
  • 예시 ) user-service 라는 이름으로 서버가 3개 떠 있다면, 그 중 하나에 자동으로 요청이 분산됨
  • Fegin에서 연동 방식
    • @FeginClient(name = "user-service") 라고 쓰면 내부적으로 user-service라는 이름을 Eureka 에서 조회하여 살아있는 인스턴스를 하나 골라서 요청 전송 
  • 장점인 이유?
    • 서버를 늘려도 클라이언트 코드를 바꿀 필요 없음
    • 장애 난 서버를 자동으로 제외하고 정상 서버로만 요청 보냄
• Retry
  • 요청 실패 시 자동으로 다시 요청하는 기능
  • 타임아웃 발생 시 1~2번 더 시도함 
  • Spring Retry 또는 Resilience4j를 사용하여 자동 재시도 설정 가능
  • 장점인 이유?
    • 일시적인 네트워크 장애에 강함
    • 사용자 입장에서 실패율이 줄어듬 ( 계속 다시 시도하니까 - ? )

# yaml 설정

feign:
	client:
    		config:
        	 	default:
            	 		retryer:
                			max-attempts: 3

( 들여쓰기 제대로 안먹노 ~~~ ) 

 

• Fallback ( 대체 응답 )
  • 호출한 서버가 죽었거나 실패했을 때, 미리 정해둔 응답으로 대체하는 기능
  • 예시 ) user-service 가 죽었을 때 
  • @FeignClient(name = "user-service", fallback = UserFallback.class)
  • 장점인 이유?
    • 한 서비스 장애가 전체 장애로 번지지 않게 막아줌
    • 사용자 경험이 좋아짐 ( 에러 대신 대체 응답 제공 )
• Circuit Breaker (서킷 브레이커)
  • 호출 실패가 일정 횟수 이상 발생하면, 일정 시간 동안 호출 자체를 차단하는 기능
  • 예시 ) 5번 연속 실패 -> 1분 동안 요청을 안보냄 ( 대신 fallback 실행 ) 
  • 장점인 이유? 
    • 계속 실패하는 서버에 무의미한 요청을 보내지 않음으로서 시스템 안정성이 증가한다
    • 전체 시스템이 과부화로 무너지지 않게 보호한다 

 

이런 장점들은 Feign + Spring Cloud 조합일 때 제공 된다는 것 !!!! 

 

 

마이크로 서비스 구조

하나의 큰 서비스를 여러 개의 작은 서비스로 쪼개서 운영하는 구조

ex) 
사용자 관리 전용 서버 : user-service
상품 관리 전용 서버 : product-service
주문 처리 전용 서버 : order-service 

각 서비스는 독립적으로 배포되고 실행되며, REST API 등을 통해 서로 통신하기 때문에  FeginClient 로 인터페이스를 만들어서 사용하면 다른 서비스들을 호출하여 사용하는데 편리하다 

* 마이크로서비스 구조가 아니라면 ? 
모놀리식(monolithic) 구조

모든 기능이 한 프로젝트에 있는 것 
ex) 사용자 관리, 주문관리, 결재관리 모두 한 프로젝트에 !! 

 

 

인터페이스로 구현된 이유

 

FeginClient 는 인터페이스로 구현되어있는데 어떤이유일까?

어떤 목적성을가지고 올바르게 사용하면될까? 

 

와 같은 이유로 정리해보려 한다 

 

 

[ 목적 ] 

 

외부 Rest API 호출을 간결하게 처리하기 위함 

 

 

[ 방식 ] 

 

인터페이스 + 어노테이션으로 구성 

 

 

[ 인터페이스로 구현된 이유 ]

 

1. 프록시 패턴을 활용한 자동 구현

 

FeignClient는 인터페이스만 정의하면, Spring Cloud가 런타임에 프록시 객체를 만들어서 실제 HTTP 통신을 대신해준다.

따라서 굳이 RestTemplate 나 WebClient 로 직접 API 호출 코드를 자겅하지 않아도 된다는 것이다.

 

'@FeginClient' 어노테이션으로 작성해두면, 스프링이 내부적으로 구현 클래스를 만들어줘서 호출가능해 진다. 

 

 

2. 느슨한 결합(Loosely Coupled)

 

인터페이스를 사용하면 실제 구현체와 분리되기 때문에 유지보수와 테스트가 쉬워진다

 

예를 들어, 테스트할 때는 진짜 API를 호출하지 않고 인터페이스를 Mock 처리해서 테스트할 수 있다.

 

 

3. 관심사의 분리(Separation of Concerns)

 

인터페이스는 "이런 API를 호출하겠다" 라는 계약(Contract) 만 정의하고, 구현은 프레임워크가 알아서 처리하니까 개발자는 비즈니스 로직에만 집중할 수 있는 장점이 있다.