[마이크로서비스 디자인 패턴] 리액티브 마이크로서비스 (Reactive Microservice)

1. 문제점

- 보통 HTTP 기반의 Restful Json API와 같은 블로킹 I/O 모델을 사용해 동기식 통신을 구현해 왔다.
- 블로킹 I/O를 사용하면 요청을 처리하는 동안 운영체제의 스레드를 점유하게 된다.
- 동시 요청 수 혹은 요청과 관련된 컴포넌트가 증가하면 운영체제의 가용 스레드가 부족해 
  응답 시간이 늦거나 서버가 중단되는 문제가 발생할 수 있다.
- 블로킹 I/O를 과도하게 사용하면 마이크로서비스 시스템에 오류가 발생하기 쉽다.
- 연쇄 장애가 발생할 수 있다.
  > 어떤 서비스의 지연 시간이 증가하면 가용 스레드가 부족해져서 클라이언트가 실패할 수 있다.
  > 이런 상황은 클라이언트의 클라이언트에게도 동일한 유형의 문제를 유발하게 된다.

 

2. 해결책

논블로킹 I/O를 사용해 데이터베이스나 다른 마이크로서비스가 처리하길 기다리는동안 스레드가 할당되지 않게 한다.
- 가능하다면 비동기(asynchronous) 프로그래밍 모델을 사용한다.
  즉 메시지를 보낸 후 수신자가 메시지를 처리하길 기다리지 않는다.
- 동기식 프로그래밍 모델을 선호한다면 리액티브 프레임워크를 사용한다.
  > 리액티브 프레임워크 : 논블로킹 I/O를 사용해 응답을 기다리는 동안에도 스레드 할당 없이 동기식 요청을 실행한다.
- 마이크로서비스는 의존하는 서비스가 중단되더라도 응답할 수 있도록 탄력성 있게 설계돼야 하며,
  중단된 서비스가 재개되면 클라이언트가 서비스를 다시 사용할 수 있어야 한다.
  (자가치유[self-healing] 라고 한다.)

 

3. 구현된 오픈소스 도구

- 스프링부트 : Spring Reactor, Spring WebFlux