microservice

개발을 하다보면, 느껴지는게 분명 하나의 프로젝트를 만드는건데 그 프로젝트를 잘게 쪼개고 쪼개고 쪼개고 쪼개고

그걸 넣고 넣고 넣고 넣고 넣어서 모듈화(=합쳐주기) 해준다

백엔드 서버와 디비를 묶어서 service라고 부르고

auth서비스, board서비스 … 이런식으로 부른다.

브라우저에서 어떤 디비로 가야해? 라고 궁금해할텐데

그때 사용하는게 API게이트웨이 이다.

근데 만약 기능들을 나눠주면 그거에 맞춰서 디비도 분할을 해줘야한다.

그러면 3개(인증, 게시판, 상품)로만 나눈다고 하더라도 인증 백엔드1, 디비1, 게시판 백엔드1, 디비1, 상품 백엔드1, 디비1,

• API게이트웨이까지 총 7개의 컴퓨터가 필요하다.

왜이렇게 컴퓨터 7개를 사용하면서까지 해야하는지에 대한 의문이 들 수 있다.

그런데도 불구하고 이렇게 해야하는 이유는

1. 소스코드가 엄청 많아지면 빌드(최적화, 압축)할때 시간이 너무 오래걸림

   => 게시판 api가 바뀌면 게시판 폴더만 빌드하면 되지 뭐하러 전체 빌드를 해?

2. 에러나서 서버 죽으면 모든 API가 사용 불가능해진다

   => 게시판이 죽어도 상품, 로그인 등 나머지는 모두 사용가능하다.

3. Nestjs 개발자만 뽑아야됨

   => 게시판은 Nestjs, 상품은 Django, 로그인은 Spring 등 다양한 개발자를 채용 가능하다.

그렇지만 7개의 컴퓨터를 사서 그 서버비용을 지불할 만큼 서비스가 클때 사용하는게 좋다.

규모가 작으면 저렇게 할 이유가 전혀 없음.

그래서 필수는 전혀 아니다.

또한 단점을 전체적인 기술 복잡도가 증가하는게 또다른 이유가 될 수 있겠다.

그치만 만약 프로젝트 규모가 크다면… 거의 필수일듯 싶다.

내가 서버 백엔드로 들어가본적이 없어서 모르지만

없으면… 아주 큰일이 날 것 같은 느낌인데..? ●︿●

이게 또 restAPI를 쓸때와 graphql을 쓸때 설정해주는 방식이 다른데,

한번 알아보도록 하자

Nest기반 Rest-API의 마이크로서비스 분리

GraphQL의 마이크로서비스 분리