서비스 검색,로드 균형 조정 및 연결 풀링 접근

Question

AWS와 같은 클라우드에 배치 된 대규모 시스템에 SOA를 사용하는 경우 서비스 상호 작용에 사용할 수있는 두 가지 접근 방법이 있습니다.

1. 내부 서비스 그룹 뒤에 각 서비스 클러스터를 두십시오. 클라이언트는 해당 엘브와 연결 풀을 만들고 엘브는 라운드 로빈 균형 조정을 수행합니다.

2. netflix eureka와 같은 서비스 검색 방식을 사용합니다. 각 서비스 클러스터 내부 ELB 뒤에 클라이언트는 각각의 클라이언트 인스턴스가 ELB 엔드 포인트 만 1 풀 즉를 유지하는 ELB를 통해 통신 곳

현재 우리는 첫번째 접근 방식을 사용하고 있습니다.

제 2의 apporach에 관해서 다음과 같은 의문의 여지가 있습니다.

1. 서비스 클라이언트는 (해당 유레카 서비스 또는 통해) 모든 서비스 인스턴스를 알고 내부 부하 분산을 수행 서비스 검색 및 스마트 클라이언트 아키텍처로 이동의 혜택이 있습니까?
2. 위의 경우 연결 풀링은 어떻게 작동합니까? 현재 각 클라이언트 인스턴스는 정확히 1 개의 연결 풀 즉 해당 서비스 엘브를 유지해야합니다. 그러나 리치 클라이언트를 사용하면 각 클라이언트는 직접 통신 할 수있는 모든 서비스 인스턴스 엔드 포인트를 갖게됩니다. 각 요청에 연결하는 것은 효율적이지 않으며 각 클라이언트에 대한 연결 풀 (각 서비스 인스턴스 당 1 개)이 너무 많아 과잉이라고 생각합니다.

위의 두 가지 질문에 대한 의견이 필요합니다.

Answer 1

첫 번째 질문입니다.

예 있습니다. 먼저, 장애 복구를보다 잘 수행 할 수 있습니다 (예 : 클라이언트에 오류를 표시하지 않고 다른 노드로 실패한 요청을 다시 시도). 다음으로 ELB가 제공하는 것보다 더 나은 균형을 유지할 수 있습니다. 다음으로 ELB 구성을 변경하지 않고 클러스터에 노드를 추가/제거 할 수 있습니다. 노드에 상태 확인이있는 경우 매우 유용합니다. 더 중요한 것은 소프트웨어 밸런서가이를 빠르게 수행 할 수 있다는 것입니다.

두 번째 질문입니다.

노드 당 연결 풀이 있습니다. 즉 [클라이언트 코드의 API 메소드] -> [소프트웨어 밸런서] -> [노드 연결 풀] -> [노드 연결] -> [이 연결을 사용하여 요청]