카테고리 없음

02-01. MSA - 마이크로서비스 아키텍처 기반 주문 처리 시스템

Dev.99_tale 2025. 3. 10. 00:37

주문이 들어왔어! -> 주문확인 - 상품 확인 - 유저 확인 애플리케이션이 있겠네?

1. 그렇다면 필요한 어플리케이션은 ? Order, Product, User

2. 만약 주문에서 상품을 봐야해 어떻게 해 ? 컨트롤은 Ribbon에서 실제 호출은 Feign Client를 통해서 해준다.

3. host관리를 위해 Eureka서버에 모두 등록 (그럼 모든 APP들이 Eureka Client가 된다.)

4. 그럼 실제 Client가 각 어플들을 일일 호출해야해 ? API Gateway로 호출을 보내고 API Gateway에서 알아서 요청을 보내고 처리해준다.

5. 로그인된 사용자만 사용하게 해줘야 하지 않을까 ? API Gateway가 해주면 좋겠다!! 필터 기능으로 처리

6. 만약 Order가 Product와 User를 호출하는데 User 요청을 병렬처리 하다가 에러가 난다면 ? 서킷 브레이커(Resilience4j)를 통해 알아보도록 하자(Failover 처리), 에러 상황 처리에 대한 판단

7. 애플리케이션 마다 각각의 yml 파일(설정 파일)을 일일이 수정하는 번거로움을 해결하고 싶어 -> 그럼 모든 yml파일을 저장하는 Config서버를 만들자.

8. 주문이 들어왔고, 각 주문 -> 상품 -> 유저 확인 앱들에 호출이 들어가면 우리는 어떻게 호출이 되는지 몰라... 

 -> 그렇기 때문에 분산 추적(Zipkin)을 통해서 요청이 들어왔을때 어떻게 호출이 되는지 알아볼거야!


🔹 1. 필요한 애플리케이션

  • Order 서비스 (주문)
  • Product 서비스 (상품)
  • User 서비스 (유저)

🔹 2. 서비스 간 호출 및 통신 방법

  • 주문(Order)에서 상품(Product) 정보를 조회해야 한다면?
    • Ribbon(클라이언트 측 로드 밸런싱)으로 컨트롤
    • Feign Client를 사용해 실제 호출

🔹 3. 서비스 등록 및 관리

  • 모든 애플리케이션을 Eureka 서버에 등록하여 서비스 디스커버리 기능 활용
  • 모든 애플리케이션이 Eureka Client가 됨

🔹 4. API 요청 처리 방식

  • 각 클라이언트가 여러 서비스에 직접 호출을 보내야 할까?
    • ❌ No!
    • ✅ API Gateway를 사용해 클라이언트의 요청을 한 곳으로 모아 처리
    • API Gateway가 내부 서비스로 요청을 라우팅함

🔹 5. 보안 및 접근 제어

  • 로그인한 사용자만 서비스 이용 가능해야 한다면?
    • ✅ API Gateway에 필터 기능 추가하여 인증 및 보안 처리

🔹 6. 부하 분산 (로드 밸런싱)

  • 같은 서비스가 여러 개 배포되어 있을 때, 요청을 효율적으로 분배해야 한다면?
    • ✅ 라운드 로빈 방식 적용 (Ribbon & Eureka)
    • 클라이언트가 Ribbon을 사용하여 라운드 로빈 방식으로 요청을 분배
    • Eureka 서버에서 여러 개의 인스턴스를 관리하며 순차적으로 요청을 전달

🔹 7. 장애 대응 및 안정성 확보

  • Order 서비스가 Product와 User를 호출하는데, User 서비스에서 오류 발생하면?
    • ✅ 서킷 브레이커(Resilience4j) 적용
    • 장애 발생 시 Failover 처리하여 시스템 안정성 유지

🔹 8. 설정 관리 최적화

  • 서비스마다 개별적으로 yml 설정 파일을 관리하는 게 번거롭다면?
    • ✅ Config 서버 구축
    • 모든 설정 파일을 한 곳에서 관리하여 유지보수 용이

🔹 9. 서비스 호출 추적

  • 주문(Order) -> 상품(Product) -> 유저(User) 호출이 어떻게 이루어지는지 알고 싶다면?
    • ✅ 분산 추적 시스템 (Zipkin) 도입
    • 요청 흐름을 시각화하여 분석 가능

💡 전체 아키텍처 흐름 요약

  1. 클라이언트가 API Gateway로 요청
  2. API Gateway가 Order 서비스로 요청 전달
  3. Order 서비스가 Product & User 서비스 호출 (Feign Client 사용)
  4. 서비스 간 요청 경로는 Eureka 서버를 통해 관리
  5. Ribbon을 사용한 라운드 로빈 방식으로 여러 개의 서비스 인스턴스에 부하 분산
  6. 장애 발생 시 Resilience4j 서킷 브레이커로 안정성 확보
  7. 설정은 Config 서버에서 일괄 관리
  8. 서비스 호출 흐름은 Zipkin으로 추적 가능