Service Discovery_시스템 설계 노트 7

일.애플리케이션 층

단순한 3 층 구조에서, Web 서비스 층은 요청을 처리함과 동시에 비즈니스 기능도 담당합니다:

더 우수한 구조는 Web 층과 애플리케이션 층 (플랫폼 층이라고도 함) 을 분리하는 것입니다:

우위성은 다음과 같습니다:

애플리케이션 층을 단독으로 확장 가능: 독립적으로 머신을 추가하거나, 전용 머신으로 교체하는 것을 허용
인프라스트럭처를 复用: 멀티엔드 지원을 간소화하고, 캐시, 데이터베이스 등 처리를 모두 复用 가능
조직 확장을 용이하게: 하나의 팀이 플랫폼 자체의 구현/최적화를 담당하고, 다른 여러 팀이 플랫폼 기능을 이용하여 개발

애플리케이션 층을 분리한 후, 다음에 직면하는 문제는애플리케이션 층 내부에서 어떻게 직책을划分하고, 어떻게 협동 작업하는가로,也就是마이크로서비스 아키텍처가 해결하려는 문제입니다

이.마이크로서비스 아키텍처

마이크로서비스 아키텍처는 애플리케이션을 일련의 소결합한 세분화 서비스로 설계하고, 경량 통신 프로토콜을 통해 조직할 것을 제창:

In a microservices architecture, an application is structured as a collection of loosely coupled services, which are fine-grained and the protocols are lightweight.

이들 서비스는 모두 독립적으로 배포, 독립적으로 확장 가능하며, 각 서비스는 견고한 모듈 경계를 가지며, 다른 프로그래밍 언어를 사용하여 다른 서비스를 작성하거나, 다른 팀이 관리하는 것도 허용:

P.S. 마이크로서비스 아키텍처에 대한 더 많은 정보는, [마이크로서비스 아키텍처 (Microservices)](/articles/마이크로서비스 아키텍처（microservices）/) 참조

마이크로서비스 아키텍처 하에서, 애플리케이션은 여러 서비스로 분할되어, 각각 (다른 머신의) 다른 프로세스에서 실행:

각 마이크로서비스가 단일 머신에서만 실행되는 경우, 하나의 마이크로서비스는 정적 설정표를 통해 다른 의존 서비스를 찾을 수 있고,进而서비스 간 통신을 통해 협력을 완료

그러나, 실제 시나리오에서는, 1 개의 마이크로서비스는 일반적으로 여러 머신에 배포되며, 필요에 따라 동적으로 신축 (머신의 증감) 합니다.シンプルな 정적 설정으로는 분명히 만족할 수 없으므로, 하나의 서비스 등록 조회 메커니즘이 필요합니다:

즉 Service Discovery 입니다

삼.Service Discovery

클라이언트 측 Service Discovery

클라이언트가 서비스 등록표를 조회하여, 목표 서비스의 일련 주소를 얻고, 로드밸런싱 전략에 따라 그 중에서 하나를 선택하여 요청을 시작 (즉 클라이언트 측 로드밸런싱)

그 중에서, 서비스 등록표 (service registry) 는 사용 가능한 모든 서비스 인스턴스를 저장하고, 관리 (등록/등록 해제) 와 조회 API 를 제공:

The service registry is a database of available service instances. The service registry provides a management API and a query API. Service instances are registered with and deregistered from the service registry using the management API. The query API is used by system components to discover available service instances.

구체적으로는, 서비스 인스턴스를 시작할 때, 등록표에 그 네트워크 위치를 추가하고, 서비스를 정지할 때 기록을 삭제하며, 서비스 인스턴스 실행 기간 중, 하트비트 메커니즘을 통해 주기적으로 등록 정보를 업데이트

P.S. 예를 들어 Netflix Eureka 는 REST API 를 제공하여 서비스 인스턴스의 등록/등록 해제, 조회에 사용:

Netflix Eureka provides a REST API for registering and querying service instances. A service instance registers its network location using a POST request. Every 30 seconds it must refresh its registration using a PUT request. A registration is removed by either using an HTTP DELETE request or by the instance registration timing out. As you might expect, a client can retrieve the registered service instances by using an HTTP GET request.

및 配套의 Netflix Ribbon, 클라이언트 측 로드밸런싱으로 사용

이 모드는 비교적シンプル하고, 클라이언트가 더 똑똑한 (예를 들어 애플리케이션 특정의) 로드밸런싱 결정을 내릴 수 있지만, 몇 가지 단점도 존재:

클라이언트가 사용하는 각 언어마다 하나씩 구현할 필요
고가용의 등록 서비스를自行으로 유지할 필요
서비스 발견 관련 로직이 모두 클라이언트에서 구현되며, 예를 들어 재시도, 클라이언트가 비교적 무거워짐

DNS-SD

特殊的, DNS 를 서비스 등록표로 사용할 수 있으며, DNS-SD (DNS-based Service Discovery) 라고 함

DNS SRV 기록을 통해 서비스에서 인스턴스로의 1 대 다 매핑을 완료:

SRV 기록 (Service locator record): 通用서비스定位기록, 서비스가所在하는 서버 (도메인명과 포트번호) 를 지정, 주로 SIP(Session Initiation Protocol, 세션 개시 프로토콜) 에 사용

(자원 기록 | DNS_시스템 설계 노트 3 에서 발췌)

예를 들어:

$ nslookup -query=SRV _http._tcp.backends.example.com 10.0.0.2
Server:		10.0.0.2
Address:	10.0.0.2#53

_http._tcp.backends.example.com	service = 0 2 8090 backend-0.example.com.
_http._tcp.backends.example.com	service = 0 1 8091 backend-1.example.com.
_http._tcp.backends.example.com	service = 10 1 8092 backend-2.example.com.

DNS 를借助하면シンプル하고 조작하기 쉽지만, DNS 의 업데이트 시효 (캐시 문제) 에 제한됨

서버 측 Service Discovery

물론, 조회 프로세스는 서버 측에서 완료할 수도:

클라이언트가 로드밸런서를 통해 목표 서비스에 요청하고, 로드밸런서가 등록표를 조회하여 사용 가능한 인스턴스 그룹을 얻고, 로드밸런싱 전략에 따라 그 중에서 하나를 선택하여 요청을 시작

P.S. 예를 들어 AWS Elastic Load Balancer (ELB)

이 모드에서는, 클라이언트는 각종 언어, 다른 프레임워크를 위해 서비스 조회 로직을 구현할 필요가 없고,シンプル하게 로드밸런서에 요청을 시작하면 되지만, 배포 플랫폼이 이 능력을 제공하지 않는 경우, 이러한 고가용의 시스템 컴포넌트를自行으로建立하고 유지할 필요

사.서비스 등록과 등록 해제

Service Discovery 중, 서비스 인스턴스는 서비스 등록표에 등록하고, 시기에注销할 필요가 있으며, 자등록과 제 3 자 등록의 2 종 모드로 나뉩니다

자등록 모드

자등록 모드에서는, 서비스 인스턴스가 자신을 서비스 등록표에 등록하고, 거기서注销하는 것을 담당하며, 필요하면, 하트비트 요청을 전송하여 활성을 유지하고, 등록 기한 만료를 회피

이 방식은 비교적シンプル하고, 다른 시스템 컴포넌트에 의존하지 않지만, 서비스 인스턴스와 서비스 등록 메커니즘이 결합하여,以致って 등록 로직을 각종 언어, 다른 프레임워크의 클라이언트에서 모두 하나씩 구현할 필요

P.S. Netflix OSS Eureka client 가 채택하고 있는 것은 이 모드로, Eureka 클라이언트가 서비스 인스턴스의 등록과注销을 처리

제 3 자 등록 모드

서비스 인스턴스는 더 이상 등록/注销을 담당하지 않고, 서비스 등록원 (service registrar) 에交由하여 처리하며, 서비스 인스턴스와 등록 메커니즘 간의 결합 관계를 해제. 등록원은 배포 플랫폼을 순회하거나 이벤트를 구독하여 서비스 인스턴스의 실행 상태를 추적하고, 새로운 서비스 인스턴스를 발견하면 등록하고, 서비스 인스턴스가 정지한 것을 발견하면注销

P.S. Registrator 가 이 모드를 채택하여, Docker 컨테이너로 배포된 서비스의 자동 등록/注销을 지원

特殊的, 배포 플랫폼은 서비스 인스턴스의 시작과 정지를 掌控하고 있으며, 그것이 등록,注销을 완료하는 것이 가장 적합. 사실, Kubernetes 와 Marathon 등의 배포 플랫폼도 서비스 등록, 조회 능력을 제공. 구체적으로는, 클러스터 중의 각 노드에서 실행되고 있는 대리 서비스를 서버 측 Service Discovery 중의 로드밸런서로 사용하고, 클라이언트가 대리에 요청을 전송하면, 대리 서비스가 클러스터 중의 다른 노드 상의 사용 가능한 인스턴스로 전달

오.정리

마이크로서비스 아키텍처는 서비스 분할과 의존 관계 결합 해제를 담당하며, Service Discovery 는 이들 서비스 간 통신 문제를 해결하여, 한 마이크로서비스가 다른 마이크로서비스를 찾을 수 있게 합니다

구현상, 클라이언트 측 Service Discovery 와 서버 측 Service Discovery 의 2 종으로 나뉘며, 차이는 조회/선택 로직이 클라이언트 측인가 서버 측인가에서 구현되는가. 그리고 서비스의 등록/注销은 서비스 자신이 완료 (자등록), 또는 배포 플랫폼 등의 제 3 자가 완료 (제 3 자 등록)