Service discovery pattern이란
MSA와 같은 분산 환경은 서비스 간의 원격 호출로 구성이 된다. 원격 서비스 호출은 IP 주소와 포트를 이용하는 방식이 됩니다.
클라우드 환경이 되면서 서비스가 오토 스케일링등에 의해서 동적으로 생성되거나 컨테이너 기반의 배포로 인해서, 서비스의 IP가 동적으로 변경되는 일이 잦아졌습니다.
그래서 서비스 클라이언트가 서비스를 호출할때 서비스의 위치 (즉 IP주소와 포트)를 알아낼 수 있는 기능이 필요한데, 이것을 Service discovery (Eureka Server)라고 합니다.
위의 그림에서 Service A의 인스턴스들이 생성이 될때, Service A에 대한 주소를 Service registry (서비스 등록 서버)(Eureka Server) 에 등록합니다. Service A를 호출하고자 하는 클라이언트는 Service registry에 Service A의 주소를 물어보고 등록된 주소를 받아서 그 주소로 서비스를 호출합니다.
MicroService와 Eureka server간 통신
각 마이크로서비스는 구동 시 Service Discovery(Eureka Server)에 자신의 IP/FQDN과 PORT를 등록하며 Service discovery pattern을 사용합니다.
Eureka Server는 주기적으로 각 마이크로서비스의 실행여부를 체크합니다. 정지된 경우, registry에서 삭제합니다.
각 마이크로서비스는 등록된 모든 마이크로서비스의 정보를 주기적으로 갖고 와서 캐싱할 수 있습니다.
한 마이크로서비스가 다른 마이크로서비스를 연결할때는 캐싱된 registry정보를 이용하거나 Eureka server를 조회하여 대상 마이크로서비스의 IP/FQDN과 PORT를 구해 연결합니다.
Client측 properties 설정
eureka:
client:
register-with-eureka: true
fetch-registry: true-
eureka.client.register-with-eureka
- 레지스트리에 자신을 등록할지에 대한 여부 (디폴트 true)
- 클러스터링 모드의 Eureka Server구성은 서로 peering 구성이 가능합니다.
(Eureka Server 설정에 정의된 peering 노드를 찾아서 레지스트리 정보의 sync 를 맞춥니다.) - 독립 실행형 모드(standalone)에서는 peering 실패가 발생하므로 Eureka Client측 동작을 끕니다.
-
eureka.client.fetch-registry
- 레지스트리에 있는 정보를 가져올지에 대한 여부 (디폴트 true)
- true로 설정 시 검색할 때마다 Eureka Server 를 호출하는 대신 레지스트리가 로컬로 캐싱됩니다.
- 30초마다 Eureka Client 가 유레카 레지스트리 변경 사항 여부 재확인합니다.
*peering : 서로 네트워크를 연결하고 트래픽을 교환
refer :
https://assu10.github.io/dev/2020/12/05/spring-cloud-eureka-configuration/
https://happycloud-lee.tistory.com/210 [온달의 해피블로그]
https://medium.com/@ijayakantha/microservices-service-registration-and-discovery-with-netflix-eureka-9a2aa729da96
https://bcho.tistory.com/1252 [조대협의 블로그]
