게이트웨이가 필요한 이유는 무엇입니까?
우리는 우리가 서비스 자체에 입력하고 싶다는 것을 알고 있으며, 우리는 특별히 좋은 방법이 없다는 것이 분명합니다. IP 주소 + 포트 번호를 직접 입력합니다. 우리는이 접근법이 매우 나쁘다는 것을 알고 있습니다. 이 접근법에는 큰 문제가 있습니다. 먼저 실제 시스템의 IP 주소를 노출시킵니다. 다른 사람들이 귀하의 IP 주소를 보면 서비스가 어디에 배치되는지 알고있어 다른 사람들이 공격 작업을 매우 편리하게 수행 할 수 있습니다.
둘째, 우리는 너무 많은 서비스를 가지고 있습니다. 하나씩 전화해야합니까? 권한 인증을 수행했다고 가정하고 각 고객은 다른 기계에서 실행되는 다른 JVM에 대한 서비스 프로그램에 액세스합니다. 각 서비스에는 서비스 인증이 필요합니다. 이것이 성가신가요? 분명히 매우 성가신 일입니다.
그런 다음 현재이 두 가지와 일반적인 문제에 직면하고 있으며,이를 해결할 수있는 방법이 필요합니다. 우선, IP 주소의 노출과 사망 후 IP 주소 작성으로 인한 단일 포인트 문제를 살펴 보겠습니다. 또한 그러한 서비스 자체에 대한 서비스 목록을 동적으로 유지해야합니까? 이 서비스 자체를 호출해야합니다. 또한로드 밸런싱이 필요합니까?
IP 주소 노출에 대한 것도 있습니다. Nginx의 리버스 프록시와 같은 프록시 여야하고 모든 포털에 대한 권한 검증과 같은이 제품에 대한 공개 모듈을 배치하는 것들도 있습니다. 이제 Zuul API 게이트웨이가 필요합니다. 위의 문제를 해결합니다. 특정 서비스를 호출하려면 귀하를 매핑하고 서비스의 IP 주소를 매핑합니다.
당신이 경로에 들어가면 그것은 일치하고 서비스에 액세스 할 것입니다. 요청 전달 프로세스가 있습니다. 서비스 머신 인스턴스의 특정 강도 인 Nginx와 마찬가지로 IP에 직접 액세스하지 못하며 Eureka 등록 센터로 이동하여 서비스 인스턴스 ID, 즉 서비스 이름을 얻습니다. 클라이언트의로드 밸런싱 리본을 사용하여 서비스 인스턴스 중 하나에 다시 액세스했습니다.
API 게이트웨이는 주로 서비스 자체의 외부 통화 문제를 해결하고 권한 검증 문제를 해결하는 데 사용됩니다. Shiro, Springsecurity 및 기타 것들과 같은 일련의 필터를 통합하고 호출 할 수 있습니다.
Zuul은 동적 필터링 메커니즘을로드하여 다음 기능을 달성 할 수 있습니다.
1. 확인 및 보안 : 다양한 리소스에 대한 검증 요구 사항을 식별하고 요구 사항과 일치하지 않는 요청을 거부합니다.
2. 검토 및 모니터링 : Edge 위치에서 의미있는 데이터 및 통계 결과를 추적하여 생산 상태에 대한 정확한 결론을 제공합니다.
3. 동적 라우팅 : 필요에 따라 다른 백엔드 클러스터에 대한 경로 요청.
4. 응력 테스트 : 성능 수준을 계산하기 위해 클러스터로의 하중 흐름을 점차적으로 증가시킵니다.
5. 부하 할당 : 해당 용량을 각 부하 유형에 할당하고 한계 값을 초과하는 요청을 사용하지 않습니다.
6. 정적 응답 처리 : 내부 클러스터로 유입되는 것을 방지하기 위해 에지 위치에서 직접 부분 응답을 만듭니다.
7. 다중 지역 탄력성 : AWS 지역의 요청 라우팅은 다양한 ELB 사용을 달성하고 가장자리 위치가 가능한 한 사용자와 가까워 지도록 설계되었습니다.
다음으로 작은 데모로 이동하십시오
첫 번째 단계는 원래 프로젝트에 따라 새로운 Zuul 모듈을 구축하고 종속성을 소개하는 것입니다. 코드는 다음과 같습니다.
<pectionency> <groupid> org.springframework.cloud </groupid> <artifactid> Spring-Cloud-Starter-Eureka </artifactid> <3.5. <3.5. release </version> </dependency> <groupid> org.springframework.cloud </groupid> <artifactid> Spring-cloud-starter-starter-state-state- spright-state-state-stated> <버전> 1.3.5. release </version> </fectionency>
그런 다음 시작 클래스에 @enablezuulproxy 주석을 입력하면 코드는 다음과 같습니다.
서버 : 포트 : 5000Spring : 응용 프로그램 : 이름 : API-GetewayZuul : Routes :#여기에서 직접 정의 할 수있는 서비스 이름을 확인하십시오. 일반적으로 편의성과 사양은 서비스 이름 Hello-Service :#서비스 매핑 경로,이 경로를 통해 외부에서 서비스에 액세스 할 수 있습니다. 목적은 기계의 IP와 서비스 지향 경로를 노출하지 않고 사용 가능한 경로를 선택하는 것입니다. #Here, Zuul은 자동으로 Hystrix 및 Ribbon에 의존하며 독립형 경로가 아니라 : /Hello-Service /**# Eureka 등록 센터의 서비스 이름이어야합니다. 따라서 ServiceID는 Eureka와 결합되므로 여기에서 구성됩니다. Zuul 만 사용하는 경우 자신의 컴퓨터의 IP를 작성해야합니다. #Such AS URL : http : // localhost : 8080/이것은 IP Dead를 작성하기에 충분하지 않습니다. 이 IP가 실패하고 고 가용성 인 경우 서비스 등록 세트는 사용되지 않습니다. Serviceid : hello-serviceeureka : #client : #Registration Center 주소 서비스 -URL : http : // localhost : 8888/eureka/, http : // localhost : 8889/eureka/
그런 다음 이전 기사에서 레지스트리 센터와 2 명의 Hello-Service 서비스 제공 업체를 시작하십시오. 그런 다음 우리는 그것을 실행하고 요청 전달 기능을 살펴보고 그것이 두 서비스에 투표하는지 확인합니다.
LocalHost를 입력하십시오 : 5000/hello-service/hello, 다음과 같이 :
그런 다음 다시 새로 고침 :
Zuul이 배포를 요청했음을 알 수 있습니다. 서비스 이름 Hello-Servie를 기반으로 특정 시스템에 매핑됩니다. 이것이 리버스 프록시의 기능이 아닙니까?
Zuul은 요청 필터링을 수행 할 수 있으므로 시연 할 토큰 검증을 수행하겠습니다. 먼저 Zuulfilter 클래스를 상속하고 4 개의 인터페이스를 구현하기 위해 새로운 토큰 필터 클래스를 만들어야합니다. 코드는 다음과 같습니다.
패키지 hjc.zuul; import com.netflix.zuul.zuulfilter; import com.netflix.zuul.context.requestcontext; import javax.servlet.http.htttp.httpervletrequest;/*** 2018/5/18에 생성 한* ***. */public class tokenfilter 확장 Zuulfilter {// 4 가지 유형 : 사전, 라우팅, 오류, post // pre : 주로 라우팅 매핑 단계에서 사용됩니다. 라우팅 매핑 테이블 // 라우팅 : 특정 라우팅 전달 필터는 라우팅 라우터에 있습니다. 특정 요청을 전달하면 // 오류 : 이전 필터 오류가 발생하면 오류 필터가 호출됩니다. // POST : 라우팅 후이 필터가 호출되지 않으며 오류가 완료되지 않습니다. @override public string filtertype () {return "pre"; } // 필터 실행 순서를 사용자 정의합니다. 값이 클수록 나중에 실행됩니다. 값이 작을수록 더 많이 실행될수록 먼저 실행됩니다. @override public int filterorder () {return 0; } // 적용 할 필터를 제어합니다. @override public boolean roopilter () {return true; } // 필터로 logic @override public 객체 run () {requestContext context = requestContext.GetCurrentContext (); httpservletrequest request = context.getRequest (); 문자열 토큰 = request.getParameter ( "토큰"); if (token == null) {context.SetSendZuulResponse (false); context.setResponsestatScode (401); Context.SetResponseBody ( "Unuthrized"); 널 리턴; } return null; }}FilterType : 필터 유형을 나타내는 문자열을 반환합니다. 수명주기가 다른 4 개의 필터 유형은 다음과 같이 Zuul에서 정의됩니다.
1. pre : 요청이 라우팅되기 전에 호출 할 수 있습니다. 라우팅 매핑 단계에서 라우팅 매핑 테이블을 찾는 데 사용됩니다.
2.route : 라우팅 요청 중에 호출됩니다. 라우터의 특정 요청 전달을 라우팅 할 때 특정 라우팅 전달 필터가 호출됩니다.
3. error : 요청을 처리하는 동안 오류가 발생할 때 호출
4. post : 라우팅 후에 필터가 호출되지 않으며 마지막 단계에있는 오류가 완료되었습니다.
여기서는 Zuul 필터가 네트워크 요청을 실행할 때 발생하는 예외를 선언합니다. Try-Catch에 의해 잡힌 예외는 필터의 페이지에 직접 던져 질 수 없습니다. 캐치에서 Context.set () 메소드를 사용하여 응용 프로그램에서 던진 예외는 페이지로 반환 할 수 있습니다. 다음과 같이 :
{business logic ...} catch (예외 e) {requestContext context = requestContext.GetCurrentContext (); context.set ( "error.status_code", 401); context.set ( "error.exception", e); context.set ( "error.message", "sfdfsdf");}다음 으로이 필터를 스프링에 추가하고 스프링을 관리해야합니다. 코드는 다음과 같습니다.
패키지 hjc; import hjc.zuul.tokenfilter; import org.springframework.boot.springApplication; import org.springframewor.boot.autoconfigure.springbootapplication; import org.spramework.cloud.netflix.zuule.enablezuulproxy; import org.springframework.context.annotation.bean;@springbootapplication@enablezuulproxypublic class zuulapplication {public static void main (String [] args) {springApplication.run (zuulapplication.class, args); } // 필터를 Spring Management @Bean Public TokenFilter TokenFilter () {return new TokenFilter (); }}다음으로, 시작 클래스를 시작하고 토큰없이 첫 번째 액세스를 시작하겠습니다.
허가없이 메시지가 반환되는 것을 볼 수 있습니다. 여기서 나는 토큰이 일반적으로 요청 헤더에 배치된다고 말하고 싶습니다. 여기서 우리는 시연 목적으로 그렇게하지 않습니다.
그런 다음 토큰을 가져 와서 다음과 같이 방문하십시오.
우리의 요청이 전송되었음을 알 수 있습니다.
여기에서는 기본 경로가 무엇인지에 대해 이야기하고 다음과 같이 Zuul 구성을 삭제하겠습니다.
서버 : 5000Spring : 응용 프로그램 : 이름 : API-GeteWayeureka : #Client Client : #Register Center 주소 서비스 -URL : DefaultZone : http : // localhost : 8888/eureka/, http : // localhost : 8889/eureka/
그런 다음 다음과 같이 다시 시작하고 액세스를 계속하십시오.
,,,
우리는 여전히 계속 액세스 할 수 있음을 알 수 있습니다. 우리는 할 일이 없지만 여전히 액세스 할 수 있습니다. 기본적으로 서비스 이름 Hello-Service로 자동으로 선언되기 때문입니다.
따라서 자동으로 선언하고 싶지 않으면 직접 정의하고 싶다면 YML 구성 파일의 zuu.ignored-services를 사용하여 다음과 같이 필터링처럼 필터링 할 수 있습니다. "
Zuul : #if 무시 서비스 :* 모든 기본 경로가 만료되었음을 의미합니다. 당신은 그들과 하나씩 일치시켜야합니다. 당신이 이상한 사업을 무시하지 않는 한 아무도 그렇게 망할 것입니다.
예를 들어 매핑 규칙에 대해 이야기합시다
Zuul : 경로 :#서비스 이름을 확인하면 여기에서 직접 정의 할 수 있습니다. 일반적으로 편의와 사양은 서비스 이름과 동일합니다. Hello-Service : #Service 매핑 경로이 경로를 통해 외부에서 서비스에 액세스 할 수 있습니다. 목적은 기계의 IP 노출을 피하는 것이며 서비스 지향 경로는 귀하를위한 것입니다. #Here Zuul은 독립형 경로가 아닌 Hystrix 및 Ribbon에 자동으로 의존합니다. /Hello-Service /**#Eureka 등록 센터 서비스의 이름이어야하므로 ServiceID는 Eureka와 결합되어 있기 때문에 여기에 구성됩니다. Zuul 만 사용하는 경우 #SUCH : http : // localhost : 8080/This Is Bone으로 기계의 IP를 작성해야합니다. IP Dead를 작성하는 것을 의미합니다. 이 IP가 실패하고 고 가용성이 실패하면 서비스 등록 세트가 사용되지 않습니다 : Hello-Servicezuul : Routes : hello-service :/hello-service/ext/** service : hello-service
여기에 두 개의 Zuul 구성 매핑 경로는 /hello-service /입니다. /hello-service/** 포함/hello-service/ext/**를 볼 수 있습니다. 이 두 경로와 일치 할 때 충돌이 있습니까? 그것을 다루는 방법? 누가 먼저 일치할까요?
다음은 YML에 정의 된 순서가 일치합니다. Application.Properties 형식의 구성 파일 인 경우이 순서를 보장 할 수 없습니다. YML 형식의 구성 파일은 순서대로 보장 될 수 있습니다. 여기에 참고하십시오.
일치하는 규칙을 정의하려면 어떻게해야합니까? 그런 다음 스타트 업 클래스에서 Bean을 정의해야하며 다음과 같이 경로를 결정합니다.
나는 여기서 그것을 보여주지 않을 것입니다. 필요하면 가서 천천히 정보를 검색하십시오.
또한 무시 된 패턴도 있습니다. 다음과 같이 :
Zuul : 경로 :#서비스 이름을 확인하면 여기에서 직접 정의 할 수 있습니다. 일반적으로 편의와 사양은 서비스 이름과 동일합니다. Hello-Service : #Service 매핑 경로이 경로를 통해 외부에서 서비스에 액세스 할 수 있습니다. 목적은 기계의 IP 노출을 피하는 것이며 서비스 지향 경로는 귀하를위한 것입니다. #Here Zuul은 독립형 경로가 아닌 Hystrix 및 Ribbon에 자동으로 의존합니다. /Hello-Service /**#Eureka 등록 센터 서비스의 이름이어야하므로 ServiceID는 Eureka와 결합되어 있기 때문에 여기에 구성됩니다. Zuul 만 사용하는 경우 #SUCH : http : // localhost : 8080/이것은 나쁜 IP를 작성해야한다는 것을 의미합니다. 이 IP가 실패하고 고 가용성이 있으면 서비스 등록 세트가 사용되지 않습니다.
패턴 무시 : /hello /**의 경로가 차단되었음을 나타냅니다. 귀하/Hello-Service/Hello/**가 불가능하더라도 여전히 차단합니다. 이 구성을 더 세분화 할 수 있습니다. 예를 들어, /hello 인터페이스를 라우팅하지 않으려면 위와 같이 구성 할 수 있습니다.
서비스의 접두사를 구성하려면 어떻게해야합니까? 코드는 다음과 같습니다.
Zuul : 경로 :#서비스 이름을 확인하면 여기에서 직접 정의 할 수 있습니다. 일반적으로 편의와 사양은 서비스 이름과 동일합니다. Hello-Service : #Service 매핑 경로이 경로를 통해 외부에서 서비스에 액세스 할 수 있습니다. 목적은 기계의 IP 노출을 피하는 것이며 서비스 지향 경로는 귀하를위한 것입니다. #Here Zuul은 독립형 경로가 아닌 Hystrix 및 Ribbon에 자동으로 의존합니다. /Hello-Service /**#Eureka 등록 센터 서비스의 이름이어야하므로 ServiceID는 Eureka와 결합되어 있기 때문에 여기에 구성됩니다. Zuul 만 사용하는 경우 #SUCH : http : // localhost : 8080/Dead IP를 작성하기에는 충분하지 않습니다. 이 IP가 실패하고 고 가용성이 있으면 서비스 등록 세트가 사용되지 않습니다.
방문한 서비스는/api/hello-service/**와 같은/api/로 접두사를해야한다는 것을 알 수 있습니다.
경로 액세스를 원한다면 내 지역으로 점프하고 싶다면 어떻게해야합니까?
액세스 /로컬에 액세스 할 때 사용자가 자동 으로이 방법으로 이동할 수 있기를 바랍니다. 따라서 현재 Zuul의 로컬 점프를 사용해야하며 구성 방법은 다음과 같습니다.
Zuul : Prefix :/API 무시-파괴 :/**/hello/** 경로 : 로컬 : Path :/Hello-Service/** url :/local
Springsecurity 또는 타사 구성 요소에 연결하는 일반적으로 사용되는 일부는 쿠키 정보 중 일부를 얻습니다. 따라서 Zuul Gateway는 보안상의 이유로 쿠키 정보를 모두 죽였으며 쿠키를 만들 수있는 방법이 없습니다. 기본적으로 사망합니다.
여기서 Zuul은 Zuul.sensitive-Headers를 제공하여 이러한 쿠키와 헤더를 만들고 이러한 정보를 필터링하지 마십시오. 민감한 정보를 제어하십시오.
기본적으로 민감한 헤더 정보는 API 게이트웨이를 통해 전달할 수 없습니다. 다음 구성을 통해 통과 할 수 있습니다.
Zuul : 경로 : hello-service : path : /hello-service /** serviceid : hello-service sensitive-headers : 쿠키, 헤더 및 기타 물건
또한 앞에서 언급했듯이 Hystrix의 자세한 구성과 함께 사용할 수 있습니다. 나는 여기서 그것에 대해 이야기하지 않을 것입니다
위는이 기사의 모든 내용입니다. 모든 사람의 학습에 도움이되기를 바랍니다. 모든 사람이 wulin.com을 더 지원하기를 바랍니다.