게이트웨이 Zuul 과학

왜 게이트웨이를 사용

(예 : 휴대 전화 APP)을 외부 클라이언트는 비즈니스 요구 사항을 완료하기 위해 여러 서비스 인터페이스를 호출 할 필요가 수도 있지만 일반적으로 다른 마이크로 서비스는 다른 네트워크 주소를 가지고있다. 아래와 같이 예를 들어, 영화 티켓 폰 APP는 여러 인터페이스는 비즈니스 프로세스의 구매를 완료하기 위해 마이크로 서비스를 호출 할 수 있습니다.

클라이언트가 각각의 마이크로 서비스와 직접 통신 할 경우, 다음과 같은 질문을해야합니다 :

• 클라이언트는 계속 다른 마이크로 서비스를 요청한 클라이언트의 복잡성을 증가시킨다.

• 특정 장면에서 크로스 도메인 요청은 상대적으로 과정을 복잡하다.

• 복잡한 인증, 각 서비스는 독립적 인 인증이 필요합니다.

• 어려운 다시 나누어 마이크로 서비스해야 할 수도 있습니다 프로젝트의 반복으로 재구성합니다. 예를 들어, 복수의 서비스는 하나 이상의 서비스들로 분할하는 복수로 조합 될 수있다. 클라이언트가 직접 마이크로 서비스와 통신 할 경우, 재 구현하기 어려울 것이다.

• 일부 서비스는 어려움이있을 것 마이크로 프로토콜 방화벽 / 브라우저 쌀쌀, 직접 액세스를 사용할 수 있습니다.

상기 문제는 마이크로 서비스 게이트웨이에 의해 해결 될 수있다. 마이크로 서비스 게이트웨이는 클라이언트와 서버 사이에 중간층을 개재 모든 요청은 게이트웨이를 제공하는 외부 마이크로 통과한다. 아래와 같이 서비스 게이트웨이 후 마이크로 아키텍처를 사용.

이때, 마이크로 서비스 게이트웨이는 애플리케이션의 내부 구성을 캡슐화 클라이언트 만 필요 게이트웨이와 상호 작용하여, 직접 전화 인터페이스 특정 마이크로 서비스 않고도. 이러한 방법으로, 개발자들은 단순화 할 수있다. 또한, 마이크로 서비스 게이트웨이의 사용은 다음과 같은 장점이있다 :

• 쉽게 모니터링 할 수 있습니다. 데이터는 마이크로 - 모니터에 수집 및 분석을위한 외부 시스템에 서빙 게이트웨이를 푸시 할 수있다.

• 인증에 쉽게. 인증 각 마이크로 서비스 인증없이 전달 후 마이크로 백엔드 서비스에 대한 요청을 상기 마이크로 서비스 게이트웨이에서 수행 될 수있다.

• 그것은 클라이언트와 다양한 마이크로 서비스 간의 상호 작용의 수를 줄일 수 있습니다.

Zuul 소개

본질적으로 웹 서블릿 응용 프로그램입니다 Zuul는 오픈 소스 넷플 릭스 API 게이트웨이 (//github.com/Netflix/zuul : HTTPS 코드 호스팅 주소)입니다. Zuul 가족 양동이 봄 클라우드, 그것은 유레카, 리본, Hystrix 및 기타 구성 요소는 함께 사용할 수 있습니다.

핵심 Zuul,이 필터 우리는 다음과 같은 기능을 수행하는 데 도움이 필터의 연속이다 :

• 인증 및 보안 : 자원의 모든 종류의 식별 검증 요구 사항 및 요청과 요구 사항이 일치하지 않습니다 거부합니다.

• 검토 및 모니터링 : 트랙 의미있는 데이터와 통계를 에지 위치에, 우리를 위해 정확한 생산 상태 결론을 선도.

• 동적 라우팅 : 동적 라우팅 할 필요가 뒤쪽 끝에서 다른 클러스터로 요청.

• 스트레스 테스트 : 점차적으로 성능 수준을 계산하기 위해, 클러스터에 부하 트래픽을 증가시킨다.

• 하중 배분 : 하중 배분 유형별 용량 및 폐기에 대한 요청을 대응하는 한계 값을 초과한다.

• 답변 정적 공정 : 클러스터 내에 흐르는 않도록 가장자리 부분에 직접 응답을 설정.

• 멀티 지역 유연성 : ELB의 사용을 다양 화하고 보장하기위한 AWS 지역에 걸쳐 라우팅 요청 사용자에게 가능한 한 가깝게 에지 위치가.

또한, 넷플릭스는 카나리아 버전 Zuul 정확한 라우팅 기능 및 스트레스 테스트를 사용합니다.

참고 : Zuul 공식 문서에서 상기 설명하지만, 사실, Zuul의 오픈 소스 버전은 더 이상 함수보다 - 그것은, 위의 기능을 의미 몇 항아리 Zuul 오픈 소스 패키지는 Zuul 자신의 공식 넷플릭스의 능력이 있어야한다.

시작하기

이 개 서비스를 정의 각각 그들이 서비스 유레카에 등록되어 안녕하세요 - 서버와 사용자 서버, (여기 아래도 언급 Zuul 올라갈 등록) 아래의 예를 :

이 게이트웨이를 통해 아닌 경우, 우리는 별도의 다음 두 개의 인터페이스에 의한 안부 서버와 사용자 서버에 액세스 할 수있다 :

http://localhost:8081/hello
http://localhost:8082/user

이제 메이븐 다음에 따라 관련 Zuul 서비스를 정의 할 수 있습니다 :

<dependencies>
    <dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-starter-netflix-zuul</artifactId>
        <version>2.2.2.RELEASE</version>
    </dependency>
    <dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
        <version>2.2.2.RELEASE</version>
    </dependency>
</dependencies>

application.yml 파일은 다음과 같은 구성을 추가 :

spring:
  application:
    name: zuul-service

eureka:
  client:
    service-url:
      defaultZone: http://localhost:8761/eureka

server:
  port: 6069

시작 클래스 노트 @EnableZuulProxy를 추가

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.cloud.netflix.zuul.EnableZuulProxy;

@SpringBootApplication
@EnableZuulProxy
public class ZuulServiceApplication {
    public static void main(String[] args) {
        SpringApplication.run(ZuulServiceApplication.class, args);
    }
}

프로그램을 시작하면, 우리는 서비스 게이트웨이를 통해 상기 두 개의 인터페이스에 액세스 할 수있다 :

curl http://localhost:6069/hello-server/hello
curl http://localhost:6069/user-server/user

참고 : 유레카 유레카에 결합 된 기본 Zuul는 서비스 이름의 contextPath 액세스로 등록됩니다. Zuul에서 우리는 사용자 정의 관련 세부 사항을하지 않는다 여기 라우팅 규칙의 다양한 구성 할 수 있습니다.

요청 필터링

위의 예는, 우리가 Zuul에 의해 라우팅 기능 요청을 구현, 우리의 마이크로 서비스 응용 프로그램이 통합 된 API 게이트웨이 항목을 통해 제공 할 수 있도록 인터페이스는 클라이언트 액세스입니다.

각 클라이언트 응용 프로그램이 사용자 인터페이스 서비스 요청을 제공하고, 그들이 특정 제한에 액세스하는 경향이 시스템은 그들 모두는 마이크로 서비스 인터페이스에 열하지 않습니다. 그러나, 현재 서비스 라우팅 기능이 그러한 권리를 제한하지 않습니다, 모든 요청은 보안 검사를 달성하고 클라이언트, 가장 간단하고 잔인한가 요청한 권한을 제어하기 위해, 특정 응용 프로그램과 반환 결과에 예약없이 전달됩니다 각 방법은 서명을 확인하고 필터 또는 인터셉터를 식별 할 수있는 권한을위한 마이크로 서비스 응용 프로그램을 구현하는 것입니다. 이러한 질문은 중복을 달성하기에 너무 작동합니다. 좋은 방법은 별도의 인증 서비스를 구축하기 위해 검사 논리를 분사하는 것입니다. 직접 인증 시스템 서비스를 호출하여 구현 된 마이크로 체크 서비스 응용 프로그램에, 박리 완료하지만 인증 로직이 단순히 주소를 분리,이 원래의 자연하지 중복 로직에 포함되지 않은 후 일부 마이크로 서비스 응용 프로그램 중복 인터셉터 나 여전히 존재합니다 필터를 분할합니다.

이러한 문제를 들면, 더 접근 게이트웨이 서비스의 앞쪽이 비 작동 특성의 완료를 확인하는 것이다. 게이트웨이 서비스 가입으로 관계없이 특정 사업이 검사가 왜 확인 요청 및 여과를 완료하는 시간에 도착하지 때문에, 외부 클라이언트는, 우리의 시스템 통합 입구에 액세스 할 수있는, 마이크로 엔드 서비스 응용 프로그램 캔 복합 필터 및 마이크로 어플리케이션 인터페이스 서비스 개발 및 테스트의 복잡성을 만드는 인터셉터 제거하여 따라 감소되었다. 이것은 또 다른 주요 기능 zuul 요청 필터를 포함한다.

필터의 사용에 간단한 모양의 다음 예제 :

import com.netflix.zuul.ZuulFilter;
import com.netflix.zuul.context.RequestContext;
import com.netflix.zuul.exception.ZuulException;
import lombok.extern.log4j.Log4j2;

import javax.servlet.http.HttpServletRequest;

@Log4j2
public class AccessFilter extends ZuulFilter {

    //过滤器的类型，它决定过滤器在请求的哪个生命周期中执行，这里定义为pre，代表会在请求被理由之前执行。
    @Override
    public String filterType() {
        return "pre";
    }

    //过滤器的执行顺序。当请求在一个阶段中存在多个过滤器时，需要根据该方法返回的值来依次执行
    @Override
    public int filterOrder() {
        return 0;
    }

    //判断该过滤器是否需要被执行。这里我们直接返回了true，因此该过滤器对所有的请求都生效。实际运行中我们可以利用该函数
    //来指定过滤器的有效范围。
    @Override
    public boolean shouldFilter() {
        return true;
    }

    //过滤器的具体执行逻辑。
    @Override
    public Object run() throws ZuulException {
        RequestContext ctx = RequestContext.getCurrentContext();
        HttpServletRequest request = ctx.getRequest();

        log.info("send {} request to {}", request.getMethod(), request.getRequestURI().toString());

        Object accessToken = request.getParameter("accessToken");
        if (accessToken == null) {
            log.warn("access token is empty");
            ctx.setSendZuulResponse(false);
            ctx.setResponseStatusCode(401);
        } else {
            log.info("access token ok");
        }

        return null;
    }
}

코드 샘플 ZuulFilter 인터페이스는 네 가지 방법을 정의한다 :

• filterType : 요청이 이유는 전에 사전으로 정의 요청의 수명주기가, 대표이 실행됩니다되는 결정의 구현을 필터링 유형 (유형) 필터. (필터의 형태는 다음 페이지에서 상세히 설명 될 것이다)

• filterOrder : 실행 순서 필터 (실행 순서). 다단 필터의 요구가있는 경우에, 순차적 방법에 의해 리턴되는 값에 따라 실행되어야한다.

• shouldFilter : 필터는 (기준)을 행할 필요가 있는지 여부를 결정하는 단계를 포함한다. 모든 요청에 ​​필터를 적용하려면 그래서 여기에 우리가 직접 true를 돌려줍니다. 실제 작업은 우리는이 기능을 사용할 수 있습니다.

• 실행 로직 특정 필터 (작업)을 수행.

이 필터 시작 클래스를 추가 :

@Bean
public AccessFilter accessFilter(){
    return new AccessFilter();
}

이 경우, 다음 액세스 컬에 http : // localhost를 : 6069 / 안녕하세요 - 서버 / 안녕하세요 인터페이스를 불평 할 것이다, 상태 코드 (401)는, 올바른 자세 액세스는 다음과 같습니다

curl http://localhost:6069/hello-server/hello?accessToken=666

필터 수명주기

사전, 라우팅, 포스트 및 오류, 요청의 일반적인 라이프 사이클에 해당하는 필터의 이러한 유형 : Zuul 네 가지 표준 필터를 정의합니다. 우리는 필터의이 사가지 역할의 수명주기 및 실행 순서에 대해 이야기하기 위해 다음 표를 참조하십시오.

요청이 외부의 HTTP API 게이트웨이 서비스에 도달하면, 먼저이 프리 필터 타입으로 처리되는 제 1 스테이지 프리 들어간다. 이 유형의 필터의 주요 목적은 이러한 액세스 제한 등의 어떤 전처리를 수행하기 전에 수행 요청 라우팅된다.

프리 필터 타입 프로세스의 종료 후, 요청, 즉 라우팅 요청 전달 단계를 라우팅의 두 번째 단계를 입력 요청은 필터의 종류의 라우팅을 처리한다. 여기서 처리되는 특정 외부 요청이 서비스 요구의 결과를 라우팅하는 단계는, 세 번째 단계 포스트를 입력하기위한 요청을 완료하고, 인스턴스를 반환 프로세스 가입 특정 서비스 인스턴스에 전달된다.

이 시점에서 요청이 필터 포스트 유형을 처리 할 것입니다,이 필터는 게시물에, 필터의 종류 만 처리시 요청 정보를 얻을 수뿐만 아니라 서비스 인스턴스를 반환 정보를 얻기 위해, 우리는 다룰 수 이러한 반응에서와 같은 결과와 다른 처리 또는 콘텐츠의 변환은 표준 HTTP 헤더 수집 통계 및 지표를 추가한다.

또한, 특별한 상 오류가,이 세 단계 만 예외가 발생 위상이 트리거됩니다. 필터 흐름도에서 오류의 이해를 깊게하기 위해 우리는 다음과 같은 필터를 실행합니다.

일반적으로, 일반 과정은 사전됩니다 -> 경로 -> 게시 할 수 있습니다. 예외가 프리 필터 단계에서 발생 된 경우, 처리는 : -> 에러 - 프리> 후, 예외 라우트 필터링 단계에서 발생하는 경우, 프로세스는 : ​​사전 -> 경로 -> 오류 -> 포스트, 포스트 (post)의 필터 단계 던져, 최종 프로세스는 다음과 같습니다 사전 -> 경로 -> 포스트 -> 오류입니다.

기본 필터 유형뿐만 아니라, Zuul는 또한 우리는 사용자 정의 필터 유형을 만들 수 있습니다. 예를 들어, 우리는 후방 전달하지 않고, 상기 마이크로 서비스 요청을 직접 반응 Zuul 생성 필터의 정적 타입을 정의 할 수있다.

필터 API 게이트웨이 기능은 HTTP 요청의 각각은 요청 응답을 프로세싱 체인을 제공하고 클라이언트에 반환하도록하는 일련의 필터를 통해 Zuul 입력되며 Zuul를 코어 부재로 구현된다. 실제 작업에서 라우팅 기능을, 예를 Zuul 라우팅 기능을 위해 가지고, 그 매핑 및 라우팅 요청을 완료하는 데 몇 가지 필터에 의해 전달됩니다. 필터의 주요 유형을 통해 노선도가 완료 사전하며,이 전달되는 목적지 주소를 찾기 위해, 규칙이 일치하는 라우팅 경로 구성을 요청하고, 요청 부분에 대한 필터의 경로 유형에 의해 이루어집니다에서 전달 프리 필터 타입 라우팅 주소가 전달 얻어.

Zuul 아키텍처

Zuul 코어의 작동 원리는이 그림에 따라 다음 그림 쇼, 우리는 더 나은 Zuul을 이해할 수있다.

언어의 본질적 구성 Zuul 필터 그루비, 처음에 이러한 필터 파일 (끝에는 .groovy)은 아래의 특정 목록의 형태로 저장된다. Zuul FilterFileManager는 정기적으로이 디렉토리에서 회전, 새로 추가 또는 수정 필터를 동적으로로드됩니다. 파일이 GroovyComplier JVM 클래스를 컴파일하기 위해 사용되는 용 FilterFileManager에는 .groovy를 판독 한 후, 그 최종 FilterRegistry ZuulFilter에 저장된 객체 (즉, 필터)으로합니다 (에 Class.newInstance)를 인스턴스화 재. FilterRegistry 우리가 말할 수 있도록, FilterLoader 포함 객체 그래프입니다 : ZuulFilter 마지막에 FilterLoader에 저장된 객체.

FilterRegistry 오브젝트 후 경로에는 .groovy 파일 키 값 ZuulFilter의 동적 로딩되는 것을 특징 ConcurrentHashMap의로 알 수있다.

데이터 전송을위한 필터 Zuul 바이 그들 사이 RequestContext 각 사이의 직접 통신 (ConcurrentHashMap의 하나로서 볼 수있다)이 없다. 요청에 의해 송신 된 데이터 레코드의 각 클래스의 ThreadLocal RequestContext 변수가 필요했다.

요청이 Zuul 오면 말했다 이전 초기화 RequestContext에서 ZuulRunner ZuulServlet 객체가, ZuulServlet 첫 번째 프로세스를 언급했다. ZuulRunner FilterProcessor도가 상기 FilterProcessor는 FilterLoader (FilterRegistry)로부터 ZuulFilter (S)을 얻었다. 실행될 이러한 필터의 구현에 오류가있는 경우 이들 ZuulFilter은 이후 함께 ZuulServlet 먼저 실행 필터의 종류를 미리하고 필터의 경로 형태를 수행 후 최종 구현 필터의 종류이고, 필터의 오류 유형. 이러한 필터, 클라이언트에 요청 뒷면의 최종 결과의 이행 후.

Zuul 2.X

월 21 일, 넷플릭스는 공식 블로그 공식 오픈 소스 마이크로 서비스 발표 게이트웨이 구성 요소 Zuul 2 (Zuul은 Zuul가 Zuul 1로 표현하기 전에 명시됩니다 다음의 구분을 용이하게하기 위해 6 월 12 일, 2013 년 오픈 소스에 넷플 릭스입니다 ). Zuul 2 Zuul 1 아키텍처의 주요 차이는 거짓, Zuul 2 비 블로킹 비동기 프레임 등의 Netty 실행. Zuul 1 종속 사용 지원 증가, 처리량 및 인 Netty 프레임 워크 Zuul 2 멀티 스레드하는 이벤트와 콜백을 껐다 따라 달라집니다.

필터 Zuul2 요청의 실행의 Netty 클라이언트로 전달 인바운드 필터 결과를 완료 한 후에 도시 된 바와 같이 인 Netty는, 그 요청은 아웃 바운드 필터의 시리즈를 통해 반환되는 일련의에서 실행되는 서비스입니다. ZuulFilter 사전, 사후, 라우팅, 오류로 나누어 이전과 같이, Zuul 2는 세 가지 유형의 필터으로 나누어 져 있습니다 :

• 인바운드 필터 : 라우팅하기 전에 실행

• 엔드 포인트 필터 : 라우팅 작업

• 해당 데이터 수행 후 아웃 바운드 필터

Zuul 2 구조는 실질적으로 상기와 같이 도시 한 Zuul 1 본질적인 차이. 아웃 바운드, 인바운드, 엔드 포인트 : ZuulFilter 사전으로 나누어 전에, 게시물, 라우팅, 오류, Zuul 필터 (2)는 세 가지 유형으로 구분된다. Zuul 2 대신 일본어 Zuul 1 서블릿의 Netty 서버 대신의 Netty 클라이언트 HttpClient를 사용의 필터의 후단에 의한 필터의 전단, 즉 전방 및 후방 단부를지지 할 수 있도록 비동기 (3.0 사양 최적화 지원 AsyncServlet에 사용될 수 Zuul1 서블릿 ) 선단보다지지 비동기 접속을 달성 할 수 있고, Zuul2 동일한 효과를 달성한다. Zuul 1에 비해, Zuul 2도 풍부하며 HTTP / 2, 웹 소켓의 지원으로, 기능면에서 많이 최적화 할 수 있습니다.

Zuul 대 Zuul 1 2

Zuul1 디자인은 아래와 같이는, 본질적으로 동기화 서블릿, 멀티 스레드가 차단 모델, 쉬운 코드가 상대적으로 작은 읽기, 상대적으로 간단하다.

연결 요청 당 쓰레드를 사용하여 서블릿 동기 방법. 이 글의 클라이언트에 반환 응답이 컨테이너 스레드 풀을 반환 해제 될 때까지 간단히 말해서, 각각의 새로운 인바운드 요청에 대해, 서블릿 컨테이너는 스레드를 할당해야합니다. 배경은 다음 스레드가 스레드 리소스를 점유 차단시 차단됩니다 시간이 소요되는 서비스 요청 인 경우, 당신은 다른 작업을 수행 할 수 없습니다. 스레드 풀 크기가 제한됩니다 서블릿 컨테이너는, 현재의 클라이언트가 새 요청을 받아 들일 수있는 용기를 유발, 컨테이너 스레드 풀 스레드가 부족하기 쉽습니다, 배경과 느린 서비스 비교적 긴 시간에 많은 양의 요청, 넷플릭스이 또한 Hystrix 개발 퓨즈 구성 요소는 자원 고갈 속도가 느린 서비스의 문제를 해결합니다.

> 처리 - -이 동기 차단 패턴은 비교적 간단한 프로그래밍 모델은 전체 요청이다> 흐름 (호 흐름)는 스레드에 응답하여 처리 될뿐만 아니라 개발 및 편리 디버그 디버깅의 이해를 용이하게한다. 그러나, 동기 블록 모드 일반적으로 스레드가 많이 시작할 스레드 스위치 오버 헤드 필연적으로 도입했다. 또한, 동기 블록 모드, 컨테이너 스레드 풀의 수는 일반적으로 느린 백 오피스 서비스, 컨테이너 스레드 풀은 고갈 된 컨테이너가 새 요청을 거부하면, 쉽게 고갈 연결 수에 특정 제한의 결과로, 고정,이 시간 컨테이너 스레드는 정말 바쁜하지 않지만, IO가 차단 백 오피스 서비스라고하지만, 다른 일을하지 할 수 있습니다.

전반적으로, 동기 블록 모드들은 계산 집약적 (CPU 바인딩) 시나리오에 적합하다. IO 집중적 인 장면 (IO 바인딩)의 경우, 동기 블록 모드 스레드, 그들은이 차단 된 상태 IO를 기다리고있다 헛된 자원을 많이 소모되며, 실질적인 일을하지 않았다.

Zuul2 디자인에 도시 된 바와 같이이 비 블록킹의 Netty 비동기 프로그래밍 모델을 사용하여, 그 코드를 판독하는 것은 용이하지 않다 비교적 복잡하다.

당신이에 의해, Zuul이 소스 코드를 읽을 필요가있는 경우 "[Zuul2 소스 코드 분석] (http://springcloud.cn/view/344)"도움에 대한 기사가 더 효과적 일 수 있습니다.

위의 그림에서, 당신은 단순히 사용자 요청에 전념 큐가 전면으로 이해 수, 동시에 전후 모니터 배경 서비스 호출, 이벤트 루프 스레드 (이벤트 루프 스레드)의 중간을 처리에 대한 책임을 백 엔드 큐가 큐의 이벤트는, 이벤트가 이벤트를 처리하는 콜백 함수를 트리거합니다. 이 모드 적은 스레드 만 실질적 핵 이벤트 루프 각각의 스레드를 처리하는 CPU를 필요에 선단부가 많은 연결 큐에 유일한 연결 일 수 있으며, 스레드는 이벤트 루프 스레드에 의해 이벤트를 시작할 필요가 없다 트리거, 아니 멀티 스레딩 블로킹 문제.

비동기 비 차단 모드 스레드가 작은 시작 스위치 오버 적은 자원 사용 스레드 컨텍스트는 작다. 연결이 비 차단 크게 증가 단순히 전용 큐를 입력하기위한 요청으로 이해 될 수있는 모드, 큐 용량이 더 초과만큼 매우 큰 허용 가능한 설정 될 수 있고, 요구 큐가 순차적으로 처리된다. 비동기 모드는 프로그래밍 모델이 복잡 할 수 있습니다. 상기 요청에 대한 명확한 정의가없는 비동기 모델 -> 처리 -> 응답하여 실행 흐름의 흐름이 이벤트에 의해 트리거되고, 상기 요구 처리 플로우는 전체 실행 흐름 ID를 연관 일부 내부 메커니즘을 통해 달성 될 언제든지 스위치 오프 될 수있다 다음 함께, 개발자 디버그 운영 및 유지 보수를 소개에게 IDE 내부 비동기 요청의 흐름을 디버깅하는 것은 매우 어렵다 같은 복잡성의 수를 제공한다.

전체적으로 비 차단 모드는 비동기 CPU 라이터 컴퓨팅 작은 이벤트 루프 스레드를 처리 할 수있는, 대부분의 프로세싱 시스템 IO의 시간이 시나리오 IO 집약적 (IO 바인딩) 시나리오에 더 적합하다.

성능 Zuul2 Zuul1 배향에 관해서는 거의 넷플릭스 더 여기서 20 % Zuul1 성능보다 애매한 데이터 Zuul2 성능을 제공 주로 노드 초당 처리 된 요청의 개수를 나타낸다. 왜 모호? 이 데이터가 많은 영향을 실제 시험 환경, 교통 장면 모드 및 기타 요인에 따라이기 때문에, 테스트 데이터를 재생하기 어렵다. 심지어 20 %의 성능 향상이 참 사실, 이러한 성능 향상은 크지이며, 20 % 증가에 비해 비동기의 도입의 복잡성 가치가 문제입니다. 넷플릭스 자체는 그 자체가 약간의 의심의 여지가 있더라도에서, 자사의 블로그 [참고 5]와 PPT [참고 8]에 약간 모호합니다.

질문은 그래서, 당신은 또한, Zuul1 또는 Zuul2, 또는 봄 클라우드 게이트웨이를 사용하도록 선택하거나 홍콩의 경우?

Referencs

1. https://netflixtechblog.com/announcing-zuul-edge-service-in-the-cloud-ab3af5be08ee

2. https://www.jianshu.com/p/9c104186572d

3. http://www.itmuch.com/spring-cloud/finchley-16/

4. http://www.itmuch.com/spring-cloud/zuul/zuul-ha/

5. https://netflixtechblog.com/zuul-2-the-netflix-journey-to-asynchronous-non-blocking-systems-45947377fb5c

6. https://mp.weixin.qq.com/s/QkeIVTn97VmOc0Y18PAvYQ

7. https://blog.csdn.net/yang75108/article/details/86991401

8. https://github.com/strangeloop/StrangeLoop2017/blob/master/slides/ArthurGonigberg-ZuulsJourneyToNonBlocking.pdf