Skip to main content Link Menu Expand (external link) Document Search Copy Copied
Backend Forge

created at 2022-12-24

전체 스키마 수정

앞서 본 프로젝트에서 backend와 front가 kafka Request/Response 아키텍쳐로 통신하도록 설정하였다. 이 때, 발생하는 귀찮은 부분이 상당히 많았다.

특히 로그인 부분에서 다시 생각해보게 되었다

기존 구현

아키텍처

img

(아직 로깅서버는 미구현)

통신 흐름

  1. Client – POST https://{frontend}/login –> Frontend
  2. Frontend Producer – { topic=login-request, data=ReqLoginDto, key=userId } –> Kafka
  3. Backend Consumer – 로직처리 – Kafka { topic=login-response, data=RespLoginDto, key=userId } –> Kafka Broker
  4. Frontend Consumer – STOMP { topic:/sub/userLogin/{userId}, data:”Accepted” } –> Client

발생한 문제점

고려할 점이 상당히 많다. 단순히 backend를 RESTAPI로 구현하면 webClient를 통해 발신/수신하면 된다. 이는 요청에 대한 반환의 시점이 명시되어야 하는 로그인서비스의 기능과 부합한다. 하지만 kafka로 REQ/RESP하면 메세지를 consume하는 시점자체가 명확하지 않다보니 언제 로그인 서비스가 해당 유저에게 제공될 지 모르는 문제점이 발생한다.

수정된 구현

아키텍처

img

  • Kafka를 여러 부가기능서버와 데이터를 주고받는 백본으로 활용한다(실시간 처리가 필요없는 부가기능들!).
  • API Gateway로 같은 기능의 서버를 묶고 restapi형태로 제공하여 쉽게 사용할 수 있도록 한다.

통신 흐름

  1. Client – POST https://{frontend}/login –> Frontend
  2. Frontend –redirect to API Gateway–> Api Gateway(“/chat”)
  3. API Gateway –redirect to Backend(Load Balancing)
  4. Backend –results–> API GateWay –> Frontend –STOMP { topic:/sub/userLogin/{userId}, data:”Accepted” }–> Client
  5. Backend(ChatServer)에서 주기적으로 Logging토픽에 메세지 전송
  6. LoggingServer에서 메세지 소비

곧 크리스마스인데 다들 따뜻하게 입으시고 즐거운 크리스마스 보내세요 :D

혹시라도 컨셉이 잘못되었거나 이상한점이 있다면 언제든! ghkdqhrbals@gmail.com 로 메일 보내주시면 감사하겠습니다.