部署Nginx Plus作为API网关：Nginx

一些API可以在单个后端实现，但是出于弹性或负载平衡的原因，我们通常期望存在多个API。使用微服务API，我们为每个服务定义单独的后端;它们一起作为完整的API。在这里，我们的Warehouse API被部署为两个独立的服务，每个服务都有多个后端。

upstream warehouse_inventory { 
 zone inventory_service 64k; 
 server 10.0.0.1:80; 
 server 10.0.0.2:80; 
 server 10.0.0.3:80; 
} 
  
upstream warehouse_pricing { 
 zone pricing_service 64k; 
 server 10.0.0.7:80; 
 server 10.0.0.8:80; 
 server 10.0.0.9:80; 
} 

API网关发布的所有API的所有后端API服务都在api_backends.conf中定义。这里我们在每个块中使用多个IP地址 - 端口对来指示API代码的部署位置，但也可以使用主机名。 NGINX Plus订户还可以利用动态DNS负载平衡，自动将新后端添加到运行时配置中。

定义Warehouse API

配置的这一部分首先定义Warehouse API的有效URI，然后定义用于处理对Warehouse API的请求的公共策略。

# API definition 
# 
location /api/warehouse/inventory { 
 set $upstream warehouse_inventory; 
 rewrite ^ /_warehouse last; 
} 
  
location /api/warehouse/pricing { 
 set $upstream warehouse_pricing; 
 rewrite ^ /_warehouse last; 
} 
  
# Policy section 
# 
location = /_warehouse { 
 internal; 
 set $api_name "Warehouse"; 
  
 # Policy configuration here (authentication, rate limiting, logging, more...) 
  
 proxy_pass http://$upstream$request_uri; 
} 

Warehouse API定义了许多块。 NGINX Plus具有高效灵活的系统，可将请求URI与配置的一部分进行匹配。通常，请求由最具体的路径前缀匹配，并且位置指令的顺序并不重要。这里，在第3行和第8行，我们定义了两个路径前缀。在每种情况下，$ upstream变量都设置为上游块的名称，该上游块分别代表库存和定价服务的后端API服务。

此配置的目标是将API定义与管理API交付方式的策略分开。为此，我们最小化了API定义部分中显示的配置。在为每个位置确定适当的上游组之后，我们停止处理并使用指令来查找API的策略(第10行)。

使用重写指令将处理移至API策略部分

重写指令的结果是NGINX Plus搜索匹配以/ _warehouse开头的URI的位置块。第15行的位置块使用=修饰符执行完全匹配，从而加快处理速度。

（编辑：核心网）

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