원작자: Yi Jiuping
원본 링크: 기록 공유 | 강력한 API 게이트웨이로 NGINX 구축(2부)
NGINX의 유일한 공식 중국어 커뮤니티(모두 http://nginx.org.cn )
편집자 주 - 이 기사는 NGINX Sprint China 2022 온라인 컨퍼런스의 공유 기록입니다. 컨퍼런스 전체 동영상을 무료로 시청하려면 여기를 클릭하세요. 글이 길어서 2부로 나누어 게재하겠습니다. 이전 기사를 읽으려면 "기록 공유 | 강력한 API 게이트웨이로 NGINX 구축(1부)"를 클릭하세요 .
이번 공유에서는 API 게이트웨이의 개념과 기능, 그리고 NGINX를 사용하여 강력한 API 게이트웨이를 만드는 방법을 포괄적으로 소개합니다.
3. API 게이트웨이 구축 시작
API 게이트웨이를 구축하는 방법은 무엇입니까? 엔지니어링 관점에서 전체 개발 프로세스를 완료하려면 일부 소프트웨어 개발 법률이나 일부 소프트웨어 엔지니어링 아이디어를 준수해야 합니다. 일반적으로 개발은 7가지 주요 단계로 완료될 수 있습니다.
- 게이트웨이 기능 계획: API 게이트웨이의 기능을 계획하고 API 게이트웨이의 기능적, 비기능적 특성을 명확히 합니다.
- 기술 아키텍처 설계: 기술 아키텍처를 명확히 하고 데이터 플레인, 컨트롤 플레인, 관리 플레인의 구성 요소 아키텍처를 결정합니다. 또한 기술 아키텍처의 타당성을 보장하기 위해 API 게이트웨이의 배포 위치를 명확히 하는 것도 필요합니다.
- NGINX 구성 설계: NGINX의 구성 설정과 게이트웨이 기능을 구현하는 데 어떤 NGINX 명령 및 구성이 사용되는지 명확히 합니다. 이때 기능이 실현 가능하고 요구 사항을 충족하는지 확인하기 위해 PoC 검증을 위해 수동 구성이 필요합니다.
- 구성 모델 설계: NGINX에 익숙하지 않은 사용자도 NGINX 게이트웨이를 빠르게 사용할 수 있습니다.
- 구성 템플릿 개발: 모델 및 구성 데이터를 통해 NGINX 구성을 자동으로 렌더링하고 생성할 수 있는 템플릿을 구현합니다.
- 제어 평면 개발: 제어 평면 개발을 통해 API 게이트웨이는 NGINX 오픈 소스 버전과 상용 버전을 모두 지원할 수 있으며 Reload 지원 외에도 동적 API 구성 변경도 지원할 수 있습니다.
- 기능 테스트 검증: API 게이트웨이의 기능이 실제로 존재하고 사용 가능한지 확인합니다.
3.1 API 게이트웨이 기능 아키텍처
우선, 이 API 게이트웨이의 기능은 실제로 하위 집합일 뿐입니다. API 게이트웨이로서 API의 역방향 프록시 기능 외에도 Eureka, Nacos 등 등록 센터와의 통합을 통해 백엔드 서비스 인스턴스를 검색해야 합니다. 또한 HTTP 프로토콜, gRPC 프로토콜, 웹 소켓 프로토콜 등 API가 지원하는 프로토콜을 명확히 할 필요가 있으며, 동시에 API는 분산화 및 도메인 기반 관리 기능을 갖추고 있어야 합니다. 주소 매칭이나 자동화된 구성 기능이 있기 때문에 Good Management API를 업데이트하는 방법에 대한 고민이 필요합니다.
두 번째 점은 API 액세스 제어, API 인증 방법 등과 같은 API 보안에 주의가 필요하다는 것입니다.
세 번째는 API 흐름 제어입니다. API 게이트웨이가 백엔드 애플리케이션을 트래픽 입구로 보호할 수 있는지 확인하는 것이 필요합니다. 트래픽 속도를 제한하고, 요청 재작성, 응답 재작성을 수행하거나, 통합 오류 코드 변환을 수행하고 심지어 수행할 수도 있습니다. 일부 응용 프로그램 최적화. 또한 트래픽 스케줄링을 구현해야 하며 역방향 프록시 로드 밸런싱의 일반적인 기능 외에도 그레이스케일 게시, 청록색 게시 기능 또는 트래픽 계산 기능도 구현할 수 있습니다.
3.2 API 게이트웨이 기술 아키텍처
위 그림은 단순한 기술 아키텍처 설계입니다. 물론 이 기술 아키텍처는 단지 청사진일 뿐이며, 이 실험은 모든 기능을 구현하지는 않았으며 주로 데이터 플레인과 컨트롤 플레인의 기능을 구현했습니다.
컨트롤 플레인의 핵심 기능은 구성 센터 또는 관리 플레인과 통합하여 구성 데이터를 얻고 이를 NGINX 구성으로 변환하는 것입니다. 이 프로세스는 구성 파일을 생성한 다음 다시 로드하는 것일 수도 있고, NGINX API를 직접 호출하여 구성을 동적으로 로드하는 것일 수도 있습니다.
또한 게이트웨이 제어 서비스의 기능은 주로 구성을 작성하거나 수정하는 것입니다. 이번 데모에서는 etcd를 사용하여 구성을 저장하고, etcd를 데이터베이스로 사용하며, 먼저 etcd에 구성을 기록한 후 Confd 실행 템플릿을 통해 해당 구성을 NGINX 구성으로 변환합니다.
데이터 플레인으로서 API 게이트웨이는 비즈니스 서비스에 대한 역방향 프록시 역할을 할 뿐만 아니라 두 가지 유형의 서비스와 인터페이스할 수도 있습니다. 첫 번째는 API 액세스 인증 또는 인증을 위해 인증 및 권한 부여 센터와 인터페이스하는 것이고, 다른 하나는 모니터링 센터와 인터페이스하여 데이터 평면 모니터링을 구현합니다.
3.3 API 게이트웨이 구성 설계
NGINX에는 많은 기능이 있는데, 특정 기능을 구현하기 위해서는 이러한 기능에 대한 계획이 필요합니다. 다양한 차원에 따라 고려해야 하는 디렉토리 구조로 계획할 수 있습니다.
예를 들어 구성이 자주 수정되는지, 비즈니스 차원에 따라 분할되는지, 요청을 받는 HTTP 서비스 구성과 기본 구성을 분리해야 하는지, 백엔드 서비스 구성을 분리해야 하는지 등이 있습니다. 따라서 API 게이트웨이 관리가 더욱 단순해지고 분리되도록 이러한 계획을 수행해야 합니다.
3.4 API 게이트웨이 모델 설계
모델은 전체 응용 프로그램 시스템의 아키텍처를 결정합니다. 이번에 공유한 API 게이트웨이 아키텍처에서는 API 게이트웨이 모델을 설계했습니다. 위 그림에서는 모델을 두 가지 색상으로 구분합니다. 진한 파란색 부분을 엔터티로 정의하며 고유한 속성을 갖습니다. ID와 독립적인 생명주기, 연한 파란색 부분이 값 객체로 정의됩니다. 우리는 도메인 기반 사고를 사용하여 모델을 정의하므로 맨 위에 게이트웨이 엔터티가 있습니다.
게이트웨이는 게이트웨이 클러스터를 나타냅니다. 클러스터에는 여러 개의 NGINX 인스턴스가 있습니다. 동일한 게이트웨이라도 다른 서버를 가질 수 있습니다. 업스트림은 이해하기 쉬우며, 업스트림 서비스로서 업스트림 서비스 클러스터를 설명하는 모델이 있어야 합니다. 구성원은 다양한 방법으로 생성될 수 있으며 수동으로 구성하거나 자동으로 검색하거나 Excel에서 가져올 수 있습니다.
업스트림 서비스 클러스터(Upstream)에 대해서도 몇 가지 전략이 있으며 일반적으로 세 가지 유형의 전략이 있습니다. 첫째, 일부 트래픽 로드 밸런싱을 수행할지 여부, 둘째, 서비스의 연속성을 보장하기 위해 특정 상태 세션에 대한 세션을 유지할지 여부, 마지막으로 백엔드 서비스의 가용성을 감지하기 위해 일부 상태 확인 기능을 수행할지 여부를 명확히 합니다. 회로 차단기 다운그레이드를 수행합니다.
3.5 API 게이트웨이 제어 에이전트 개발
모델 설계가 완료된 후 에이전트 개발을 진행해야 하는데, 이때 공유하는 에이전트는 Confd인데, Confd 자체가 구성 변경 도구이기 때문에 보다 유연한 템플릿 기능을 지원하고, NoSQL 구성과의 도킹도 지원한다. etcd, Redis 등의 센터 또는 캐싱 서버. 이러한 방식으로 이를 사용하여 구성 변경 사항을 모니터링하고 구성 생성 및 로드를 완료할 수 있습니다.
3.6 API 게이트웨이 템플릿 개발
다들 템플릿 개념에 대해 많이 배웠는데 템플릿은 실제로 동적과 정적인 것을 결합하고, 정적인 것을 템플릿에 넣고, 동적인 것을 변수로 변환하는 아이디어를 사용합니다. 템플릿이 더 유연하다면 다른 판단을 내릴 수도 있고 for 루프를 만들 수도 있으며 일부 확장 기능을 구현하고 일부 명령을 호출하는 등의 작업도 할 수 있습니다.
기능 테스트는 시나리오와 유스 케이스의 두 가지 차원으로 나누어집니다.예를 들어 TLS 오프로딩 시나리오를 테스트할 때 인증서가 만료되었는지 여부와 인증서가 어디에 저장되어 있는지 고려해야 합니다.시나리오 및 유스 케이스의 설계는 다음과 같이 구현되어야 합니다. 전반적인 기능 계획과 연계됩니다.
또한 테스트 프로세스 전반에 걸쳐 백엔드 서비스가 있어야 합니다. 유스 케이스에서는 간단한 애플리케이션을 구현합니다. 이 애플리케이션의 기능은 매우 간단합니다. API 테스트에만 사용되며 단순히 여러 비즈니스 분야의 서비스를 구현합니다. 주로 테스트 요구 사항을 충족하기 위한 것이므로 구현이 너무 많지 않습니다. 복잡한.
후속 업데이트에서 새로운 기능이 추가될 수 있으므로 자동화된 테스트 도구를 사용할 수도 있으며, 새로운 기능을 추가하는 과정에서는 원래 기능의 가용성이 보장되어야 하므로 통합 및 제공을 자동화하는 것이 가장 좋습니다.
NGINX의 유일한 공식 중국어 커뮤니티(모두 nginx.org.cn )
추가 NGINX 관련 기술 정보, 대화형 Q&A, 일련의 과정 및 이벤트 리소스:
오픈소스 커뮤니티 공식 홈페이지: 오픈소스 웹 서비스 제공자-NGINX 오픈소스 커뮤니티
WeChat 공개 계정: NGINX는 오픈 소스 커뮤니티에 대한 새로운 약속을 엄숙하게 발표합니다.
IntelliJ IDEA 2023.3 및 JetBrains Family Bucket 연간 주요 버전 업데이트 새로운 개념 "방어 프로그래밍": 안정적인 작업 수행 GitHub.com은 1,200개 이상의 MySQL 호스트를 실행합니다. 8.0으로 원활하게 업그레이드하는 방법은 무엇입니까? Stephen Chow의 Web3 팀은 다음 달에 독립 앱을 출시할 예정입니다. Firefox는 사라질까요? Visual Studio Code 1.85 출시, 부동 창 US CISA는 메모리 보안 취약점을 제거하기 위해 C/C++ 포기를 권장합니다. Yu Chengdong: Huawei는 내년에 파괴적인 제품을 출시하고 업계 역사를 다시 쓸 것입니다. TIOBE 12월: C#이 올해의 프로그래밍 언어가 될 것으로 예상됩니다. A 논문 Lei Jun이 30년 전에 작성함: "컴퓨터 바이러스 판별 전문가 시스템의 원리 및 설계"