week2 기술공유

마이크로서비스 아키텍쳐

마이크로서비스는 독립적인 프로세스 형태.

그래서 각기 배포할 수 있어야 하고, 개별적으로 개발 가능.

상호 독립적인 구조라서, 독립적인 db를 가지고 있고, 네트워크 통신 기능을 가질 수 있다.

• 여러개의 프로세스(서비스)가 통신을 하는 방식으로 분산처리 하는 것
• 마이크로서비스는 기본적으로 서버이지만, 다른 마이크로서비스에 정보를 요청해야하는 클라이언트가 되기도 한다. (서로서로 통신을 한다는 의미)

그래서 구현해야 하는게 무었인가 하면

1. 분산 아키텍쳐 (분산 시스템 구성 방법)

ex) 우리가 했던 에어비앤비

• 모노 아키텍쳐(하나의 프로세스)

• 분산 아키텍쳐(여러개 프로세스)

그런데 분산 아키텍처를 구성하려면, 저 세개의 프로세스간에 통신(네트워크)를 어떻게 연결할지 고민해야한다. 그런데 nodejs에선 꽤 쉽게 구현 할 수 있다.

각 프로세스를 망형(mesh)으로 구현 할 수 있다.

그래서 어떻게 구현할 거냐.

이런식으로 구현하면 된단다.

모든 노드의 정보들을 Distributor라는곳에 저장을 하고, 모든 노드들이 Distributor에 접근이 가능 하다면, 위의 mesh 형태 네트워크 구조와 같다 라는 컨셉.

그래서, Distributor를 구현해야 한다.

각 노드와 distributor는 http통신이 아닌, tcp 소켓으로 통신을 할 거다. 왜냐하면, 항상 연결되어 있어야 하기 때문에. 접속이 끊어진다 라던가? 장애가 발생 했을 경우 바로 알아채야 하기 때문에.

그래서 distributor의 중요한 3가지.

1. Distributor가 실행되지 않았을 경우, 노드들은 주기적으로 접속을 시도한다.
2. 새로운 노드가 Distributor에 접속하거나, 종료하면 이를 다른 노드들에게 전파한다.
3. Distributor가 종료되도, 각 노드는 알고 있는 정보를 이용해, 노드 간 접속 상태를 유지해야 한다.

결론. 각 서비스들은 tcp 소켓 통신을 할 수 있어야 하고( 서버로서의 역할), 이 tcp 서버는 Distributor의 클라이언트 이기도 하다.

결국, 각 서비스들은 요청이 오면 자신의 db 작업 후 적절한 정보를 응답해 주는 비즈니스 로직을 가지고 있는 tcp 서버 이면서 클라이언트 이다.

2. api 게이트웨이

위에서 설명했듯이, 프로세스(서비스)를 분산시켜서 실행하기 때문에 클라이언트에서 서비스를 요청하는데 어려움을 겪는다. 각 서비스별로 접속 정보나, 프로토콜?(규칙)을 다 알아야 하는데 생각만해도 복잡하다.

그래서, api 게이트웨이라는 계층을 하나 만들어, 얘가 통일된 인터페이스를 제공하고, 클라이언트는 이 인터페이스에 맞춰 api호출을 하게끔 한다.

그래서 api 게이트웨이는 client와 http 통신을 하면서 동시에, tcp 클라이언트로서 Distributor와 통신하는 구조. Distributor를 통해서 서비스(비즈니스 로직)을 호출해야 하기 때문에.

결론.

마이크로 아키텍쳐로 우리가 서비스 구현을 하기 위한 기반으로

각 프로세스가 통신할 수 있게끔 하기 위한 모듈 (Distributor) 와

서비스를 호출하기 위한 인터페이스를 제공하는 모듈 (API Gateway)

이 두가지를 구현해야한다.

부가적으로, 마이크로 아키텍쳐에서 장애처리나, 로깅, 배포 관리가 중요하다.