Micro Service Architecture

Micro Service Architecture

1. MSA라 부르는 아키텍처를 왜 사용?

• 반의어: 모놀리틱 아키텍처
  • 한 서비스 안에 모든 게 다 들어가 있음
    • 상품상세
    • 상품 정보
    • 결제
    • 장바구니
    • 기타 등
  • 구현의 속도는 빠른데, codebase가 커짐.
  • 스파게티 코드들이 많아질 가능성 높음
    • 결제를 어디까지 봐야돼?
    • 이미 이해할 수 없는 수준으로 커짐
    • 결제를 구현한 사람이 퇴사를 하면, 결제는 blackbox가 되어버림
    • 어디까지가 결제 영향권인지 모름
    • A가 죽으면 b, c, d 전체가 다 죽음
  • 초기 스타트업에 적합 => MSA에 비하면 훨씬 빠름
• MSA
  • 상품 서비스
  • 결제 서비스
  • 장바구니 서비스
  • 기타 서비스
  • 장점
    • 관심사 분리
    • Layer 별로 격리가 됨
    • 서비스 사이의 인터페이스가 필요하지만, 기본적으로는 인터페이스를 정리하기 용이
    • 회사의 조직 구조 짜기에 용이
      • 각자가 맡고 있는 서비스에만 충실하면 회사가 잘 굴러갈 수 있음
  • 단점
    • 인력이 많이 필요
    • 서비스마다 해야할 일이 많음
    • 서비스가 커질 수 밖에(?)
  • FE > API(gateway )
    • 어떤 API를 찌르든 endpoint는 하나로 유지를 시키고, 중개서버를 둘 수 있음
    • 
    • API gateway를 산 상태로 유지시키는 게 중요한 미션이 됨
    • 어떤 아키텍처를 가지고 있든, client는 알 필요 없음.
    • API (Header, Body) => Response 관리하기에 수월
    • 서비스가 분리됨 => 서비스 별로 API가 나올 수도 있고 안나올 수도 있음
    • API Gateway
      • Scaling
      • auth 서비스
      • 원하는 response 얻어낼 수 있음 > 화면에 렌더링 어떻게 할지 얻어내는지 중요
        • pay.api
        • cart.api
        • product.api
        • 관리하는 서비스가 많아질 수록 클라이언트에서 관리해야하는 API 개수도 그만큼 많아짐
        • => API Endpoint를 통일 시키고, PATH만 관리하는 것을 추천
    • BFF Layer
    • MFA => front에서의 MSA
• 서비스를 잘게 쪼개고 각 모델 별로 서비스를 관리하는 것
• 결제가 죽어도, 상품이 살아있으면 서비스 전체는 살아있음