이번 프로젝트는 Poly Repo부터 시작해볼 생각이다.

일단 Mono Repo와 Poly Repo의 차이를 간략하게 알아보자

Mono Repo vs Poly(Multi) Repo

• Mono Repo : msa-shopping-mvp 하나로 통합

즉 우리가 그냥 Github에 생성하는 하나의 Repo를 말하는 것 같다.
아마 지금까지 해온 Monolithic의 Mono랑 같은 맥략인듯 하다.

• Poly(Multi) Repo : user-service, order-service, cart-service 등으로 분리 (운영 확장성↑)

MSA의 특징은 각 서비스가 독립적으로 분리되어있고, 그에 따라 DB 역시 독립적으로 존재한다는 것이다.

즉, Repo 역시 여러개 존재하는 구조가 Poly(Multi) Repo이다.

내가 생각하기에 MSA 구조인 만큼 MVP를 만든다 하여도 Poly Repo 구조로 시작해보는게 나을 것 같다.
(뭐 CI/CD가 힘들 수 있지만 어떻게든 되겠지)

Poly(Multi) Repo 설정

딱히 설정이라고 할 건 없다.

다만 repo를 여러개 생성하는 것인데... 그 repo를 하나의 Repo로 묶어서 관리하는 방법도 존재하겠지만

나는 이번에 Organization을 생성하여 관리하도록 할 예정이다.

Organization을 생성하면 권한 관리와 협업이 어렵움과 CI/CD 구성의 불편함도 해소 될 수 있다.

개발 순서

를 정하기 전에 API Gateway에 대해 조금 더 알아보자

예전에 잠깐 Node.js를 봤을 때, 정확히는 Express.js를 사용할 때 routes를 생성해서 하는 방식이
API Gateway랑 비슷한 방식일것이라고 짐작으로 예상했었다.

다만 Express에서는 단순하게 클라이언트의 요청을 핸들러로 넘기는,
REST API의 엔드포인트 관리만을 담당한다.

그에 반해 API Gateway는 각각의 마이크로 서비스의 요청을 라우팅하기 때문에
라우팅 범위에서도 꽤나 다르게 작동하며 보안, 로드 밸런싱, 장애 대응, 트래픽 제한 등의
추가 기능 역시 API Gateway에서 담당한다.

일단 내가 중요하다고 생각했던 내용은 라우팅에 관련한 내용이며 라우팅과 Security관련된 내용을
API Gateway에 작성해야 하고 따라서 개발 순서도 Gateway가 1순위이며 그 외에 각 서비스로 진행될 줄 알았다.

개발 순서

그렇지만 라우팅을 하기 전에 각 서비스에서 비지니스 로직을 구현하고,
각 서비스에서 제작된 API들을 API Gateway쪽으로 넘기는 방식으로 진행 될 것 같다.

가장 처음으로

그래서 가장 처음 개발할 서비스 로직은 아마 User (& Auth) 쪽이지 않을까 싶다.

개발할 내용으로는 다음과 같으리라 예상된다.

User Service
1. 회원 가입

Auth Service
2. 로그인 (당장에는 email 로그인이기 때문에 User에 위치할 가능성이 높음)
3. JWT 발급

각 서비스에서 JWT 발급이 끝난다면

API Gateway
1. JWT 검증 및 사용자 정보 추출(Filter)
2. 인증된 요청을 각 서비스로 전달

검증까지 필요하다면 API Gateway전에 상품을 올리는 product Service로 검증해볼 수 있겠다.

끝!

다음 포스팅 부터는 진짜 개발이 진행될 예정이다.