Spring Cloud Message Broker의 필요성(RabbitMQ)

 

Spring Cloud Message Broker

스프링 클라우드 메시지는 마이크로서비스를 카프카 및 RabbitMQ 와 같은 경량 메시지 브로커에 연결한다.

 

마이크로서비스 ISSUE

예를들어, 마이크로서비스를 구성했을 때, Production 환경에서 실행 중인 마이크로서비스 중 A의 backend 서비스가 5개 있다고 가정하면, Config 서버에서 Configuration 정보를 긴급하게 변경해야하는 경우가 생긴다.

##microservice-a.properties

##application.message=Message not changed
application.message=Message changed!

@RestController
public class MessageController {
  @Autowired
  private ApplicationConfiguration configuration; //ApplicationConfiguration의 구성된 메시지 값을 읽음
  @RequestMapping("/message")
  public Map<String, String>welcome() {
      Map<String, String> map = new HashMap<String, String>();
      map.put("message", configuration.getMessage()); //application.message값을 읽어옴.
      return map;
  }
}

마이크로서비스 backend 서비스 중 A가 변경된 이 Configuration 정보를 적용하려면 curl -X POST http://localhost:8080/refresh 로 요청을 호출해야 한다.

curl -X POST http://localhost:8080/refresh
{"message": "Message changed"}

하지만, Configuration 변경은 URL이 실행된 마이크로서비스 A의 1개 서비스에만 반영된다. 다른 4개의 서비스는 새로 고침 요청이 실행될 때까지 변경 사항을 받지 못한다.

마이크로서비스에 여러개의 서비스가 있는 경우, 각 Config 서버에 정보를 변경 시마다 이 작업을 수행해야 하므로 각 인스턴스에 대해 새로 고침 URL을 실행하는 것이 번거로워진다.

 

SOLUTION

해결책은 스프링 클라우드 메시지 버스를 사용하여 RabbitMQ와 같은 메시지 브로커를 통해 Configuration 변경 정보를 여러 서비스(혹은 인스턴스)에 전달하는 것이다. 

위 그림은 마이크로서비스 A의 서비스들이 스프링 클라우드 버스를 사용해 메시지 브로커에 연결되는 방법을 보여준다.

각 마이크로서비스의 서비스(Apps)는 애플리케이션 부팅 시 스프링 클라우드 버스(RabbitMQ)에 등록할 것이다.

마이크로서비스 서비스 중 하나에서 새로 고침이 호출되면, 스프링 클라우드 버스는 모든 마이크로서비스의 App에 변경 이벤트를 전달한다.

마이크로서비스 App은 변경 이벤트 수신 시 구성 서버에 업데이트된 구성을 요청한다.