개요 현재 마이크로서비스 간 데이터 통신 시 TCP를 활용하고 있다. 그러나, gRPC로 방향을 바꿔보고자 한다. 이유로는 크게 3가지가 있다. 성능 개선 기대 예외 처리의 직관성 개선 기대 네트워크 사용량 감소 기대 세가지 경우 모두 확실하지 않지만, 채팅 서버 - 상태관리 서버 사이에 적용하여 다양한 테스트를 해볼 예정이다. 테스트는 아래 3가지를 할 생각이다. TCP VS gRPC 송수신 성능 평가 예외처리 코드 작성 및 직관성 개선 확인(지극히 개인적, 정성적.. 으로 평가할 예정) Prometheus & Grafana를 통한 usage 체크 특히, 현재 가장 문제점은 예외처리 코드에 대한 직관성이 많이 떨어진다. 그 이유로는 TCP통신에 대한 이해도가 부족하여, 예외처리 구현의 미흡함이 있다. ..
1인 프로젝트에서 MSA 기반 인증 서버 만든 것을 확장하여 구현하였다. 게이트웨이 Gateway를 통해 Jwt 토큰을 검증하고 각 서버에서 필요 시 jwt토큰으로 부터 유저 정보를 확인한다. 게이트웨이를 활용하였기 때문에 각 서버에서 따로 검증하는 코드를 작성할 필요가 없게 되었다. 게이트웨이 주요 구현 내용 Jwt 검증 GlobalExceptionHandler ErrorCode Jwt 검증 게이트웨이에서 Jwt를 검증한 방법은 아래 코드를 통해 확인할 수 있다. header에 Jwt 토큰이 존재하는 지, 그리고 그 토큰이 유효한 지를 검증한다. 이 때 예외 발생 시 예외를 던진다. public class AuthorizationHeaderFilter extends AbstractGatewayFilte..
프로젝트를 경험해보면서 API, DB 등 설계의 중요성을 많이 느꼈다. 프로젝트가 복잡해질수록 소프트웨어도 복잡해지고 이에따라 탄탄한 설계가 가져오는 장점들이 존재함을 몸소 느낄 수 있었다. 우리가 만들고하자는 요구사항(윈터데브캠프의 목표)을 효과적으로 만족시킬 수 있다. 유지보수 측면에서 용이하다. 협업에서 이점을 갖는다. 따라서, API,DB명세를 상세히 하고자 했고, 이에 따라 적용한 방법을 보이고자 한다. 내가 생각하는 API 명세를 작성하는 이유는 크게 3가지가 존재한다. 어떤 것을 구현해야하는지 명확히 한다. 협업에 있어 req/res 형태를 공유한다. 정해진 규칙을 따라 API를 명세한다. 이를 만족시키기 위해 기능 명세를 작성하였다. 기능 명세를 작성한 이유는 시간에 대한 한계가 있기 때문..
스마일게이트 윈터데브캠프에서 채팅 애플리케이션을 개발하였다. 채팅 애플리케이션을 개발하기로 한 이유는 팀원들 간 회의를 통해 도출된 공통 목표에서 나오게 되었다. 공통 목표 경험해보지 못한 아키텍처와 기술들을 활용하여 문제 해결에 대한 폭을 넓힌다. 양방향 소켓 통신에 대한 경험 X 전체 서버의 아키텍처는 MSA를 기반으로 구성하였으며, 채팅 서버는 scale out 가능한 구조로 구성하고자 했다. 전체 구조는 아래 그림과 같다. 이번 프로젝트에서 서비스 레지스트리, 게이트웨이, 인증 서비스, 유저 서비스, 푸시 서비스는 내가 맡게 되었다. 추후 각 서비스 별 주요 내용을 정리할 예정이다. 실제 상호작용하는 부분이 추가된 상세화된 아키텍처는 아래와 같다. 전체 사용 스택은 Spring Boot, Spri..
