리본 로드 밸런싱
1.1 로드 밸런싱 원리
Spring Cloud의 최하위 계층은 실제로 리본이라는 구성 요소를 사용하여 로드 밸런싱 기능을 구현합니다.
그렇다면 우리가 보낸 요청은 분명히 http://userservice/user/1인데 왜 http://localhost:8081이 되었을까요?
1.2 소스코드 추적
왜 서비스 이름만 입력하면 접속이 되나요? 또한 먼저 IP와 포트를 얻어야 합니다.
분명히 누군가가 서비스 이름을 기반으로 서비스 인스턴스의 IP와 포트를 얻는 데 도움을 준 것 같습니다. 즉 LoadBalancerInterceptor, 이 클래스는 RestTemplate 요청을 가로채서 서비스 ID를 기반으로 Eureka에서 서비스 목록을 얻은 다음 로드 밸런싱 알고리즘을 사용하여 실제 서비스 주소 정보를 얻고 서비스 ID를 대체합니다.
우리는 소스 코드 추적을 수행합니다:
1)LoadBalancerIntercepor
여기에서 Intercept 메소드가 사용자의 HttpRequest 요청을 가로채고 여러 가지 작업을 수행하는 것을 볼 수 있습니다.
request.getURI(): 요청 URI를 가져옵니다(이 경우 http://user-service/user/8).originalUri.getHost(): 실제로 서비스 ID인 URI 경로의 호스트 이름을 가져옵니다.user-servicethis.loadBalancer.execute(): 서비스 ID 및 사용자 요청을 처리합니다.
유형은 다음과 this.loadBalancer같습니다 LoadBalancerClient. 계속해서 따라가겠습니다.
2) LoadBalancer클라이언트
계속해서 실행 메소드를 따르십시오.
코드는 다음과 같습니다:
- getLoadBalancer(serviceId): 서비스 ID를 기반으로 ILoadBalancer를 가져오고 ILoadBalancer는 서비스 ID를 가져와 eureka에서 서비스 목록을 가져와 저장합니다.
- getServer(loadBalancer): 내장된 로드 밸런싱 알고리즘을 사용하여 서비스 목록에서 하나를 선택합니다. 이 예에서는 포트 8082의 서비스가 획득되었음을 확인할 수 있습니다.
풀려난 후 다시 방문해서 추적해보니 8081이 나왔습니다.
물론 로드 밸런싱이 달성되었습니다.
3) 로드 밸런싱 전략 IRule
지금 코드에서는 서비스 획득 시 메서드를 사용하여 getServer로드 밸런싱을 수행하는 것을 볼 수 있습니다.
계속해서 후속 조치를 취하겠습니다.
소스 코드 chooseServer 메소드를 계속 추적하면서 다음 코드 조각을 발견했습니다.
이 규칙이 누구인지 살펴보겠습니다.
여기서 규칙의 기본값은 one 입니다 RoundRobinRule. 클래스 소개를 참조하세요.
이것이 여론조사의 의미가 아닌가?
이 시점에서 우리는 전체 로드 밸런싱 프로세스를 명확하게 이해했습니다.
4) 요약
SpringCloudRibbon의 하위 계층은 인터셉터를 사용하여 RestTemplate에서 보낸 요청을 가로채고 주소를 수정합니다. 사진으로 요약하자면 이렇습니다.
기본 프로세스는 다음과 같습니다.
- RestTemplate 요청 http://userservice/user/1을 가로채세요.
- RibbonLoadBalancerClient는 요청 URL(user-service)에서 서비스 이름을 가져옵니다.
- DynamicServerListLoadBalancer는 사용자 서비스를 기반으로 유레카에서 서비스 목록을 가져옵니다.
- 유레카는 localhost:8081, localhost:8082 목록을 반환합니다.
- IRule은 내장된 로드 밸런싱 규칙을 활용하고 목록에서 localhost:8081과 같은 규칙을 선택합니다.
- RibbonLoadBalancerClient는 요청 주소를 수정하고, userservice를 localhost:8081로 대체하고, http://localhost:8081/user/1을 가져오고, 실제 요청을 시작합니다.
1.3 로드 밸런싱 전략
1.3.1 로드 밸런싱 전략
로드 밸런싱 규칙은 IRule 인터페이스에 정의되어 있으며 IRule에는 다양한 구현 클래스가 있습니다.
다양한 규칙의 의미는 다음과 같습니다.
| 내장된 로드 밸런싱 규칙 클래스 | 규칙 설명 |
|---|---|
| 라운드로빈규칙 | 간단히 서비스 목록을 폴링하여 서버를 선택하세요. 이는 리본의 기본 부하 분산 규칙입니다. |
| 가용성 필터링 규칙 | 다음 두 가지 유형의 서버를 무시하십시오. (1) 기본적으로 이 서버가 세 번 연결에 실패하면 이 서버는 "단락" 상태로 설정됩니다. 단락 상태는 30초 동안 지속되며, 다시 연결이 실패하면 단락 상태의 지속 시간이 기하급수적으로 늘어납니다. (2) 동시성이 너무 높은 서버. 서버에 대한 동시 연결 수가 너무 많으면 AvailabilityFilteringRule 규칙으로 구성된 클라이언트도 이를 무시합니다. 동시 연결 수의 상한은 클라이언트의 ..ActiveConnectionsLimit 속성으로 구성할 수 있습니다. |
| WeightedResponseTimeRule | 각 서버에 가중치를 부여합니다. 서버 응답 시간이 길수록 서버의 무게는 가벼워집니다. 이 규칙은 서버를 무작위로 선택하며 이 가중치 값은 서버 선택에 영향을 미칩니다. |
| 구역 회피 규칙 | 서버 선택은 해당 지역에서 사용 가능한 서버를 기반으로 합니다. Zone을 사용하여 서버를 분류합니다. 이 Zone은 컴퓨터실, 랙 등으로 이해될 수 있습니다. 그런 다음 영역에서 여러 서비스를 폴링합니다. |
| 사용 가능한 최고 규칙 | 단락된 서버는 무시하고 동시성 수가 낮은 서버를 선택하십시오. |
| 무작위 규칙 | 사용 가능한 서버를 무작위로 선택합니다. |
| 재시도 규칙 | 재시도 메커니즘의 선택 논리 |
기본 구현은 폴링 방식인 ZoneAvoidanceRule입니다.
1.3.2 맞춤형 로드밸런싱 전략
로드 밸런싱 규칙은 두 가지 방법으로 IRule 구현을 정의하여 수정할 수 있습니다.
- 코드 메서드: order-service의 OrderApplication 클래스에서 새 IRule을 정의합니다.
@Bean
public IRule randomRule(){
return new RandomRule();
}
- 구성 파일 방법: order-service의 application.yml 파일에서 새 구성을 추가하면 규칙도 수정할 수 있습니다.
userservice: # 给某个微服务配置负载均衡规则，这里是userservice服务
ribbon:
NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule # 负载均衡规则
기본 로드 밸런싱 규칙은 일반적으로 수정 없이 사용됩니다 .
1.4.배고픈 로딩
리본은 기본적으로 지연 로딩을 사용합니다. 즉, 처음 액세스할 때까지 LoadBalanceClient가 생성되지 않으며 요청 시간이 매우 길어집니다.
프로젝트 시작 시 Hungry Loading이 생성되어 최초 방문 시간이 단축되며, 다음 구성을 통해 Hungry Loading을 활성화합니다.
ribbon:
eager-load:
enabled: true
clients: userservice
Dark Horse Programmer가 편집한 연구 노트