nginx 재 작성 (rewrite) 을 통 해 이전 버 전 api 인 터 페 이 스 를 새 버 전 인터페이스 로 전송 합 니 다.
1367 단어 nginx
프로젝트 를 시작 할 때 nginx 는 매 칭
control 을 통 해 리 트 윗 을 했 습 니 다. 그 다음 에 업무 가 계속 증가 함 에 따라 매번 수정 nginx 이 필요 하기 때문에 번 거 로 웠 습 니 다. 그래서 서로 다른 이름 을 지정 하기 로 결 정 했 습 니 다. 그리고 저 희 는 서비스 도 메 인 이름 과 일치 하 는 모델 을 통 해 서로 다른 설정 문 제 를 해결 하기 로 결 정 했 습 니 다.처음 nginx 설정:
location ~* /api/AppVersion {
proxy_pass http://192.168.1.88:8888;
}현재 원 하 는 설정
serviceName 뒤에 n 다 중 컨트롤 러 포함):location ~* /api/Business {
proxy_pass http://192.168.1.88:8888;
}만약 에 웹 사이트 라면 이렇게 하면 ok 이 많 지 않 습 니 다. 그러나 우 리 는 하나
app 가 있 습 니 다. 오래된 버 전 은 업그레이드 가 필요 하고 첫 번 째 인터페이스 만 호출 할 수 있 습 니 다. 그러나 우리 의 새로운 버 전의 인 터 페 이 스 는 모두 serviceName /api/Business/AppVersion 를 추 가 했 습 니 다. 지금 은 두 가지 방식 이 생각 났 습 니 다.1. 새로운 오래된 버 전의 api 인 터 페 이 스 를 제공 합 니 다.2.
nginx 설정 을 통 해 재 작성 (재 전송) 을 설정 합 니 다. 그 때 는 아 닙 니 다. nginx 가 강하 다 는 것 만 알 고 지원 할 수 있 을 것 입 니 다.그래서 잊 어 버 리 기 위해 찾 아 봤 습 니 다.
location ~* /api/AppVersion/GetVersion {
rewrite ^ http://192.168.1.88:8888/api/Business/AppVersion/GetVersion;
}그러면 오래된 인터페이스
/api/AppVersion/GetVersion 를 호출 할 때 nginx 는 자동 으로 새로운 인터페이스 /api/Business/AppVersion/GetVersion 로 전송 되 고 코드 를 수정 하지 않 아 도 안전 하고 편리 합 니 다.
이 내용에 흥미가 있습니까?
현재 기사가 여러분의 문제를 해결하지 못하는 경우 AI 엔진은 머신러닝 분석(스마트 모델이 방금 만들어져 부정확한 경우가 있을 수 있음)을 통해 가장 유사한 기사를 추천합니다:
간단! Certbot을 사용하여 웹 사이트를 SSL(HTTPS)화하는 방법초보자가 인프라 주위를 정돈하는 것은 매우 어렵습니다. 이번은 사이트를 간단하게 SSL화(HTTP에서 HTTPS통신)로 변경하는 방법을 소개합니다! 이번에는 소프트웨어 시스템 Nginx CentOS7 의 환경에서 S...
텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
CC BY-SA 2.5, CC BY-SA 3.0 및 CC BY-SA 4.0에 따라 라이센스가 부여됩니다.
좋은 웹페이지 즐겨찾기
