created at 2022-12-24
전체 스키마 수정
앞서 본 프로젝트에서 backend와 front가 kafka Request/Response 아키텍쳐로 통신하도록 설정하였다. 이 때, 발생하는 귀찮은 부분이 상당히 많았다.
특히 로그인 부분에서 다시 생각해보게 되었다
기존 구현
아키텍처
(아직 로깅서버는 미구현)
통신 흐름
- Client – POST https://{frontend}/login –> Frontend
- Frontend Producer – { topic=login-request, data=ReqLoginDto, key=userId } –> Kafka
- Backend Consumer – 로직처리 – Kafka { topic=login-response, data=RespLoginDto, key=userId } –> Kafka Broker
- Frontend Consumer – STOMP { topic:/sub/userLogin/{userId}, data:”Accepted” } –> Client
발생한 문제점
고려할 점이 상당히 많다. 단순히 backend를 RESTAPI로 구현하면 webClient를 통해 발신/수신하면 된다. 이는 요청에 대한 반환의 시점이 명시되어야 하는 로그인서비스의 기능과 부합한다. 하지만 kafka로 REQ/RESP하면 메세지를 consume하는 시점자체가 명확하지 않다보니 언제 로그인 서비스가 해당 유저에게 제공될 지 모르는 문제점이 발생한다.
수정된 구현
아키텍처
- Kafka를 여러 부가기능서버와 데이터를 주고받는 백본으로 활용한다(실시간 처리가 필요없는 부가기능들!).
- API Gateway로 같은 기능의 서버를 묶고 restapi형태로 제공하여 쉽게 사용할 수 있도록 한다.
통신 흐름
- Client – POST https://{frontend}/login –> Frontend
- Frontend –redirect to API Gateway–> Api Gateway(“/chat”)
- API Gateway –redirect to Backend(Load Balancing)
- Backend –results–> API GateWay –> Frontend –STOMP { topic:/sub/userLogin/{userId}, data:”Accepted” }–> Client
- Backend(ChatServer)에서 주기적으로 Logging토픽에 메세지 전송
- LoggingServer에서 메세지 소비
곧 크리스마스인데 다들 따뜻하게 입으시고 즐거운 크리스마스 보내세요 :D
혹시라도 컨셉이 잘못되었거나 이상한점이 있다면 언제든! ghkdqhrbals@gmail.com 로 메일 보내주시면 감사하겠습니다.