SpringCloud Zuul 부하 균형 과 퓨즈 메커니즘 실현

장면
필 자 는 Zuul 게 이 트 웨 이 에서 부하 균형 과 퓨즈 체제(눈사태)를 실현 하 는 것 을 실천 하 는데 전 제 는 zuul 관련 의존 도 를 도입 한 것 이다.
springboot 버 전:1.5.9.RELEASE
springcloud 버 전:Dalston.SR5

<dependencies>
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-zuul</artifactId>
        </dependency>
        <dependency>
            <groupId>com.netflix.zuul</groupId>
            <artifactId>zuul-core</artifactId>
            <version>1.3.0</version>
        </dependency>
</dependencies>

2.장면 실현
1.게 이 트 웨 이 설정 파일 에 ribbon(부하 균형)과 hystrix(퓨즈 메커니즘)를 설정 합 니 다.

#    
hystrix:
  command:
    default:
      execution:
        isolation:
          thread:
            timeoutInMilliseconds: 6000
 
#    
ribbon:
  ConnectionTimeout: 500
  ReadTimeout: 2000
#  
server:
  port: 8080
spring:
  #         ，        wc-gateway
  application:
    name: wc-gateway
  profiles:
    active: dev
#      
zuul:
  host:
    connect-timeout-millis: 60000
    socket-timeout-millis: 60000
  #    
  routes:
    api:
      path: /api/user/**
      serviceId: wc-client-user

사실 ribbon 의 실제 값=(ConnectionTimeout+ReadTimeout)*2,이 값 은 hystrix 의 timeout InMilliseconds 값 보다 작 으 면 부하 균형(ribbon)의 재 시도 기 회 를 잃 고 직접 녹 기 때 문 입 니 다.
2.부하 균형 검증
zuul 아래 에 Hstrix,ribbon 관련 jar 가방 을 가지 고 있 기 때문에 모든 것 은 현재 부하 균형 과 용 단 체 제 를 실현 하 였 으 며,이어서 검증 하 였 습 니 다.
client 서비스 에서 controller 를 작성 하여 부하 균형 을 테스트 합 니 다.

package top.wingcloud.controller; 
import org.springframework.beans.factory.annotation.Value;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;
 
/**
 * @author: linjie
 * @description:            
 * @create: 2018/11/06 09:16
 */
@RestController
public class UserController {
    @Value("${server.port}")
    private int port; 
    @RequestMapping("index")
    public String index(){
        return "Hello World!"+port;
    }
}

등록 센터,설정 센터,client 서 비 스 를 순서대로 시작 하고 포트 를 수정 하여 client 서비스,서비스 게 이 트 웨 이 를 다시 시작 합 니 다.
게 이 트 웨 이 경로 에 따라 같은 경로 에 접근 하면 시 작 된 두 개의 서로 다른 포트 의 client 서비스 가 교체 되 어 실 행 된 것 을 발견 합 니 다.


이 상황 이 발생 하면 부하 균형 이 이 루어 진다.
3.퓨즈 메커니즘 검증
게 이 트 웨 이 서비스 에 Zuul Fallback Provider 의 실현 클래스 를 써 야 합 니 다.

package top.wingcloud.filter; 
import org.springframework.cloud.netflix.zuul.filters.route.ZuulFallbackProvider;
import org.springframework.http.HttpHeaders;
import org.springframework.http.HttpStatus;
import org.springframework.http.MediaType;
import org.springframework.http.client.ClientHttpResponse;
import org.springframework.stereotype.Component; 
import java.io.ByteArrayInputStream;
import java.io.IOException;
import java.io.InputStream;
 
/**
 * @author: linjie
 * @description:      ，  
 * @create: 2018/10/11 20:01
 */
@Component
public class ApiFallbackProvider implements ZuulFallbackProvider{
 
    @Override
    public String getRoute() {
        //        
        //           *
        return "wc-client-user";
    }
 
    @Override
    public ClientHttpResponse fallbackResponse() {
        return new ClientHttpResponse() {
            @Override
            public HttpStatus getStatusCode() throws IOException {
                return HttpStatus.OK;
            }
 
            @Override
            public int getRawStatusCode() throws IOException {
                return 200;
            }
 
            @Override
            public String getStatusText() throws IOException {
                return "{code:0,message:service error =_=}";
            }
 
            @Override
            public void close() {
 
            }
 
            @Override
            public InputStream getBody() throws IOException {
                return new ByteArrayInputStream(getStatusText().getBytes());
            }
 
            @Override
            public HttpHeaders getHeaders() {
                HttpHeaders headers = new HttpHeaders();
                headers.setContentType(MediaType.APPLICATION_JSON);
                return headers;
            }
        };
    }
}

이 때 client 의 모든 서 비 스 를 닫 고 이전 게 이 트 웨 이 경로 에 다시 접근 합 니 다.
getStatusText()의 알림 이 나 타 났 습 니 다.즉,퓨즈 메커니즘 을 실현 하 였 습 니 다.
자,zuul 의 부하 균형 과 퓨즈 가 실현 되 었 습 니 다!
zuul 게 이 트 웨 이 설정+흐름 제한 퓨즈
호출 된 측:지연 시간 600 ms

ahas：

사용자 제한:

trade 퓨즈:(3 초 간 요청 수>4)&&(3s 내 느 린 호출/요청 수>50%)->퓨즈 오픈
느 린 호출 표준:응답 시간 500 ms 이상

20 개 요청 테스트:

테스트 흐름 제한:

테스트 흐름 제한 및 rt 퓨즈

이상 은 개인 적 인 경험 이 므 로 여러분 에 게 참고 가 되 기 를 바 랍 니 다.여러분 들 도 저 희 를 많이 응원 해 주시 기 바 랍 니 다.