molerculer는 kubernetes와 비슷하게 분산 시스템을 구축하고 관리하는 데 사용되는 도구이지만, 다른 목적과 영역에서 작동한다.
Moleculer:
- Moleculer는 마이크로서비스 아키텍처를 구현하고 관리하는 데 사용되는 모듈러 서비스 프레임워크입니다.
- Node.js로 작성되었으며, 빠르고 확장 가능한 마이크로서비스 어플리케이션을 쉽게 개발할 수 있도록 지원합니다.
- 서비스 간 통신, 분산 환경에서의 데이터 교환, 로드 밸런싱, 서비스 디스커버리 등의 기능을 제공하여 마이크로서비스 아키텍처를 구현하는 데 도움을 줍니다.
- Moleculer는 마이크로서비스 아키텍처를 구현하는 데 사용되는 프레임워크로, 애플리케이션의 내부 로직을 분리하여 서비스로 구성하고 관리할 수 있습니다.
Kubernetes (K8s):
- Kubernetes는 컨테이너화된 어플리케이션의 배포, 확장 및 관리를 자동화하는 오픈 소스 컨테이너 오케스트레이션 플랫폼입니다.
- 컨테이너화된 어플리케이션의 배포 및 관리를 위한 클러스터링, 자동 스케일링, 로드 밸런싱, 스토리지 관리, 서비스 디스커버리 등의 기능을 제공합니다.
- 어플리케이션을 여러 호스트에 분산하여 가용성을 높이고, 확장성을 확보할 수 있으며, 무정지 배포와 같은 고급 기능도 제공합니다.
- Kubernetes는 컨테이너 오케스트레이션 플랫폼으로, 컨테이너화된 애플리케이션의 배포, 관리, 스케일링을 자동화하여 대규모 분산 시스템을 운영할 수 있도록 지원합니다.
요약하자면, Moleculer는 1개의 어플리케이션의 내부 구조를 각각의 노드로 분리시켜 마이크로서비스 아키텍쳐를 구현한 것이며
k8s는 여러 어플리케이션을 배포한 인프라스트럭처를 관리하는데 중점이 있다.
따라서 Moleculer를 이용해 마이크로 서비스 아키텍처를 구현하고 Kubernetes를 사용해 배포하는 방식을 사용하는 방법도 있다고 한다.
공식문서를 참고하면서 같이 살펴보자
대략적인 구조는 이렇다.
client에게 요청을 받으면 gateway가 service에게 요청을 보내고 helper service에게 또다른 요청을 하게 된다.
gateway는 redis, nats, Mqtt 등 메시지브로커 역할을 할 수 있는 것이면 어떤것이든 가능하다.
주요 개념은 service, node, service broker가 있다.
각 서비스가 기본 모듈 단위를 말하며, 노드는 프로세스를 말한다.
프로세스 내에는 여러 서비스가 있을 수도 있고 1개의 서비스만 있을 수도 있다.
서비스브로커는 서비스간 통신을 하기 위해 노드마다 1개씩 있다.
각 노드의 구조는 위와 같은 형태일 것이며,
1개의 노드에 여러 1개의 서비스브로커 그리고 여러 서비스가 있는 구조 혹은 1개의 서비스만 있는 구조로 노드(프로세스)가 존재할 것이다.
이 노드들 안에 있는 서비스끼리 데이터를 구조받기 위해서 서비스브로커가 각 노드마다 1개씩 존재한다.
그래서 각 서비스브로커가 보낸 요청을 메시지브로커가 받는다.
메시지브로커는 moleculer에서는 Transporters 라고 부른다.
데모버전 실행
npm i moleculer-cli
npx moleculer init project moleculer-demo
cd moleculer-demo
npm run dev
선택사항이 꽤 많다.
위처럼 선택사항에 따라 파일을 만들어준다.
우선 기본 예시 파일인 services/greeter.service.js 파일을 보자
settings : 서비스의 설정을 정의하는데 사용되며 서비스가 필요로하는 구성옵션, 환경변수설정, 데이터베이스 연결 정보가 포함된다.
서비스 전체에서 공유되며 필요한 경우 서비스 내에 다른 부분에서도 참조 가능하다.
dependencies : 현재 서비스가 의존하는 다른 서비스들을 나열하는 데 사용한다. 의존성을 명시해 다른 서비스에 대한 호출을 수행 할 수 있다.
actions : 현재 서비스가 제공하는 작업들을 정의하는 데 사용된다. 각 작업은 클라이언트 또는 다른 서비스에서 호출할 수 있는 기능이며, 이런 작업을 통해 서비스 간의 통신과 데이터 교환을 수행한다. actions는 정의된 작업 이름과 핸들러로 구성되며, 핸들러는 작업이 수행될 때 동작한다.
즉, 요약하자면, 서비스의 설정, 의존성, 어떠한 작업을 할 것인지를 설정하는 부분이라고 보면 된다.
services/greeter.service.js을 보자.
- methods : 현재 서비스에서 사용할 사용자 정의 메서드를 정의하는 데 사용된다.
Service Lifecycle Event Handlers
Moleculer 서비스는 라이프 사이클 이벤트를 가진다. 각 이벤트는 서비스의 생명주기 동안 특정한 시점에 발생하며, 서비스의 상태 변경을 추적하고 제어하기 위해 사용된다.
- created : 서비스가 생성된 직후에 호출된다. 서비스의 초기화를 수행한다.
- started : 서비스가 시작된 직후에 호출된다. 서비스가 활성화되었음을 나타내며, 주요 기능을 수행한다.
- stopped : 서비스가 중지된 직후에 호출된다. 서비스가 종료되거나 일시 중단되었음을 처리한다.
이제는 services/api.service.js를 보자
각 서비스의 Ip, 포트, routes의 path를 지정하고 middleware 설정하는 부분이 있다.
로깅, json 크기는 얼만큼 지정할것인지 등 세세하게 설정가능하다.
assets은 정적파일을 제공하기 위한 디렉토리 경로 설정을 말한다.
public 디렉토리 하부에 정적파일이 저장된다.
해당 package.json 파일을 보자.
npm run dev로 하라고 되어있다.
생성되어있는 config 파일을 찾고 서비스 브로커를 실행한다.
그다음 services 디렉토리를 찾아서 모든 js 파일을 로드한다.
따라서 서비스브로커(아까 Nats 선택함)을 실행하거나 local이니까 Null로 해서 서비스브로커를 띄우지 않게 해야 npm run dev를 실행할 수 있다.
성공적으로 4개 서비스가 띄워졌다고 한다.
js 파일은 3개이지만, 기본적으로 모든 서비스 작업과 이벤트 추적을 위해 $node라는 서비스가 자동으로 띄워지므로 3 + 1 이라 4개이다.
localhost:3000 으로 들어가면 위처럼 페이지가 뜰 것이다.
swagger 같은 기능도 제공한다.
테스트도 가능하다.
새로운 서비스를 작성하고 등록해보자.
터미널에 load services/helper.service.js라고 하니 성공적으로
터미널에서 emit "이벤트이름" --payload '전송할 텍스트' 로 하면 테스트 가능하다.
actions는 클라이언트의 요청에 대한 응답으로 호출되고
events는 특정 조건이나 상황에 따라 내부적으로 자동으로 발생하거나 외부 이벤트 수신할 때 사용되므로 구별해서 사용하면 된다.
위처럼 terminal에서 클라이언트의 호출로 바로 실행되었다.
다른 서비스에서 helper의 event나 actions을 사용하고 싶다면, ctx 컨텍스트를 이용해 해당 서비스를 호출하면 받은 NodeID를 통해 컨텍스트를 받고 응답이나 요청을 할 수 있게 된다.
docker-compose로 배포하기
moleculer.config.js 에서 구성요소를 찾고 브로커를 생성하면 모든 서비스가 로드된다.
해당 서비스를 모두 로드하려면 디렉터리를 설정하고, 특정 파일만 하려면 해당 파일을 설정한다.
위 설정은 services 디렉터리 모두 로드하려고 한다.
위처럼 서비스를 더 띄워보자
도커 컴포즈 파일을 위처럼 추가해보자.
npm run dc:up 으로 코드 수정사항을 변경하고 배포해보자.
정상적으로 배포되었다면 localhost:3000으로 들어가던가 해당 도커 컨테이너 ip:3000 들어가면 된다.
