리액티브 마이크로 서비스 정리

동일한 마이크로서비스는 서로 공유 및 통신하게 되어있다. 

예를 들면 주문과 결재, 배송서비스들은 서로 공유되어있다. 이 서비스들의 호출 관계를 단순하게 동기 방식으로 호출하게 된다면 강한 의존성을 가지게 되기 때문에 마이크로 서비스의 강점을 충분하게 살릴 수 없다. 결국 모노토릭 서비스와 크게 다를게 없어진다.

그래서 도입되는 개념이 리액티브 마이크로 서비스이다. 
리액티브 프로그래밍은 회복성(resilient), 응답성(responsive), 메시지 기반(message driven), 탄력성(elastic) 이렇게 4가지 기둥이 존재한다. 

서로간에 마이크로서비스가 독립적으로 되어있기 때문에 특정 부분에 문제가 발생하면 해당 마이크로서비스의 복제본이 이를 대체할 수 있다. 

하지만 이렇게 격리가 되었다고 해도 서비스 사이의 통신 방식과 의존 관계가 동기 블로킹방식의 RPC로 구성된다면 서비스는 완전히 격리된 것이 아니고 서로 의존관계가 있기에 오류가 전파될 수 밖에 없다.  

그래서 서비스 사이의 통신을 비동기 논블로킹 호출을 사용하는 리액티브 스타일로 설계하는 것이 중요하다.

위에 그림을 보면 각 마이크로서비스들은 이벤트를 리스닝 하고있다. 각 서비스에서 발생한 출력값이 다른 서비스에 입력값으로 들어가게 되는데 특정 마이크로서비스의 값을 대기하는게 아니라 단지 자신의입력 큐에 이벤트가 들어오기를 기다리고 있다. 

그래서 마이크로 서비스들은 서로의 존재를 알지 못한다. 단지 이벤트 발생을 리스닝 하고 있을 뿐이다. 

이렇게 되면 한 서비스의 결과 큐를 다른 서비스의 입력 큐로 연결하는 연출(choreography)효과를 낼 수 있다.  

그렇기 때문에 동기로 호출 되기를 무작정 기다리는 블로킹보다 효율적이다.

그리고 상황에 따라서 서비스를 복제하여 여러 인스턴스로 띄워서 확장할 수 도 있다. 그러면 이벤트를 리스닝하는 서비스가 증가하고 이벤트를 받은 서비스는 각자의 역할대로 이벤트를 처리하게 되면 분산처리가 가능하다. 

이런 리액티브 마이크로서비스에는 흐름 제어가 자동으로 이루어지며 중앙에서 제어해주는 밸런서가 따로 존재하지 않는다. 

대신 메시지와 입력, 출력에 대한 마이크로서비스 사이의 관계가 주어지는데 필요에 따라 입력큐와 출력큐를 바꾸기만 하면 되기 때문에 서비스의 영향없이 운영할 수 있다. 

이런 리액티브 웹 애플리케이션을 개발할 수 있도록 스프링 부트에는 기능이 내장되어 있다. 추 후에 Spring Cloud Streams에 대해 공부해보자.