1. Service Discovery
1-1. Client Side Discovery
1-2. Server Side Discovery
2. API Gateway(Eureka + zuul)1. Service Discovery
서비스의 위치를 기억해둔 뒤 클라이언트 요청에 따라 각각의 서비스 위치를 알 수 있는 기능을 Service Discovery라고 한다.
MSA 환경에서는 클라이언트의 요청 수에 따라 서비스가 생기기도, 사라지기 때문에 계속해서 변하는 서비스의 위치를 찾아주는 Service Discovery 기능이 필요
1-1. Client Side Discovery
Service 들을 모두 Service Registry(서비스 등록 서버)에 등록한 뒤 요청이 들어오면 Service Registry를 통해 서비스를 찾는 방식
Service Registry
요청에 대한 서비스를 찾아주는 역할로 Eureka가 이에 해당
장점
- 비교적 간단하다
- 클라이언트가 사용 가능한 서비스 인스턴스에 대해서 알고 있기 때문에 각 서비스별 로드 밸런싱 방법을 선택할 수 있다
단점
-
클라이언트와 서비스 레지스트리가 연결되어 있어서 종속적이다
-
서비스 클라이언트에서 사용하는 각 프로그래밍 언어 및 프레임 워크에 대해서 클라이언트 측 서비스 검색 로직을 구현해야 한다
1-2. Server Side Discovery
클라이언트와 Service Registry 앞에 로드밸런서(proxy 서버)를 넣는 뒤 로드밸런서와 Service Registry의 호출을 통해 서비스를 찾는 방식
Load Balancer
보안을 위한 요청 차단, 주소 통일 등과 많은 요청이 들어왔을 때 적당한 분배를 하는 Proxy 서버로, Zuul이 이에 해당
장점
- discovery의 세부 사항이 클라이언트로부터 분리되어있다(의존성 ↓)
- 분리 되어 있어 클라이언트는 단순히 로드 밸런서에 요청만 한다 따라서 각 프로그래밍 언어 및 프레임 워크에 대한 검색 로직을 구현할 필요가 없다
- 일부 배포환경에서는 이 기능을 무료로 제공한다
단점
-
로드밸런서가 배포환경에서 제공되어야 한다
-
제공되어있지 않다면 설정 및 관리해야하는 또 다른 고 가용성 시스템 구성 요소가 된다
2. API Gateway(Eureka + zuul)
서비스의 엔드포인트가 유동적으로 변해 DNS, Endpoint, mapping, instance를 관리하는 Service Discovery를 자동화한 것
Netflix 에서는 Eureka와 zuul 이라는 오픈소스를 만들어 API Gateway를 관리
Endpoint : API의 최종 URI (https://velog.io/write?id=156cb51c-e87b-49c0-b350-a3deca30dd8f)
DNS(Domain Name System) : 영문/한글 주소(velog.io)를 IP(3.34.63.233)로 변환해주는 시스템
출처
https://bcho.tistory.com/1252
https://mangchhe.github.io/springcloud/2021/04/07/ServiceDiscoveryConcept/
