MVP
ApplicationEventPublisher를 이용해 알림 기능을 구현했습니다.
저희 팀의 프로젝트는 결국엔 배달비를 나눠내는 서비스이지만, 그러려면 사람들이 모여서 정해진 계획을 놓고 일정을 정하여 만나야 합니다. 하지만 계속해서 APP을 바라보며 누가 참가하고 내가 보낸 참가요청은 승인이 되었는지, 내가 참가한 모임이 취소되었는지 확인 할 수는 없는 노릇이죠.
때문에 어떠한 요청을 보내고, 모임에 참가해서 기다리는 동안에 발생할 각 요청에 따른 알림이 필요하다고 느껴 구현하게 되었습니다.
알림기능들 중에 ApplicationEventPublisher를 선택하고 구현한 이유
•
느슨한 결합 : 발행자와 구독자 간의 강한 의존성을 줄일 수 있습니다. 모듈 간의 느슨한 결합은 시스템의 유지보수성과 확장성을 높입니다.
•
확장성 : 새로운 이벤트나 구독자를 추가하거나 기존 이벤트를 수정할 때, 코드 변경이 적어 유연한 확장이 가능합니다. 새로운 기능을 도입할 때 시스템의 변화가 최소화됩니다.
•
모듈 간 통신 : 모듈 간의 효과적인 통신이 가능합니다. 다양한 모듈에서 발생하는 이벤트를 중앙에서 관리하고 처리함으로써 시스템 내의 다양한 컴포넌트들이 손쉽게 소통할 수 있습니다.
•
비동기 처리 : 이벤트를 비동기적으로 처리할 수 있습니다. 이는 시스템의 응답성을 향상시키는 데 도움이 됩니다.
•
유연한 디자인 : ApplicationEventPublisher를 통한 이벤트 기반 디자인은 유연성을 제공합니다. 시스템의 각 부분을 독립적으로 개발하고 테스트할 수 있어 개발자들이 보다 효율적으로 작업할 수 있습니다.
•
Spring Framework 통합 : Spring Framework의 일부로서 간편한 통합과 사용이 가능하며, Spring의 다양한 기능과 연계하여 활용할 수 있습니다.
다른 알림 기능들
1.
메시지 큐 (Message Queue):
•
특징: 메시지 큐는 중앙에서 메시지를 관리하고, 이를 구독하는 시스템 컴포넌트들이 메시지를 받아 처리합니다. RabbitMQ, Apache Kafka 등이 대표적인 메시지 큐 시스템입니다.
•
강점: 높은 확장성, 내구성 있는 메시지 전달, 대용량 데이터 처리.
•
비교: ApplicationEventPublisher는 간단한 이벤트 기반 통신에 적합하며, 메시지 큐는 대규모 분산 시스템에서의 확장성이 뛰어난 메시지 전달에 특화되어 있습니다.
2.
웹 소켓 (WebSocket):
•
특징: 실시간 양방향 통신을 제공하는 웹 소켓은 주로 웹 애플리케이션에서 사용됩니다.
•
강점: 실시간 업데이트, 낮은 지연 시간.
•
비교: ApplicationEventPublisher는 주로 서버 내부의 모듈 간 통신에 사용되며, 웹 소켓은 클라이언트와 서버 간의 실시간 통신에 중점을 둡니다.
3.
이메일 알림:
•
특징: 이메일 알림은 주로 사용자에게 정보를 전달하는 데 활용됩니다.
•
강점: 비동기적인 커뮤니케이션, 다양한 형식의 정보 전달.
•
비교: ApplicationEventPublisher는 시스템 내부의 이벤트 전달에 주로 사용되며, 이메일 알림은 외부로의 정보 전달에 특화되어 있습니다.
주의사항
ApplicationEventPublisher는 이벤트 기반 아키텍처를 지원하기 위한 강력한 메커니즘 중 하나이지만, 몇 가지 한계와 부족한 점이 있습니다. 이러한 한계들이 주의사항이나 추가적인 고려 사항으로 나타납니다.
1.
비동기 처리의 한계:
•
문제: ApplicationEventPublisher를 통한 이벤트 발행은 주로 동기적으로 동작합니다. 비동기적인 이벤트 처리를 위해서는 별도의 비동기 작업 또는 메시지 큐와의 통합이 필요합니다.
•
해결책: 비동기적인 처리가 필요한 경우 별도의 비동기 작업 또는 메시지 큐를 사용하여 이를 보완할 필요가 있습니다.
2.
분산 환경에서의 한계:
•
문제: ApplicationEventPublisher는 주로 단일 서버 내에서 모듈 간의 통신에 사용되며, 분산 환경에서의 이벤트 전파에는 한계가 있습니다.
•
해결책: 분산 시스템에서는 메시지 브로커 또는 분산 메시징 시스템과의 통합이 필요할 수 있습니다.
3.
트랜잭션 관리의 한계:
•
문제: ApplicationEventPublisher를 사용한 이벤트는 기본적으로 트랜잭션과 직접적으로 연결되지 않습니다. 이는 트랜잭션 롤백이 이벤트에 영향을 미치지 않는다는 것을 의미합니다.
•
해결책: 트랜잭션 관리가 필요한 경우, 트랜잭션 관리 기능을 갖춘 메시지 큐 또는 트랜잭션 매니저와의 통합을 고려할 수 있습니다.
4.
이벤트 버스의 부재:
•
문제: ApplicationEventPublisher는 단일 이벤트를 여러 구독자에게 전파하는 기능만을 제공하며, 이벤트 버스의 개념이 부족합니다.
•
해결책: 이벤트 버스 패턴이 필요한 경우, 별도의 이벤트 버스 라이브러리나 프레임워크를 도입할 수 있습니다.
이러한 한계와 부족한 점들로 인해 이벤트 기반 시스템에서는 예외 처리, 비동기 처리, 분산 시스템 통합 등에 대한 주의가 필요합니다. 상황에 따라 다양한 기술과 도구를 적절히 활용하여 이러한 한계를 극복하고 시스템의 안정성과 확장성을 유지하는 것이 중요합니다.
주의점
•
비동기 처리의 한계 : ApplicationEventPublisher를 통한 이벤트 발행은 주로 동기적으로 동작하기에 비동기적인 이벤트 처리를 위해서는 별도의 비동기 작업 또는 메시지 큐와의 통합이 필요합니다.
•
트랜잭션 관리의 한계 : 기본적으로 트랜잭션과 직접적으로 연결되지 않기 때문에 트랜잭션 롤백이 이벤트에 영향을 미치지 않습니다. 트랜잭션 관리가 필요한 경우, 트랜잭션 관리 기능을 갖춘 메시지 큐 또는 트랜잭션 매니저와의 통합을 고려해보아야 합니다.
•
분산 환경에서의 한계 : ApplicationEventPublisher는 주로 단일 서버 내에서 모듈 간의 통신에 사용되며, 분산 환경에서의 이벤트 전파에는 한계가 있습니다. 이를 해결하려면 메시지 브로커 또는 분산 메시징 시스템과의 통합이 필요합니다.
•
이러한 점들로 인해, 예외처리하는데에 있어 주의가 필요합니다. 이벤트 핸들러에서 발생한 예외는 적절히 처리되어야 하며, 롤백이 필요한 경우 트랜잭션 관리에 주의해야 합니다. 또한, 테스트 코드를 작성하여 각종 시나리오에서의 안정성을 검증하는 것이 중요합니다.
