먼저 로드 밸런싱에 대해 말씀드리겠습니다. 많은 사용자가 웹사이트를 방문하고 한 서버의 사용량이 너무 많으면 여러 서버가 필요합니다. 하지만 사용자는 주소를 통해 웹사이트에 액세스해야 합니다. 이 주소를 사용하여 로드 밸런싱 서버를 생성하고 백그라운드에서 여러 애플리케이션 서버에 요청을 균등하게 배포할 수 있습니다.
역방향 프록시
따라서 로드 밸런싱 서버를 통해 백그라운드에 있는 여러 애플리케이션 서버에 요청을 분산시키는 방법은 Reverse Proxy를 통해 얻을 수 있습니다.
로드 밸런싱 서버는 비즈니스 로직을 처리하지 않습니다. 사용자의 HTTP 요청은 Nginx로 전송되고 Nginx는 요청을 처리하는 백그라운드 애플리케이션 서버로 요청을 보냅니다. 처리가 완료된 후 애플리케이션 서버에서 HTTP 응답이 Nginx로 전송되고 최종적으로 클라이언트로 전송됩니다. 이것은 역방향 프록시입니다. Nginx는 클라이언트와 애플리케이션 서버를 연결하는 브리지일 뿐입니다(위 그림 참조).
PS: 로드 밸런싱은 역방향 프록시를 통해 달성할 수 있지만 역방향 프록시가 이를 달성하는 유일한 방법은 아닙니다. 동시에 역방향 프록시는 로드 균형 조정뿐만 아니라 다양한 기능을 수행할 수 있습니다.
마지막으로 Nginx를 시작하는 데 도움이 되도록 제가 작성한 블로그가 있습니다: http://xxgblog.com/2015/05/17/nginx-start/
만약 여러분이 작성하는 웹앱이 외부 네트워크에 직접 노출된다면, 더 이상 외부 요청을 처리할 수 없게 되고, 새로운 요청에도 전혀 응답하지 않게 되며, 여러 가지 복잡한 네트워크 문제에 직면하게 될 것입니다. 느린 연결 등) 이때 Nginx는 중간에 외부 요청을 받아 잘못된 요청(시간 초과, 느린 연결)을 차단하고 이를 순차적으로 Web App에 전달하는 데 사용되는 역방향 프록시입니다.
요청량이 많으면 여러 서버를 시작하게 됩니다. 이때 Nginx는 사용자가 설정한 규칙에 따라 요청을 서로 다른 서버에 분산시킬 수 있습니다. (예를 들어 서버 A와 B가 두 개 있습니다. 이때 A는 바쁘고 B는 유휴 상태이므로 B에 더 많은 요청을 분산시킵니다.) . 이것은 로드 밸런싱입니다.
병원에 환자를 치료하는 의사가 세 명 있는데, 그 기술 수준이 정확히 같다고 가정해 보겠습니다. 간호사 한 명이 환자를 받는 일을 담당합니다. 의사를 만나러 가면 간호사에게 가서 "의사를 만나고 싶다"고 하면 간호사가 의사 세 명을 확인하는데, A 의사는 환자가 3명, C 의사도 환자가 2명 있다. , 의사 B에게는 환자가 없습니다. 당신은 의사 B에게 갑니다. 의사는 서비스 자원이고, 간호사는 역 에이전트이며, 환자는 부하입니다. 로드 밸런싱은 서비스의 리소스를 균형 있게 사용하도록 하는 것입니다. 역방향 프록시의 목적은 로드 밸런싱을 달성하는 것입니다.
역방향 프록시에 대한 스케줄링 알고리즘에는 여러 가지가 있습니다. 예를 들어 가장 간단한 것은 1:1 할당입니다. 첫 번째 환자는 의사 B에게, 세 번째 환자는 의사 C에게 할당됩니다. 그리고 네 번째 환자는 A 의사에게 주어졌습니다. A 의사... 등등. 배울 수 있는 다른 알고리즘도 많이 있습니다.
역방향 프록시라고 불리는 이유는 무엇입니까? 벽을 넘어갔다면 그 벽을 극복하는 것이 프록시 서버에 의존한다는 것을 알게 될 것입니다. 우리는 프록시 서버에 연결하고, 프록시 서버는 다른 웹사이트로 점프합니다. 이는 순방향 프록시로 이해될 수 있습니다. 역방향 프록시는 정반대입니다.
이는 프록시 서버가 클라이언트 측에 있는 정방향 프록시로 간단히 이해될 수 있습니다. 리버스 프록시, 프록시 서버는 서버 측에 있습니다.
역방향 프록시는 nginx뿐만 아니라 Apache에서도 수행할 수 있습니다.
좀 거칠고, 제가 이해한 대로 정리했습니다. 혹시 틀린 부분이 있으면 자유롭게 토론해주세요.
로드밸런싱
먼저 로드 밸런싱에 대해 말씀드리겠습니다. 많은 사용자가 웹사이트를 방문하고 한 서버의 사용량이 너무 많으면 여러 서버가 필요합니다. 하지만 사용자는 주소를 통해 웹사이트에 액세스해야 합니다. 이 주소를 사용하여 로드 밸런싱 서버를 생성하고 백그라운드에서 여러 애플리케이션 서버에 요청을 균등하게 배포할 수 있습니다.
역방향 프록시
따라서 로드 밸런싱 서버를 통해 백그라운드에 있는 여러 애플리케이션 서버에 요청을 분산시키는 방법은 Reverse Proxy를 통해 얻을 수 있습니다.
로드 밸런싱 서버는 비즈니스 로직을 처리하지 않습니다. 사용자의 HTTP 요청은 Nginx로 전송되고 Nginx는 요청을 처리하는 백그라운드 애플리케이션 서버로 요청을 보냅니다. 처리가 완료된 후 애플리케이션 서버에서 HTTP 응답이 Nginx로 전송되고 최종적으로 클라이언트로 전송됩니다. 이것은 역방향 프록시입니다. Nginx는 클라이언트와 애플리케이션 서버를 연결하는 브리지일 뿐입니다(위 그림 참조).
PS: 로드 밸런싱은 역방향 프록시를 통해 달성할 수 있지만 역방향 프록시가 이를 달성하는 유일한 방법은 아닙니다. 동시에 역방향 프록시는 로드 균형 조정뿐만 아니라 다양한 기능을 수행할 수 있습니다.
마지막으로 Nginx를 시작하는 데 도움이 되도록 제가 작성한 블로그가 있습니다:
http://xxgblog.com/2015/05/17/nginx-start/
만약 여러분이 작성하는 웹앱이 외부 네트워크에 직접 노출된다면, 더 이상 외부 요청을 처리할 수 없게 되고, 새로운 요청에도 전혀 응답하지 않게 되며, 여러 가지 복잡한 네트워크 문제에 직면하게 될 것입니다. 느린 연결 등) 이때 Nginx는 중간에 외부 요청을 받아 잘못된 요청(시간 초과, 느린 연결)을 차단하고 이를 순차적으로 Web App에 전달하는 데 사용되는 역방향 프록시입니다.
요청량이 많으면 여러 서버를 시작하게 됩니다. 이때 Nginx는 사용자가 설정한 규칙에 따라 요청을 서로 다른 서버에 분산시킬 수 있습니다. (예를 들어 서버 A와 B가 두 개 있습니다. 이때 A는 바쁘고 B는 유휴 상태이므로 B에 더 많은 요청을 분산시킵니다.) . 이것은 로드 밸런싱입니다.
병원에 환자를 치료하는 의사가 세 명 있는데, 그 기술 수준이 정확히 같다고 가정해 보겠습니다. 간호사 한 명이 환자를 받는 일을 담당합니다. 의사를 만나러 가면 간호사에게 가서 "의사를 만나고 싶다"고 하면 간호사가 의사 세 명을 확인하는데, A 의사는 환자가 3명, C 의사도 환자가 2명 있다. , 의사 B에게는 환자가 없습니다. 당신은 의사 B에게 갑니다. 의사는 서비스 자원이고, 간호사는 역 에이전트이며, 환자는 부하입니다. 로드 밸런싱은 서비스의 리소스를 균형 있게 사용하도록 하는 것입니다. 역방향 프록시의 목적은 로드 밸런싱을 달성하는 것입니다.
역방향 프록시에 대한 스케줄링 알고리즘에는 여러 가지가 있습니다. 예를 들어 가장 간단한 것은 1:1 할당입니다. 첫 번째 환자는 의사 B에게, 세 번째 환자는 의사 C에게 할당됩니다. 그리고 네 번째 환자는 A 의사에게 주어졌습니다. A 의사... 등등. 배울 수 있는 다른 알고리즘도 많이 있습니다.
역방향 프록시라고 불리는 이유는 무엇입니까? 벽을 넘어갔다면 그 벽을 극복하는 것이 프록시 서버에 의존한다는 것을 알게 될 것입니다. 우리는 프록시 서버에 연결하고, 프록시 서버는 다른 웹사이트로 점프합니다. 이는 순방향 프록시로 이해될 수 있습니다. 역방향 프록시는 정반대입니다.
이는 프록시 서버가 클라이언트 측에 있는 정방향 프록시로 간단히 이해될 수 있습니다. 리버스 프록시, 프록시 서버는 서버 측에 있습니다.
역방향 프록시는 nginx뿐만 아니라 Apache에서도 수행할 수 있습니다.
좀 거칠고, 제가 이해한 대로 정리했습니다. 혹시 틀린 부분이 있으면 자유롭게 토론해주세요.