部署Nginx Plus作为API网关：Nginx

了解着名的Nginx服务器(微服务必不可少的东西)如何用作API网关。

现代应用程序体系结构的核心是HTTP API。 HTTP使应用程序能够快速构建并轻松维护。无论应用程序的规模如何，HTTP API都提供了一个通用接口，从单用途微服务到无所不包的整体。通过使用HTTP，支持超大规模Internet属性的Web应用程序交付的进步也可用于提供可靠和高性能的API交付。

有关API网关对微服务应用程序重要性的精彩介绍，请参阅我们博客上的构建微服务：使用API​​网关。

作为领先的高性能，轻量级反向代理和负载均衡器，NGINX Plus具有处理API流量所需的高级HTTP处理功能。这使得NGINX Plus成为构建API网关的理想平台。在这篇博文中，我们描述了许多常见的API网关用例，并展示了如何配置NGINX Plus以便以高效，可扩展且易于维护的方式处理它们。我们描述了一个完整的配置，它可以构成生产部署的基础。

注意：除非另有说明，否则本文中的所有信息均适用于NGINX Plus和NGINX开源。

介绍Warehouse API

API网关的主要功能是为多个API提供单一，一致的入口点，无论它们在后端如何实现或部署。并非所有API都是微服务应用程序。我们的API网关需要管理现有的API，单块和正在部分过渡到微服务的应用程序。

在这篇博文中，我们引用了一个假设的库存管理API，即“仓库API”。我们使用示例配置代码来说明不同的用例。 Warehouse API是一个RESTful API，它使用JSON请求并生成JSON响应。但是，当部署为API网关时，使用JSON不是NGINX Plus的限制或要求; NGINX Plus与API本身使用的架构风格和数据格式无关。

Warehouse API实现为离散微服务的集合，并作为单个API发布。库存和定价资源作为单独的服务实施，并部署到不同的后端。所以API的路径结构是：

api └── warehouse  
├── inventory  
 └── pricing 

例如，要查询当前仓库库存，客户端应用程序会向/ api / warehouse / inventory发出HTTP GET请求。

组织NGINX配置

使用NGINX Plus作为API网关的一个优点是，它可以执行该角色，同时充当现有HTTP流量的反向代理，负载平衡器和Web服务器。如果NGINX Plus已经是应用程序交付堆栈的一部分，那么通常不需要部署单独的API网关。但是，API网关所期望的某些默认行为与基于浏览器的流量的预期不同。出于这个原因，我们将API网关配置与基于浏览器的流量的任何现有(或未来)配置分开。

为实现这种分离，我们创建了一个支持多用途NGINX Plus实例的配置布局，并为通过CI / CD管道自动配置部署提供了便利的结构。 / etc / nginx下的结果目录结构如下所示。

etc/ └── nginx/  
 ├── api_conf.d/ ....................................... Subdirectory for per-API configuration  
 │ └── warehouse_api.conf ...... Definition and policy of the Warehouse API  
 ├── api_backends.conf ..................... The backend services (upstreams)  
 ├── api_gateway.conf ........................ Top-level configuration for the API gateway server  
 ├── api_json_errors.conf ............ HTTP error responses in JSON format  
 ├── conf.d/ 
 │ ├── ...  
 │ └── existing_apps.conf  
 └── nginx.conf 

所有API网关配置的目录和文件名都以api_为前缀。这些文件和目录中的每一个都启用API网关的不同特性和功能，并在下面详细说明。

定义顶级API网关

所有NGINX配置都以主配置文件nginx.conf开头。要读入API网关配置，我们在nginx.conf的http块中添加一个指令，该指令引用包含网关配置的文件api_gateway.conf(下面的第28行)。请注意，默认的nginx.conf文件使用include伪指令从conf.d子目录中引入基于浏览器的HTTP配置(第29行)。本博文广泛使用include指令来提高可读性并实现配置某些部分的自动化。

include /etc/nginx/api_gateway.conf; # All API gateway configuration 
 include /etc/nginx/conf.d/*.conf; # Regular web traffic 

api_gateway.conf文件定义了将NGINX Plus公开为客户端的API网关的虚拟服务器。此配置公开API网关在单个入口点https://api.example.com/(第13行)发布的所有API，受第16到21行配置的TLS保护。请注意，此配置纯粹是HTTPS - 没有明文HTTP侦听器。我们希望API客户端知道正确的入口点并默认进行HTTPS连接。

log_format api_main '$remote_addr - $remote_user [$time_local] "$request"' 
 '$status $body_bytes_sent "$http_referer" "$http_user_agent"' 
 '"$http_x_forwarded_for" "$api_name"'; 
  
include api_backends.conf; 
include api_keys.conf; 
  
server { 
 set $api_name -; # Start with an undefined API name, each API will update this value 
 access_log /var/log/nginx/api_access.log api_main; # Each API may also log to a separate file 
  
 listen 443 ssl; 
 server_name api.example.com; 
  
 # TLS config 
 ssl_certificate /etc/ssl/certs/api.example.com.crt; 
 ssl_certificate_key /etc/ssl/private/api.example.com.key; 
 ssl_session_cache shared:SSL:10m; 
 ssl_session_timeout 5m; 
 ssl_ciphers HIGH:!aNULL:!MD5; 
 ssl_protocols TLSv1.1 TLSv1.2; 
  
 # API definitions, one per file 
 include api_conf.d/*.conf; 
  
 # Error responses 
 error_page 404 = @400; # Invalid paths are treated as bad requests 
 proxy_intercept_errors on; # Do not send backend errors to the client 
 include api_json_errors.conf; # API client friendly JSON error responses 
 default_type application/json; # If no content-type then assume JSON 
} 

此配置是静态的 - 各个API及其后端服务的详细信息在第24行的include伪指令引用的文件中指定。第27到30行处理日志记录默认值和错误处理，并在响应中讨论错误部分如下。

单服务与微服务API后端

（编辑：核心网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!