로 컬 nginx 서비스 배포

처음에는 nginx 를 손 에 넣 고 스스로 뒤 집 었 다.자신 이 현지에서 서 비 스 를 배치 하여 나 누 어 주 었 다.회사 컴퓨터 에 있어 서 windows 버 전 입 니 다.mac 의 차 이 는 많 지 않 을 것 입 니 다. 집에 가서 이 글 을 정리 하 세 요.
hosts
    127.0.0.1     www.nodurex.com     www.online.com
nginx.conf

 upstream nodurex{
    server  www.nodurex.com:8080;
}

 server {
        listen       80;
        server_name  www.online.com;

        location / {
            proxy_pass http://www.nodurex.com:8080;
           #     upstream   ，    ，       。
           #      proxy_pass http://nodurex;
        }
    }

이렇게 하면 로 컬 에서 8080 포트 의 서 비 스 를 시작 하여 www. online. com 으로 방문 할 수 있 고 nginx 에서 www. nodurex. com 으로 배포 할 수 있 습 니 다.access. log 에 기록 되 어 있 습 니 다.
Nginx 를 대리 로 하 는 예 는 다음 과 같다.

server {
  listen       10.1.146.144
  server_name  www.soso.com;
  access_log  /data/nginxLog/nginx.soso.com.access.log  main;
  error_log   /data/nginxLog/nginx.soso.com.error.log;
   location / {
                       proxy_pass   http://upstreamName;
                       include /usr/local/nginx/conf/proxy.conf;
                }  
        }  

upstream Name 은 자신 이 정의 하 는 부하 균형 방식 입 니 다. 자주 사용 하 는 upstream 은 다음 과 같 습 니 다.
1. 폴 링
모든 요청 은 시간 순서에 따라 다른 백 엔 드 서버 에 하나씩 분 배 됩 니 다.
upstream poll_svr (이곳 은 upstream 의 이름 으로 임의로 지 을 수 있 습 니 다) {
server 10.1.146.163;
server 10.1.146.133;
}
2.weight
폴 링 확률 을 지정 하고 weight 와 방문 비율 이 정비례 하여 백 엔 드 서버 의 성능 이 고 르 지 않 은 경우 에 사용 합 니 다.예 를 들 면:

upstream weight_svr {
server 10.1.146.163 weight=2;
server 10.1.146.133 weight=1;
}

설명:
1) weight 를 설정 하지 않 으 면 기본 weight 는 1 입 니 다.따라서 각 server 가 weight 를 지정 하지 않 으 면 방식 1 에 해당 합 니 다.
2) 기계 다운 이 떨 어 지면 다른 기 계 를 사용 해 본다.
3.ip_hash
모든 요청 은 ip 에 접근 하 는 hash 결과 에 따라 분 배 됩 니 다. 모든 방문객 이 백 엔 드 서버 에 고정 적 으로 접근 하면 session 문 제 를 해결 할 수 있 습 니 다.
예 를 들 면:

upstream ip_hash_svr {
ip_hash;
server 10.1.146.163;
server 10.1.146.133;
}

설명:
이 방식 을 사용 할 때 기계 다운 이 떨 어 지면 다른 기계 에 서 비 스 를 요청 하려 고 시도 합 니 다.
상기 몇 가지 방식 에 대해 각 server 는 다음 과 같은 몇 가지 속성 치 를 가 질 수 있 습 니 다.
1. 다운 은 목록 앞의 server 가 부하 에 잠시 참여 하지 않 음 을 표시 합 니 다.
2. weight 는 기본적으로 1. weight 가 클 수록 부하 의 가중치 가 커진다.
3.max_fails，fail_timeout: failtimeout 이 지정 한 주기 내 에 max 가 있 으 면fails 번 실패 하면 서 비 스 를 이번 주 내 에 사용 할 수 없다 고 생각 합 니 다. 다음 failtimeout 주말 에 도 이 서 비 스 를 방문 하려 고 시도 합 니 다.설정 하지 않 으 면 maxfails 기본 값 은 1, failtimeou 기본 값 은 10s 입 니 다.하면, 만약, 만약...fails 값 을 0 으로 설정 하면 이 검 사 를 하지 않 습 니 다.
4. backup (0.6.7 이후 버 전 지원): 다른 모든 비 backup 기기 다운 또는 바 쁠 때 backup 기 계 를 요청 합 니 다.
종합 예시

upstream  backend  {
server backend1.example.com    weight=5;
server 127.0.0.1:8080          max_fails=3  fail_timeout=30s;
server unix:/tmp/backend3;
}

4. fair (제3자 플러그 인 필요)
백 엔 드 서버 의 응답 시간 에 따라 요청 을 분배 하고 응답 시간 이 짧 은 우선 분 배 를 합 니 다.

upstream fair _svr{
    server server1;
    server server2;
    fair;
}

5、url_hash (제3자 플러그 인 필요)
url 에 접근 한 hash 결과 에 따라 요청 을 할당 합 니 다. 모든 url 을 같은 백 엔 드 서버 로 지정 하고 백 엔 드 서버 가 캐 시 (squid 등) 일 때 유효 합 니 다.
예: upstream 에 hash 문 구 를 추가 하고 server 문 구 는 weight 등 다른 인 자 를 기록 할 수 없습니다.

upstream url_hash _svr{
server 10.1.146.163;
server 10.1.146.133;   
hash   $request_uri;
}

설명:
이 방식 을 사용 할 때 기계 다운 이 떨 어 지면 다른 기 계 를 사용 해 보지 않 는 다.사용자 측 에 502 bad Gateway 를 직접 되 돌려 줍 니 다.
이상 의 방식 은 1, 2, 3 은 nginx 자체 테이프 이 고 4, 5 는 제3자 플러그 인 이 필요 합 니 다.서버 상태 값 ms 는 nginx 자체 테이프 의 upstream 에 만 적 용 됩 니 다.