- 프로젝트 목적: 물류 관리 및 배송 시스템을 위한 MSA 기반 플랫폼
- 프로젝트 설명: 물류 관리 및 배송 시스템입니다. MSA기반 플랫폼으로, 대규모 트래픽을 고려한 설계와 개발을 진행하였습니다.
- 아키텍처 설명 : 허브, 배송담당자, 회원, 주문, 업체, 상품, 배송, slack/AI로 나뉘어져 있으며, DB, SpringBoot 모두 docker container로 관리 하였습니다. 서비스 간의 통신은 FeignClient를 통해서 진행하였습니다.
- 빈번하게 조회되는 데이터를 캐싱
- 허브의 경로 데이터는 경로를 계산하여 Cache-Aside 전략으로 캐싱
- 정렬, 권한 별 조회 등에 따른 동적 쿼리 작성을 위하여 QueryDSL을 도입하여 활용했습니다.
- 각각의 모듈과 정확한 소통을 위해 스웨거를 통해 API 를 관리하였습니다.
- 성능 문제를 분석하고 트랜잭션 추적을 위해 Zipkin을 도입하였습니다.
- 마이크로서비스 간의 호출 관계를 시각화하여 성능 병목 지점을 식별할 수 있도록 하였습니다.
- 공통적으로 적용해야 하는 로깅 기능을 AOP(Aspect-Oriented Programming)를 활용하여 구현하였습니다.
- 서비스 레이어 및 주요 비즈니스 로직에서 실행 시간을 측정하고 로깅하여 성능을 모니터링하였습니다.
— 기술/구현
— 피드백
-
회원:
- 권한별 회원가입을 진행합니다
- 권한은 MASTER(관리자), HUB(허브담당자), STORE(업체담당자), DELIVERY(배송담당자)로 분류되어 있습니다
- 로그인이 진행되고, 필터 단에서 유저의 권한을 확인하여 토큰을 발급합니다.
- 발급된 토큰을 기반으로 gateway의 AuthPermissionFilter에서 권한별 API를 처리합니다.
-
배송담당자:
- 스파르타 물류센터에 속한 허브 배송담당자가 10명 존재합니다
- 각 허브별 업체 배송담당자는 10명이 존재합니다
- Redis Queue를 통해서 배송 담당자의 순번에 따라서(라운드 로빈방식으로) 배송담당자를 할당합니다.
-
주문:
- 주문의 CRUD 및 검색 기능이 있습니다.
- MASTER 권한은 CRUD 검색이 모두 가능합니다.
- 토큰을 인증한 회원은 모두 주문이 가능합니다.
- 주문 취소는 MASTER, 허브 관리자, 주문자만 가능합니다.
- 허브 관리자는 본인 담당의 허브 주문만 취소 가능합니다.
- 주문자는 배송이 시작되지 않은 경우에만 취소 가능합니다.
-
배송:
- 주문이 생성되면 배송이 함께 생성됩니다.
- 배송이 생성되면 배송 경로가 함께 생성되어 배송 담당자에게 슬랙으로 알림을 보냅니다.
-
상품:
- 상품 신규 등록이 가능합니다
- 상품 재고 추가/감소가 가능합니다
- 주문 서비스 호출을 통해서 재고 추가/감소를 진행합니다.
-
허브:
- 물류 전략을 Hub And Spoke로 정했던 가장 큰 이유는 패션 산업의 특징 때문입니다. 패션 쪽은 종류도 다양하고, 같은 옷에 색상 및 사이즈도 구분되어 있습니다. 그리고 반품/교환 비율이 높아 (수거 → 검사 → 재분류 → 유통) 과정이 빈번하게 일어납니다. 그래서 중앙 허브에 집중해 자동화 및 효율화에 이점이 있는 전략을 선택하게 되었습니다.
- 허브 경로는 허브와 연관관계를 맺지 않고 이벤트에 의해 최신화가 되도록 진행했습니다. 이렇게 한 이유는 허브 경로는 허브의 CUD 뿐만 아니라 스케쥴링, 트래픽 등 다양한 상황에서 최신화를 해야했고, 이 때 경로의 일관성을 위해 모든 경로를 업데이트 하기 때문입니다. 따라서 MSA 환경에서 이후에 도메인 분리가 고려될 때 확장성을 위해 결합도를 낮춰서 구현했습니다.
-
업체:
- 업체의 CURDs 기능이 있습니다.
- MASTER는 모든 권한이 있고, 허브 관리자는 자신의 허브에 대해서만 모든 권한이 있습니다. 업체 담당자는 자신의 업체에 대해서 수정 및 조회만 가능합니다.
-
SLACK/AI
- Gemini를 이용하여 메세지를 생성하고 Slack app을 이용하여 특정사용자에게 DM을 보냅니다.
- ORDER의 값들을 requestDTO에 담아 요청하고, 일관된 형태의 response를 받습니다.
- 일관된 형태의 response에서 변수들을 파싱해 DB에 저장, 메시지를 전송합니다.
- MASTER만 전 권한이 있고 나머지는 생성만 가능합니다.
| SpringBoot |  |
3.4.3 |
| Java |  |
17 |
| Spring Data JPA |  |
5.0.0 |
| QueryDSL |  |
1.11.12 |
| Spring Security |  |
3.4.2 |
| PostgreSQL |  |
16.3 |
| pgAdmin |  |
latest |
| Docker |  |
우리의 브랜치 전략은 아래와 같은 Git Flow를 기반으로 하며, 다음과 같은 브랜치를 사용합니다.
-
Main Branch
- 배포 가능한 상태의 코드를 유지합니다.
- 모든 배포는 이 브랜치에서 이루어집니다.
-
develop Branch
- 통합 기능 관리 브랜치 입니다
- feat에서 개발한 기능을 develop 브랜치에서 통합하여 관리합니다.
-
feat Branch
- 기능 개발 브랜치 입니다.
- 기능 단위로 브랜치를 나누어 기능을 개발하였습니다.
-
refactor Branch
- 코드 리팩토링 브랜치 입니다.
- 코드 리팩토링이 필요한 경우 refactor 브랜치에서 작업했습니다.
-
release Branch
- 배포 전 버전을 관리하는 브랜치 입니다.
- 최종 배포하기 전 테스트를 진행하고, 이상이 없다면 Main브랜치로 배포를 진행합니다.
-
hotfix Branch
- 핫픽스를 관리하는 브랜치 입니다.
- 배포된 환경에서 수정사항이 발생했을 경우, hotfix 브랜치에서 관리하였습니다.
|
|
|
|
|---|---|---|---|
| 박규원 | 류지윤 | 박상욱 | 김지수 |
| 회원, 배송담당자, 상품 | 주문, 배송 | 허브 | 슬랙, 업체 |
| Lead | Tech Lead | BE | BE |