MSA를 구성하기 위한 공부중이다.
각 서비스의 결합도를 낮춤으로써 유지보수가 쉽고, 하나의 서버에 장애가 발생하더라도 문제없이 운영이 가능하기 때문에 MSA를 선호하는 추세이다.
또한 배포하기 쉬워지고 데이터베이스 서버에 과부화가 줄어들고 다양한 이점들이 있다.
카카오 클라우드 스쿨을 다니면서 최종 목표는 쿠버네티스, 카프카, 스프링을 활용하여 MSA아키텍처를 설계 및 구현하는 것이다.
==========================================================================================
오늘은 기초적인 카프카, 스프링 어플리케이션 간 분리를 진행해보았다.
스프링과 카프카를 설계 시 컨수머 단을 먼저 구성하는 것이 좋은 것 같다.
도메인, 서비스 구현이 중점이 아니라 카프카에 중점이 맞춰 구현을 하였다.
이번 프로젝트는 개발자가 상품을 등록해놨다고 가정하고, producer에서 상품 주문을 하면 컨수머단에서 기다리고 있다가 주문 정보를 받아들여 상품 개수가 줄어드는 프로젝트이다. 도메인은 간단히 상품 이름, 상품 개수 2가지로 구성하였다.
로컬에서 구현하는 관계로 카프카 브로커 서버는 하나만 두었다.
@EnableKafka 로 카프카를 사용하는 것을 알린다.
ConsumerFactory : 컨수머 인스턴스를 생산함.
ConcurrentKafkaListenerContainerFactory : kafkaListenerContainerFactory를 생산함
@kafkaListener : config에서 등록한 ConcurrentKafkaListenerContainerFactory를 사용하여 리스너를 구현함.
위 Config 에서 서버, 컨수머 설정을 끝내고 컨수머 객체를 만들어야한다.
토픽을 모니터링하면서 producer로부터 들어온 메시지에 대한 반으을 구현해야한다.
objectMapper를 사용하여 컨수머 메시지로부터 값을 가져온다. object를 키,값으로 하는 이유는 모든 객체의 상위 메소드는 object를 상속받아 구현되므로 object로 설정한다.
map에 키 값은, producer로부터 들어온 dto의 필드명으로 구성된다.
위에는 원래 order로 구현을 했었는데, 데이터베이스를 mysql을 사용해서 product로 바꾸었다. mysql에서 order는 예약어이므로 사용이 불가해서 바꾸었다.
실제 전송되는 객체는 goods, qty로 되어있는것을 볼 수 있다.
카프카 producer는 토픽에 데이터를 넣기 위한 탬플릿이 필요하다. 카프카 탬플릿은 키, 값을 가진 자료구조이며, 설정이 가능하다.
