八步部署NGINX Plus API網(wǎng)關(guān)

awesome23 發(fā)布于2019-07-25 14:20 / 3786人閱讀

摘要：作為一組獨(dú)立的微服務(wù)之一被實(shí)現(xiàn)并作為一個(gè)多帶帶的進(jìn)行發(fā)布。該配置將暴露所有由網(wǎng)關(guān)發(fā)布的，入口位于，用協(xié)議加密保護(hù)。由網(wǎng)關(guān)發(fā)布的所有的所有后端服務(wù)均在中被定義。與瀏覽器不同，網(wǎng)關(guān)并不能向客戶端發(fā)送帶有新的命名的重定向。

歡迎大家前往騰訊云+社區(qū)，獲取更多騰訊海量技術(shù)實(shí)踐干貨哦~

本文來自云+社區(qū)翻譯社，作者ArrayZoneYour

Nginx往往是構(gòu)建微服務(wù)中必不可缺的一部分，從本文中你可以習(xí)得如何使用Nginx作為API網(wǎng)關(guān)。

HTTP API是現(xiàn)代應(yīng)用架構(gòu)的核心。HTTP協(xié)議使開發(fā)者可以更快地構(gòu)建應(yīng)用并使應(yīng)用的維護(hù)變得更加容易。HTTP API提供了一套通用的接口，這使得在任意的應(yīng)用規(guī)模下，我們都可以借助HTTP API從一個(gè)基本的微服務(wù)開始構(gòu)建出一個(gè)具有完備功能的整體。借助HTTP，普通的web應(yīng)用程序也可以在規(guī)模巨大的互聯(lián)網(wǎng)上提供高性能、高可用的API。

如果你還不理解API網(wǎng)關(guān)對(duì)微服務(wù)應(yīng)用的重要性，可以參閱Building Microservices: Using an API Gateway

作為領(lǐng)先的高性能、輕量級(jí)反向代理和負(fù)載均衡器解決方案，NGINX Plus具有處理API流量所需的高級(jí)HTTP處理能力。這使得NGINX Plus成為構(gòu)建API網(wǎng)關(guān)的理想平臺(tái)。在本文中，我們將使用一些常見的API網(wǎng)關(guān)為例展示如何配置NGINX Plus來以高效、可擴(kuò)展、易維護(hù)的方式處理它們。最后我們會(huì)得到一套可作為生產(chǎn)環(huán)境部署基礎(chǔ)的完整配置。

注：除特殊注明外，本文中所有的配置同時(shí)適用于NGINX和NGINX Plus。

樣例API簡介（以倉儲(chǔ)背景為例）

API網(wǎng)關(guān)的主要功能是為不同的API分別提供多帶帶，一致的入口點(diǎn)，它的實(shí)現(xiàn)與后端的實(shí)現(xiàn)與部署方式無關(guān)。實(shí)際場景中，往往不是所有的API都是以微服務(wù)的方式實(shí)現(xiàn)的。我們的API網(wǎng)關(guān)需要同時(shí)管理現(xiàn)有的API、巨無霸式的API（monoliths，對(duì)與微服務(wù)相對(duì)的龐然大物的戲稱）以及開始局部切換為微服務(wù)的應(yīng)用等等。

在本文中，我們假想一個(gè)庫存管理的API（WareHouse API）為例進(jìn)行說明。我們使用實(shí)例的配置代碼來說明不同的用例。我們假設(shè)的API是一個(gè)RESTful API，它接受JSON請(qǐng)求并生成JSON數(shù)據(jù)響應(yīng)請(qǐng)求。雖然我們本文中是以RESTful API為例進(jìn)行講解，但是NGINX Plus作為API網(wǎng)關(guān)部署時(shí)并不要求或者限制JSON的使用；NGINX Plus本身并不知道API使用的架構(gòu)或者數(shù)據(jù)格式。

WareHouse API 作為一組獨(dú)立的微服務(wù)之一被實(shí)現(xiàn)并作為一個(gè)多帶帶的API進(jìn)行發(fā)布。其下的inventory 和 pricing 資源分別作為多帶帶的服務(wù)集成并部署在不同的后端上。由此可以畫出如下的API路徑結(jié)構(gòu)：

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

舉例來說，如果我們想獲得倉庫的庫存信息，則需要通過客戶端發(fā)送一個(gè) HTTP GET請(qǐng)求到/api/warehouse/inventory.

API結(jié)構(gòu)示意圖

組織NGINX的配置文件

我們使用NGINX Plus作為API網(wǎng)關(guān)的好處是它可以同時(shí)扮演反向代理、負(fù)載均衡器以及現(xiàn)有HTTP流量所需的web服務(wù)器這三個(gè)角色。如果NGINX Plus已經(jīng)是你的應(yīng)用交付棧的一部分，那么你不需要再用它部署一個(gè)多帶帶的API網(wǎng)關(guān)。不過，API網(wǎng)關(guān)預(yù)期的默認(rèn)行為與基于瀏覽器的流量所期望的默認(rèn)行為不同，因此我們需要將API網(wǎng)關(guān)配置與現(xiàn)存（未來）的基于瀏覽器所需的流量對(duì)應(yīng)的配置文件分來。

為了實(shí)現(xiàn)上述需求，我們?yōu)榕渲梦募?chuàng)建了以下目錄結(jié)構(gòu)來支持多用途的NGINX Plus實(shí)例，這也為通過CI / CD 管道自動(dòng)配置并部署提供了便利。

etc/
    └── nginx/
            ├── api_conf.d/ ....................................... API配置的子目錄
        │ └── warehouse_api.conf ...... Warehouse API 的定義及配置
        ├── api_backends.conf ..................... 后端服務(wù)配置 (upstreams)
        ├── api_gateway.conf ........................ API網(wǎng)關(guān)服務(wù)器的頂級(jí)配置
        ├── api_json_errors.conf ............ JSON格式的HTTP錯(cuò)誤響應(yīng)配置
        ├── conf.d/
        │ ├── ...
        │ └── existing_apps.conf
        └── nginx.conf

API網(wǎng)關(guān)配置的目錄和文件名都加了api_前綴。上面的每個(gè)目錄和文件都對(duì)應(yīng)著API網(wǎng)關(guān)的不同功能和特性，我們?cè)谙旅鏁?huì)逐個(gè)詳細(xì)解釋。

定義API網(wǎng)關(guān)的頂級(jí)配置

NGINX讀取配置將從主配置文件nginx.conf開始。為了讀取API網(wǎng)關(guān)配置，我們需要在nginx.conf中http塊中添加一條指令來引用包含網(wǎng)關(guān)配置的文件api_gateway.conf (大概在28行附近)。從文件內(nèi)容中我們可以看到nginx.conf中默認(rèn)從conf.d子目錄中讀取基于瀏覽器的HTTP配置。本文中將廣泛使用include命令來提高可讀性并實(shí)現(xiàn)部分配置的自動(dòng)化。

    include /etc/nginx/api_gateway.conf; # 所有的API網(wǎng)關(guān)配置
    include /etc/nginx/conf.d/*.conf;    # 正常的web流量配置

api_gateway.conf文件定義了將NGINX Plus作為API網(wǎng)關(guān)暴露給客戶端的虛擬服務(wù)器的配置。該配置將暴露所有由API網(wǎng)關(guān)發(fā)布的API，入口位于https://api.example.com/，用TLS協(xié)議加密保護(hù)。注意這里使用的配置文件是針對(duì)HTTPS的——并沒有使用明文傳輸?shù)腍TTP。這代表著我們默認(rèn)并要求API客戶端知道正確的入口點(diǎn)并使用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 配置
    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 定義, 每個(gè)文件對(duì)應(yīng)一個(gè)
    include api_conf.d/*.conf;
    # 錯(cuò)誤響應(yīng)
    error_page 404 = @400;         # 處理非法URI路徑的請(qǐng)求
    proxy_intercept_errors on;     # 不將后端的錯(cuò)誤消息發(fā)送給客戶端
    include api_json_errors.conf;  # 定義返回給客戶端的JSON響應(yīng)數(shù)據(jù)
    default_type application/json; # 如果不指定 content-type 則默認(rèn)為 JSON
}

以上配置是靜態(tài)的，表現(xiàn)在每個(gè)獨(dú)立API的細(xì)節(jié)以及響應(yīng)的后端服務(wù)是通過include命令引用相應(yīng)的文件實(shí)現(xiàn)的。上面文件的最后四行負(fù)責(zé)處理默認(rèn)的日志輸出以及錯(cuò)誤處理。我們將在后面的錯(cuò)誤響應(yīng) 一節(jié)中多帶帶討論。

單服務(wù) vs. 微服務(wù) API后端

一些API可以通過單個(gè)后端實(shí)現(xiàn)，但是出于彈性或者負(fù)載均衡等原因，我們通常期望有不止一個(gè)后端。通過微服務(wù)的API，我們可以為每個(gè)服務(wù)定義多帶帶的后端，將他們組合在一起就形成了完整的API。在本文中，我們的倉儲(chǔ)API被部署為兩個(gè)獨(dú)立的服務(wù)，每一個(gè)都有多個(gè)后端。

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網(wǎng)關(guān)發(fā)布的所有API的所有后端API服務(wù)均在api_backends.conf中被定義。這里我們?cè)诿總€(gè)塊中使用了多個(gè)IP地址-端口對(duì)來指示API代碼的部署位置，我們也可以使用主機(jī)名來替換IP地址。NGINX Plus 的訂閱用戶還可以使用動(dòng)態(tài)的DNS負(fù)載均衡功能自動(dòng)地將新的后端添加至在線運(yùn)行配置。

定義Warehouse API

這部分配置首先定義了Warehouse API的有效URI，然后定義了處理Warehouse API請(qǐng)求所用的通用策略。

# API 定義
#
location /api/warehouse/inventory {
    set $upstream warehouse_inventory;
    rewrite ^ /_warehouse last;
}
location /api/warehouse/pricing {
    set $upstream warehouse_pricing;
    rewrite ^ /_warehouse last;
}
# 策略
#
location = /_warehouse {
    internal;
    set $api_name "Warehouse";
    # 在這里配置相應(yīng)的策略 (認(rèn)證, 限速, 日志記錄, ...)
    proxy_pass http://$upstream$request_uri;
}

Warehouse API 通過一系列配置塊來定義。NGINX Plus具有靈活和高效的系統(tǒng)，這使得它可以將請(qǐng)求的URI與相應(yīng)的配置塊匹配。一般來說請(qǐng)求會(huì)通過具體的路徑前綴進(jìn)行匹配，location指令的順序并不重要。在上面的配置中我們?cè)诘谌泻偷诎诵卸x了兩個(gè)路徑前綴。在每個(gè)配置中，$upstream變量被設(shè)定為分別代表 inventory 和 pricing 的后端API服務(wù)。

此處這樣配置的目的是將API的定義與API的交付邏輯分離。為了實(shí)現(xiàn)這一目標(biāo)，我們盡量減少了API定義部分的配置內(nèi)容。當(dāng)我們?yōu)槊總€(gè) location 確定了合適的 upstream 組之后，可以使用指令來查找相應(yīng)的API策略。

使用rewrite指令將處理權(quán)移交給策略塊

rewrite指令的結(jié)果是NGINX Plus搜索開頭為/_warehouse的URI對(duì)應(yīng)的 location 塊。上面的配置中使用了 = 修飾符來進(jìn)行精確匹配，這提升了處理的速度。

在這個(gè)階段，我們的策略塊內(nèi)容非常簡單。在配置中的 iternal 意味著客戶端不能直接向它發(fā)出請(qǐng)求。$api_name變量被重新定義為匹配API的名稱，以便它可以在日志文件中正常顯示。最后請(qǐng)求會(huì)通過使用 $request_uri 變量（包含未修改的原始請(qǐng)求URI）代理至API定義部分中指定的 upstreame 組。

API的寬松定義 vs. 精確定義

API的定義有兩種方法——寬松的或者精確的。每個(gè)API最適合的方法取決于API的安全要求以及后端服務(wù)是否需要處理無效的URI。

在warehouse_api.simple.conf文件中，我們使用了寬松的方式來定義Warehouse API。這意味著任何前綴滿足要求的URI都會(huì)被代理到相應(yīng)的后端服務(wù)，即以下URI的API請(qǐng)求都會(huì)被作為有效URI進(jìn)行處理：

/api/warehouse/inventory

/api/warehouse/inventory/

/api/warehouse/inventory/foo

/api/warehouse/inventoryfoo

/api/warehouse/inventoryfoo/bar/

如果我們只需要考慮將每個(gè)請(qǐng)求代理到正確的后端服務(wù)，那么寬松的定義可以提供最快的處理速度和最緊湊的配置。相對(duì)地，使用精確的定義方法可以通過明確定義每個(gè)可用API資源的URI路徑來了解API的完整URI空間。Warehouse API 的下列配置結(jié)合使用完全匹配 ( = ) 和正則表達(dá)式 ( ~ ) 實(shí)現(xiàn)了對(duì)每個(gè)URI的精確匹配。

location = /api/warehouse/inventory { # Complete inventory
    set $upstream inventory_service;
    rewrite ^ /_warehouse last;
}
location ~ ^/api/warehouse/inventory/shelf/[^/]*$ { # Shelf inventory
    set $upstream inventory_service;
    rewrite ^ /_warehouse last;
}
location ~ ^/api/warehouse/inventory/shelf/[^/]*/box/[^/]*$ { # Box on shelf
    set $upstream inventory_service;
    rewrite ^ /_warehouse last;
}
location ~ ^/api/warehouse/pricing/[^/]*$ { # Price for specific item
    set $upstream pricing_service;
    rewrite ^ /_warehouse last;
}

上面的配置雖然啰嗦一點(diǎn)，但是更準(zhǔn)確地描述了后端服務(wù)實(shí)現(xiàn)的資源。這可以使后端服務(wù)免受惡意用戶請(qǐng)求的影響，但是會(huì)增加額外的開銷來處理正則表達(dá)式的匹配。在這種配置下，NGINX Plus會(huì)接受部分URI，其余的會(huì)被視為無效而被拒絕：

匹配示例

使用精確的API定義可以利用現(xiàn)有的API文檔格式驅(qū)動(dòng)API網(wǎng)關(guān)的配置，使OpenAPI規(guī)范（過去稱為Swagger）下的NGINX Plus API定義自動(dòng)化。本文配套提供了相應(yīng)的示例腳本。

重寫客戶端請(qǐng)求

隨著API的發(fā)展，有時(shí)出現(xiàn)的突發(fā)情況或變化要求更新客戶端的請(qǐng)求。一個(gè)典型的例子就是原有的API資源被重命名或者移除。與web瀏覽器不同，API網(wǎng)關(guān)并不能向客戶端發(fā)送帶有API新的命名的重定向。不過幸運(yùn)的是，我們可以通過重寫客戶端請(qǐng)求來解決這個(gè)問題。

在下面的代碼中，我們可以看到在第三行的位置，pricing服務(wù)之前是作為inventory服務(wù)的一部分實(shí)現(xiàn)的。所以現(xiàn)在我們使用rewrite指令來將舊的pricing資源請(qǐng)求切換至了對(duì)新的pricing資源的請(qǐng)求。

# 重寫規(guī)則
#
rewrite ^/api/warehouse/inventory/item/price/(.*)  /api/warehouse/pricing/$1;
# API 定義
#
location /api/warehouse/inventory {
    set $upstream inventory_service;
    rewrite ^(.*)$ /_warehouse$1 last;
}
location /api/warehouse/pricing {
    set $upstream pricing_service;
    rewrite ^(.*) /_warehouse$1 last;
}
# 處理策略
#
location /_warehouse {
    internal;
    set $api_name "Warehouse";
    # 在這里配置相應(yīng)的策略 (認(rèn)證, 限速, 日志記錄, ...)
    rewrite ^/_warehouse/(.*)$ /$1 break; # 移除 /_warehouse 前綴
    proxy_pass http://$upstream;          # 代理重寫后的URI
}

不過使用重寫URI也意味著在上面代碼的倒數(shù)第二行我們處理代理請(qǐng)求的時(shí)候不能再使用$request_uri變量（像warehouse_api_simple.conf的第21行的做法一樣）。所以我們需要在上述代碼的第9行和第14行的位置使用不同的rewrite指令之后將URI移交給策略部分的代碼塊進(jìn)行處理。

location /api/warehouse/inventory

錯(cuò)誤響應(yīng)

基于HTTP API和瀏覽器的流量之間的一個(gè)關(guān)鍵區(qū)別是錯(cuò)誤傳遞給客戶端的方式。當(dāng)我們配置NGINX Plus作為API網(wǎng)關(guān)時(shí)，我們將其配置其以最適合API客戶端的方式返回錯(cuò)誤信息。

  # 錯(cuò)誤響應(yīng)
    error_page 404 = @400;         # 處理非法URI路徑的請(qǐng)求
    proxy_intercept_errors on;     # 不將后端的錯(cuò)誤消息發(fā)送給客戶端
    include api_json_errors.conf;  # 定義返回給客戶端的JSON響應(yīng)數(shù)據(jù)
    default_type application/json; # 如果不指定 content-type 則默認(rèn)為 JSON

上面的代碼展示了我們?cè)陧攲拥腁PI網(wǎng)關(guān)中關(guān)于錯(cuò)誤響應(yīng)的配置。

由于上面第二行的配置，當(dāng)請(qǐng)求不能夠匹配到任何的API定義時(shí)，我們將返回該行定義的錯(cuò)誤而不是NGINX Plus默認(rèn)的錯(cuò)誤響應(yīng)給客戶端。這個(gè)可選的行為要求客戶端按照滿足API文檔規(guī)范的方式進(jìn)行請(qǐng)求，這避免了未經(jīng)授權(quán)的用戶通過API網(wǎng)關(guān)發(fā)現(xiàn)API的URI結(jié)構(gòu)。

proxy_interceprt_errors指的是后端服務(wù)生成的錯(cuò)誤信息。原始的錯(cuò)誤信息可能包含著錯(cuò)誤的堆棧信息或者其他以及一些其他我們不希望客戶端看到的敏感信息。打開這一配置之后，我們將錯(cuò)誤信息標(biāo)準(zhǔn)化之后再發(fā)送給客戶端，從而進(jìn)一步提升信息的安全級(jí)別。

再下一行，我們通過include指令引入了錯(cuò)誤響應(yīng)的完整列表，下面展示了其中的前幾行。如果你想采用JSON以外的其他錯(cuò)誤格式，那么你可以修改最后一行default_type指定的內(nèi)容。你還可以在每個(gè)API的策略塊中使用include指令來導(dǎo)入列表覆蓋默認(rèn)的錯(cuò)誤響應(yīng)。

error_page 400 = @400;
location @400 { return 400 "{"status":400,"message":"Bad request"}
"; }
error_page 401 = @401;
location @401 { return 401 "{"status":401,"message":"Unauthorized"}
"; }
error_page 403 = @403;
location @403 { return 403 "{"status":403,"message":"Forbidden"}
"; }
error_page 404 = @404;
location @404 { return 404 "{"status":404,"message":"Resource not found"}
"; }

在配置完成之后，此時(shí)客戶端發(fā)送無效的URI請(qǐng)求時(shí)會(huì)得到如下響應(yīng)：

$ curl -i https://api.example.com/foo
HTTP/1.1 400 Bad Request
Server: nginx/1.13.10
Content-Type: application/json
Content-Length: 39
Connection: keep-alive
{"status":400,"message":"Bad request"}

身份認(rèn)證集成

在發(fā)布API時(shí)，我們通常都會(huì)通過身份認(rèn)證來保護(hù)它們。NGINX Plus提供了幾種方法來保護(hù)API以及驗(yàn)證API客戶端。相關(guān)的具體信息可以參閱NGINX官方文檔中的IP address?based access control lists，digital certificate authentication以及HTTP Basic authentication部分。在本文中，我們將專注于適用于API的認(rèn)證方法。

API秘鑰認(rèn)證

API秘鑰是客戶端和API網(wǎng)關(guān)同時(shí)掌握其內(nèi)容的共享秘鑰。其本質(zhì)就是一個(gè)長度很長的復(fù)雜密碼，它通常作為一個(gè)長期憑證提供給API客戶端。創(chuàng)建API秘鑰的操作十分簡單，你只需要像下面一樣編碼一個(gè)隨機(jī)數(shù)即可。

$ openssl rand -base64 18 7B5zIqmRGXmrJTFmKa99vcit

現(xiàn)在回到頂層的API網(wǎng)關(guān)配置文件api_gateway.conf，可以看到第6行我們include了一個(gè)名為api_key.conf的文件，它包含著每個(gè)API客戶端的API秘鑰信息以及相匹配的客戶端名稱或相關(guān)描述。

map $http_apikey $api_client_name {
    default "";
    "7B5zIqmRGXmrJTFmKa99vcit" "client_one";
    "QzVV6y1EmQFbbxOfRCwyJs35" "client_two";
    "mGcjH8Fv6U9y3BVF9H3Ypb9T" "client_six";
}

可以看到API秘鑰被定義在上面展示的代碼塊當(dāng)中。其中的map指令接受了兩個(gè)參數(shù)。第一個(gè)參數(shù)定義了尋找API秘鑰的位置，這里我們通過獲取客戶端HTTP請(qǐng)求頭中的apikey作為變量$http_api_key接收。第二個(gè)參數(shù)創(chuàng)建了一個(gè)新變量$api_client_name并且將其與第一個(gè)參數(shù)即同行的API秘鑰相匹配。

此時(shí)，如果客戶端提供了API秘鑰7B5zIqmRGXmrJTFmKa99vcit是，變量$api_client_name會(huì)被設(shè)置為client_one。這個(gè)變量可以用于檢驗(yàn)通過身份驗(yàn)證的客戶端以及對(duì)日志的進(jìn)一步審計(jì)。

可以看到map塊的格式非常簡單，這使得我們可以很容易地將api_keys.conf的生成集成到自動(dòng)化的工作流當(dāng)中。之后可以在API的策略塊中完成API秘鑰的校驗(yàn)邏輯。

# 策略塊
#
location = /_warehouse {
    internal;
    set $api_name "Warehouse";  
    if ($http_apikey = "") {
        return 401; # Unauthorized (please authenticate)
    }
    if ($api_client_name = "") {
        return 403; # Forbidden (invalid API key)
    }
    proxy_pass http://$upstream$request_uri;
}

我們希望發(fā)送請(qǐng)求的客戶端都在它們的HTTP頭部中指定apikey內(nèi)容為客戶端持有的API秘鑰。如果沒有HTTP頭信息或者其中沒有apikey，我們將返回給客戶端401狀態(tài)碼要求其完成認(rèn)證。如果客戶端發(fā)送的API秘鑰不存在于api_keys.conf當(dāng)中，$api_client_name會(huì)被設(shè)置為默認(rèn)值即空字符串——此時(shí)我們將返回403狀態(tài)碼來告訴客戶端其認(rèn)證無效。

完成以上配置之后，Warehouse API現(xiàn)在已經(jīng)可以支持API秘鑰校驗(yàn)了。

$ curl https://api.example.com/api/warehouse/pricing/item001
{"status":401,"message":"Unauthorized"}
$ curl -H "apikey: thisIsInvalid" https://api.example.com/api/warehouse/pricing/item001
{"status":403,"message":"Forbidden"}
$ curl -H "apikey: 7B5zIqmRGXmrJTFmKa99vcit" https://api.example.com/api/warehouse/pricing/item001
{"sku":"item001","price":179.99}

JWT認(rèn)證

現(xiàn)在，JSON Web Token ( JWT )已經(jīng)越來越廣泛地被應(yīng)用于API認(rèn)證。不過要注意的是原生JWT支持是NGINX Plus才有的特性。關(guān)于如何啟用JWT支持可以參閱Authenticating API Clients with JWT and NGINX Plus。

總結(jié)

本文是部署NIGNX Plus作為API網(wǎng)關(guān)系列文章中的第一篇。本文中使用到的所有文件可以在我們的GitHub Gist repo上下載或查看。在本系列的下一篇文章中我們將探討更高級(jí)的用例以保護(hù)后端服務(wù)免受惡意或者非法操作的用戶的侵害。

問答  
如何用nginx編寫url重寫？
相關(guān)閱讀 
如何用Nginx快速搭建一個(gè)安全的微服務(wù)架構(gòu)?
Nginx 原理解析和配置摘要 
使用API網(wǎng)關(guān)構(gòu)建微服務(wù)

此文已由作者授權(quán)騰訊云+社區(qū)發(fā)布，原文鏈接：https://cloud.tencent.com/dev...

歡迎大家前往騰訊云+社區(qū)或關(guān)注云加社區(qū)微信公眾號(hào)（QcloudCommunity），第一時(shí)間獲取更多海量技術(shù)實(shí)踐干貨哦~

文章版權(quán)歸作者所有，未經(jīng)允許請(qǐng)勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。

轉(zhuǎn)載請(qǐng)注明本文地址：http://systransis.cn/yun/39989.html

發(fā)表評(píng)論

登陸后可評(píng)論

0條評(píng)論

awesome23

男|高級(jí)講師

我要關(guān)注我要私信

TA的文章

Postman接口測試工具

閱讀 2305·2021-09-30 09:47
??Python異常捕獲和處理??保姆式教學(xué)，代碼異常報(bào)錯(cuò)也能那么和諧且個(gè)性！

閱讀 2223·2021-09-26 09:55
如何在CentOS 8系統(tǒng)鏡像部署Memcached緩存工具？

閱讀 2954·2021-09-24 10:27
禁止eclipse校驗(yàn)JavaScript

閱讀 1543·2019-08-27 10:54
微信二次分享報(bào)錯(cuò)，invalid signature

閱讀 971·2019-08-26 13:40
開發(fā)中常用的JS知識(shí)點(diǎn)集錦

閱讀 2499·2019-08-26 13:24
Vue動(dòng)態(tài)加載異步組件

閱讀 2423·2019-08-26 13:22
react后臺(tái)獲取數(shù)據(jù)調(diào)用CallBack立即使用

閱讀 1735·2019-08-23 18:38

成人国产在线小视频_日韩寡妇人妻调教在线播放_色成人www永久在线观看_2018国产精品久久_亚洲欧美高清在线30p_亚洲少妇综合一区_黄色在线播放国产_亚洲另类技巧小说校园_国产主播xx日韩_a级毛片在线免费

資訊專欄INFORMATION COLUMN

上云采購季！| 2核2G4M爆款云服務(wù)器低至59元/年，更有多臺(tái)、長期優(yōu)惠，快來選購！

八步部署NGINX Plus API網(wǎng)關(guān)

相關(guān)文章

API網(wǎng)關(guān)如何實(shí)現(xiàn)對(duì)服務(wù)下線實(shí)時(shí)感知

**利用 NGINX 最大化 Python 性能，第一部分：Web 服務(wù)和緩存**

**利用 NGINX 最大化 Python 性能，第一部分：Web 服務(wù)和緩存**

API網(wǎng)關(guān)Kong-簡介

**微服務(wù)網(wǎng)關(guān)方案調(diào)研**

發(fā)表評(píng)論

0條評(píng)論

awesome23

男|高級(jí)講師

TA的文章

Postman接口測試工具

??Python異常捕獲和處理??保姆式教學(xué)，代碼異常報(bào)錯(cuò)也能那么和諧且個(gè)性！

如何在CentOS 8系統(tǒng)鏡像部署Memcached緩存工具？

禁止eclipse校驗(yàn)JavaScript

微信二次分享報(bào)錯(cuò)，invalid signature

開發(fā)中常用的JS知識(shí)點(diǎn)集錦

Vue動(dòng)態(tài)加載異步組件

react后臺(tái)獲取數(shù)據(jù)調(diào)用CallBack立即使用

最新活動(dòng)

資訊專欄INFORMATION COLUMN

上云采購季！| 2核2G4M爆款云服務(wù)器低至59元/年，更有多臺(tái)、長期優(yōu)惠，快來選購！

八步部署NGINX Plus API網(wǎng)關(guān)

相關(guān)文章

發(fā)表評(píng)論

0條評(píng)論

男|高級(jí)講師

TA的文章

最新活動(dòng)

上云采購季！| 2核2G4M爆款云服務(wù)器低至59元/年，更有多臺(tái)、長期優(yōu)惠，快來選購！