저는 두 개의 서버를 사용하여 역방향 프록시를 구성합니다.
서버 A는 다음 구성을 통해 테스트 서버 그룹에 모든 요청을 전달합니다(단, 그룹에는 1개만 있음)
브라우저를 통해 서버 A에 접근하면 서버 B의 콘텐츠가 반환됩니다.
질문입니다.
1. 서버 B(역방향 프록시 서버)에는 구성이 필요하지 않은 것 같나요?
2. 프록시 서버에 차단 설정이 없으면 업스트림에 가입하여 역방향 프록시 서버가 될 수 있나요?
3. 로드 밸런싱을 위해 역방향 프록시를 사용할 때 서버 B의 프로젝트는 서버 A의 프로젝트와 일치해야 합니까?
怪我咯2017-05-16 17:10:55
포인트 1: 간단히 말해서 프록시 객체에는 구성이 필요하지 않지만 B에서 요청의 소스 IP를 처리하려면 A의 nginx에서 일부 구성을 수행하고 변경해야 한다는 점에 유의해야 합니다. 소스 IP를 요청 헤더에 넣으세요. 예를 들면 다음과 같습니다.
포인트 2: 업스트림을 사용한 적이 없으며 주로 Proxy_pass를 사용합니다으아악
포인트 3: 일반적으로 말하면 그렇습니다.
高洛峰2017-05-16 17:10:55
1 프록시 서버 B에는 설정이 필요하지 않습니다.
2 업스트림에 여러 서버 그룹을 추가하는 것을 로드 밸런싱 구성이라고 합니다. 그런 다음 Proxy_pass
3를 구성하세요. 로드 밸런싱된 서버는 이론적으로 데이터를 공유하고 동일한 비즈니스를 가지고 있지만 서버 부담을 줄이기 위해 다른 시스템에 분산 및 배포됩니다. (작성자는 동일한 서버의 다른 포트에서 동일한 비즈니스로 여러 서비스를 시작할 수 있으며 로드 밸런싱을 구성하고 검증할 수 있습니다 직접!)
현재 로드 밸런싱 전략에는 여러 가지 방법이 있습니다
폴링(기본값): 각 요청은 시간순으로 하나씩 다른 백엔드 서버에 할당됩니다. 백엔드 서버가 다운되면 자동으로 제거될 수 있습니다.
가중치: 폴링 확률을 지정하며, 가중치는 액세스 비율에 비례하며 백엔드 서버 성능이 고르지 않을 때 사용됩니다.
ip_hash: 각 요청은 액세스된 IP의 해시 결과에 따라 할당되므로 각 방문자는 백엔드 서버에 대한 고정 액세스 권한을 갖게 되어 세션 문제를 해결할 수 있습니다.
fair(타사): 백엔드 서버의 응답 시간에 따라 요청을 할당하고, 응답 시간이 짧은 요청에 우선 순위를 둡니다.
url_hash(타사): 액세스한 URL의 해시 결과에 따라 요청을 분산하여 각 URL이 동일한 백엔드 서버로 연결되도록 백엔드 서버를 캐시할 때 더 효과적입니다.
