daangn-server 아키텍쳐 설계 과정

[cotchan]

daangn-server 아키텍쳐 설계 과정

목차

1. API 서버(api-server)와 채팅 서버(chat-server) 분리
2. 알림 서버(notification-server) 추가
3. 최종 daangn-server 아키텍쳐

API 서버(api-server)와 채팅 서버(chat-server) 분리

분리하게 된 이유

• 131 에서 채팅 관련 DB와 API 관련 DB를 분리하면서 채팅 기능을 제공하는 서버와 API 응답을 내려주는 서버를 분리하기로 함

• 그 과정에서 api 서버에서 채팅 관련 DB와 API 관련 DB에 모두 접근해야 되면서 프로젝트 구조 변경 작업 진행

  • 21

알림 서버(notification-server) 추가

추가하게 된 이유

• 요구사항 중 알림 도메인 추가

대분류	기능	method	URI
알림 관련	알림 목록 조회	GET	/api/notifications
	알림 읽음 처리	PUT	/api/notifications/{notification-id}
	알림 삭제 처리	DELETE	/api/notifications/{notification-id}

• 알림이 발생하는 케이스는 아래 4가지
  • 사용자가 찜한 상품이 거래 완료된 경우
  • 사용자가 찜한 상품의 가격이 낮아진 경우
  • 판매자가 판매완료로 상태를 변경한 경우
  • 구매자가 구매후기를 남긴 경우

알림 기능 때문에 기존 비즈니스 로직에 알림을 처리하는 로직이 추가되는 건 바람직한 형태 X

• 그러므로 API 서버에서는 알림을 발생시키는 이벤트만 publish하고 알림을 사용하는 쪽에서 subscribe하는 구조로 결정
• 이벤트 전파를 위해 google guava eventBus를 사용하기로 하고, API 서버에서 전부 처리하는 게 아니라 별도의 알림 서버(notification-server)로 요청을 보내서 알림에 대한 정보를 DB에 insert 하도록 결정
• 이벤트 전파, 이벤트 구독의 message broker 역할로 kafka 사용

최종 daangn-server 아키텍쳐

• API 서버 + 채팅 서버 + 알림 서버