本文講述基于 OpenResty 的接口網(wǎng)關(guān)設(shè)計(jì)，主要談及接口網(wǎng)關(guān)的請(qǐng)求路由與安全認(rèn)證（IP 與 URI 白名單、加解密與驗(yàn)簽名流程等）這兩部分內(nèi)容，其中涉及到的 Nginx、OpenResty等相關(guān)內(nèi)容會(huì)作簡(jiǎn)單介紹。

〇、前言

筆者曾參與開發(fā)兩個(gè)接口網(wǎng)關(guān)的項(xiàng)目，一個(gè)是基于 Tomcat 的應(yīng)用提供的網(wǎng)關(guān)服務(wù)，另一個(gè)是基于 OpenResty 的 Nginx 應(yīng)用提供的網(wǎng)關(guān)服務(wù)。經(jīng)過兩個(gè)網(wǎng)關(guān)項(xiàng)目的開發(fā)，筆者在接口網(wǎng)關(guān)開發(fā)方面稍微積累了一些經(jīng)驗(yàn)，故在此把這些經(jīng)驗(yàn)分享出來一起交流學(xué)習(xí)。由于基于 OpenResty 的 Nginx 網(wǎng)關(guān)普遍被認(rèn)為是更優(yōu)的方案，故本文主要針對(duì)基于 OpenResty 的 Nginx 網(wǎng)關(guān)進(jìn)行講述。當(dāng)然，由于不同的并發(fā)數(shù)量級(jí)，不同的業(yè)務(wù)場(chǎng)景，接口網(wǎng)關(guān)的設(shè)計(jì)多種多樣，本文所述其中較為簡(jiǎn)單且輕量級(jí)的一種。

一、什么是接口網(wǎng)關(guān)

1.1 定位

接口網(wǎng)關(guān)，顧名思義，是企業(yè) IT 在系統(tǒng)邊界上提供給外部訪問內(nèi)部接口服務(wù)的統(tǒng)一入口。這里的外部可以指客戶端、瀏覽器或者第三方應(yīng)用等，在這種情況下，接口網(wǎng)關(guān)可以有多種定位：

• 提供后端服務(wù)面向 Web App 或者 Mobile App 的 APIGateway
• 作為開放平臺(tái)面向 Partner 的 OpenAPI
• …

在筆者的工作中，同樣把面向客戶端的網(wǎng)關(guān)稱作 APIGateway，把作為開放平臺(tái)提供給第三方服務(wù)的網(wǎng)關(guān)稱作 OpenApi。本文主要以 OpenApi 作為接口網(wǎng)關(guān)為例來講述。

1.2 功能

作為企業(yè) IT 系統(tǒng)的統(tǒng)一入口，接口網(wǎng)關(guān)可提供請(qǐng)求路由與組合、協(xié)議轉(zhuǎn)換、安全認(rèn)證、服務(wù)鑒權(quán)、流量控制與日志監(jiān)控等服務(wù)。在筆者的工作中，主要在接口網(wǎng)關(guān)上實(shí)現(xiàn)了請(qǐng)求路由與安全認(rèn)證的功能，題目中所說的“設(shè)計(jì)”，主要是指請(qǐng)求路由與安全認(rèn)證方面，暫不涉及流量控制或日志監(jiān)控等其他方面的設(shè)計(jì)。

二、為什么需要接口網(wǎng)關(guān)

正如上文所言，網(wǎng)關(guān)接口為企業(yè)應(yīng)用提供了豐富的功能，而筆者在工作中開發(fā)的接口網(wǎng)關(guān)主要提供請(qǐng)求路由與安全認(rèn)證的功能，那么在回答“為什么需要接口網(wǎng)關(guān)”的時(shí)候，需要對(duì)這兩者多加闡述。

2.1 請(qǐng)求路由

企業(yè)提供內(nèi)外兩網(wǎng)，在沒有接口網(wǎng)關(guān)時(shí)，提供外部服務(wù)的應(yīng)用需要部署在外網(wǎng)。隨著服務(wù)的增多，部署在外網(wǎng)的應(yīng)用越來越多，在服務(wù)的安全壓力與維護(hù)成本增大的情況下，需要一個(gè)統(tǒng)一的接口網(wǎng)關(guān)“隔離”內(nèi)外服務(wù)。企業(yè)提供的服務(wù)（無論內(nèi)部服務(wù)還是外部服務(wù)）均部署在內(nèi)網(wǎng)，而由部署在外網(wǎng)的網(wǎng)關(guān)接受請(qǐng)求，并路由到內(nèi)網(wǎng)服務(wù)。在這種情況下，既有利于對(duì)外屏蔽企業(yè)內(nèi)部服務(wù)部署細(xì)節(jié)，提供統(tǒng)一的服務(wù)訪問地址，又便于管理與維護(hù)內(nèi)外部服務(wù)接口，便于演進(jìn)與重構(gòu)服務(wù)。這是接口網(wǎng)關(guān)提供請(qǐng)求路由的作用。

2.2 安全認(rèn)證

在沒有接口網(wǎng)關(guān)時(shí)，企業(yè)對(duì)外服務(wù)直接由外部訪問，身份驗(yàn)證與數(shù)據(jù)加解密等工作都需要每一個(gè)對(duì)外服務(wù)本身去處理，增加了服務(wù)本不該有的職責(zé)，并且增加了服務(wù)開發(fā)的難度與工作量。實(shí)際在大多數(shù)情況下，可以將身份驗(yàn)證與數(shù)據(jù)加解密等安全工作可以從服務(wù)抽離，統(tǒng)一由接口網(wǎng)關(guān)負(fù)責(zé)處理。接口網(wǎng)關(guān)作為入口，對(duì)外驗(yàn)證調(diào)用方的 IP，身份以及接口訪問權(quán)限等，并且可以解密數(shù)據(jù)后再將請(qǐng)求路由到服務(wù)。這是接口網(wǎng)關(guān)提供安全認(rèn)證的功能。

以上是實(shí)際工作中涉及的為什么需要接口網(wǎng)關(guān)的其中兩個(gè)原因，當(dāng)然原因遠(yuǎn)不止此，有興趣的讀者可以閱讀其他文章，比如 《談API網(wǎng)關(guān)的背景、架構(gòu)以及落地方案》 或者 《微服務(wù)：從設(shè)計(jì)到部署》（英文原文：Microservices: From Design to Deployment）。接下來的章節(jié)我們開始探討如何開發(fā)接口網(wǎng)關(guān)。

三、如何開發(fā)接口網(wǎng)關(guān)

我們先看看工作中設(shè)計(jì)的提供請(qǐng)求路由與安全認(rèn)證功能的接口網(wǎng)關(guān)的架構(gòu)。

不過在介紹接口網(wǎng)關(guān)的設(shè)計(jì)之前，我們先來了解一下關(guān)于 Nginx 與 OpenResty 的基礎(chǔ)知識(shí)。

3.1 Nginx 與 OpenResty 簡(jiǎn)介

3.1.1 Nginx 簡(jiǎn)介

Nginx 是世界第二大 Web 服務(wù)器，僅次于 Apache，然而由于其極高的性能可處理海量的互聯(lián)網(wǎng)請(qǐng)求，現(xiàn)在已經(jīng)成為業(yè)界高性能 Web 服務(wù)器的代名詞。

它的主要特征是高性能、高擴(kuò)展性、高可靠性、低內(nèi)存消耗、單機(jī)支持 10 萬以上的并發(fā)連接，支持熱部署，以及使用最自由的 BSD 許可協(xié)議。其中，Nginx 可以處理高并發(fā)壓力下的并發(fā)請(qǐng)求的原因如下：

• 事件驅(qū)動(dòng)模型設(shè)計(jì)
• 全異步的網(wǎng)絡(luò) I/O 處理機(jī)制
• 極少的進(jìn)程切換
• 內(nèi)存消耗低，極度“壓榨”服務(wù)器硬件資源

除了基于事件驅(qū)動(dòng)的架構(gòu)使其支持百萬級(jí)的 TCP 連接，另外高度模塊化的設(shè)計(jì)和自由的許可證使其擁有非常多擴(kuò)展其功能的第三方模塊，也是它的重要特性。所以，后來才會(huì)有 OpenResty 的誕生。

我們看一個(gè) Nginx 作簡(jiǎn)單配置來提供服務(wù)的例子：

worker_processes 1;events { worker_connections 1024; } http { upstream backend { server 127.0.0.1:8080 } server { location / back { proxy_pass http://backend; } } }

上述配置文件中，分別在 event、http、server 以及 location 塊配置項(xiàng)中做了一些簡(jiǎn)單的配置，當(dāng)安裝完并啟動(dòng) Nginx 后（監(jiān)聽 80 端口），訪問到 /back 路徑下的請(qǐng)求會(huì)被轉(zhuǎn)發(fā)到本地 127.0.0.1:8080 服務(wù)上。

3.1.1 OpenResty 簡(jiǎn)介

根據(jù)官網(wǎng)定義，OpenResty 是一個(gè)通過 Lua 擴(kuò)展 Nginx 實(shí)現(xiàn)的可伸縮的 Web 平臺(tái)。其核心是基于 Nginx 一個(gè) C 模塊將 Lua 語言嵌入到 Nginx 服務(wù)器中，對(duì)外提供一套完整的 Lua Web 的 API，并透明支持非阻塞 I/O，提供協(xié)程 —— “輕量級(jí)線程”、定時(shí)器等，從而極大地降低了高性能服務(wù)端的開發(fā)難度和開發(fā)周期。

OpenResty 將兩個(gè)極為優(yōu)秀的組件 Nginx 與 Lua 進(jìn)行糅合，一方面保留了 Nginx 高性能 web 服務(wù)特征，另一方面有提供 Lua 特性在極少損失性能情況下便于業(yè)務(wù)功能的開發(fā)。根據(jù)官網(wǎng)介紹，OpenResty 非常便于用來搭建能夠處理超高并發(fā)、擴(kuò)展性極高的動(dòng)態(tài) Web 應(yīng)用、Web 服務(wù)和動(dòng)態(tài)網(wǎng)關(guān)。

我們也是因?yàn)?OpenResty 的這些特性，特別是它對(duì)搭建動(dòng)態(tài)網(wǎng)關(guān)的友好支持，才選擇了基于 OpenResty 來開發(fā)我們的接口網(wǎng)關(guān) —— APIGateway 與 OpenApi。

開發(fā)接口網(wǎng)關(guān)使用到的 OpenResty 一個(gè)重要知識(shí)：OpenResty 對(duì)于一個(gè)請(qǐng)求的處理流程。Nginx 把一個(gè)請(qǐng)求分為不同的階段，從而讓第三方模塊通過掛載行為在不同的階段來定制自己的行為；OpenResty 擁有同樣的特性，不過在不同階段掛載的是 Lua 腳本。下圖是基于《OpenResty 最佳實(shí)踐》原圖重繪而來：

從上圖可知，OpenResty 處理請(qǐng)求大致分為四個(gè)階段：

• 初始化階段（Initialization Phase）
• 重寫與訪問階段（Rewrite / Access Phase）
• 內(nèi)容生成階段（Content Phase）
• 日志記錄階段（Log Phase）

我們看一個(gè) OpenResty 作簡(jiǎn)單配置來提供服務(wù)的例子：

worker_processes 1;events { worker_connections 1024;}http { resolver 127.0.0.1; lua_package_path '$prefix/lua/?.lua;;'; init_by_lua_block { # ... } init_worker_by_lua_file lua/init_work_by_lua.lua; server { listen 80; location / { rewrite_by_lua_file lua/rewrite_by_lua.lua; access_by_lua_file lua/access_by_lua.lua; proxy_pass http://<url>; } }}

上述配置文件中，分別在 event、http、server 以及 location 塊配置項(xiàng)中做了一些簡(jiǎn)單的配置，當(dāng)安裝完并啟動(dòng) Nginx 后（監(jiān)聽 80 端口），首先執(zhí)行 init_by_lua_block、init_worker_by_lua_file 進(jìn)行初始化，接著接受請(qǐng)求，所有的請(qǐng)求都會(huì)匹配上 "/" 路徑，進(jìn)而執(zhí)行 rewrite_by_lua_file、access_by_lua_file進(jìn)行重寫與訪問，最后轉(zhuǎn)發(fā)請(qǐng)求到本地 127.0.0.1 服務(wù)上。

在實(shí)際的接口網(wǎng)關(guān)開發(fā)中，我們主要是使用到了 OpenResty 中初始化階段的 init_by_lua*、init_worker_by_lua*、重寫與訪問階段 的 rewrite_by_lua*、access_by_lua* 以及內(nèi)容生成階段 content_by_lua* 過程。

3.2 接口網(wǎng)關(guān)的架構(gòu)

這一節(jié)是本文的核心內(nèi)容，重點(diǎn)講述接口網(wǎng)關(guān)的架構(gòu)設(shè)計(jì)。如前文所述，本文主要以 OpenApi 為例來講述接口網(wǎng)關(guān)的架構(gòu)設(shè)計(jì)。先看圖：

下面我們來一步步來分析架構(gòu)圖的各個(gè)部分，首先是兩層的 HAProxy 。

3.2.1 兩層 HAProxy 代理

根據(jù)維基百科定義，HAProxy 是一個(gè)使用 C 語言編寫的自由及開放源代碼軟件，其提供高可用性、負(fù)載均衡，以及基于 TCP 和 HTTP 的應(yīng)用程序代理。

如圖所示，隔離的內(nèi)網(wǎng)與外網(wǎng)上分別提供了 HAProxy 代理， 外層暫且稱為 HAProxy internet ，內(nèi)層稱為 HAProxy internal。外層暴露于外網(wǎng)中，使用統(tǒng)一地址如 http://openapi.company.com 來接受外部請(qǐng)求（這里指第三方的請(qǐng)求）；中間是基于 OpenResty 的 Nginx 網(wǎng)關(guān)層，外部請(qǐng)求經(jīng)過網(wǎng)關(guān)后通過 HAProxy internal 轉(zhuǎn)發(fā)到內(nèi)網(wǎng)的服務(wù)上，內(nèi)網(wǎng)服務(wù)遵循 Restful 風(fēng)格，網(wǎng)關(guān)轉(zhuǎn)發(fā)到內(nèi)網(wǎng)的地址由接口網(wǎng)關(guān)控制。

然而，目前的代理架構(gòu)受到了當(dāng)前整體架構(gòu)的約束，實(shí)際上兩層的 HAProxy 代理并不是必需的。

• 對(duì)于外層 HAProxy internet，由于我們使用了與 HAProxy 緊密結(jié)合的 Openshift 架構(gòu)，所以多了一層 HAProxy 的轉(zhuǎn)發(fā)；一般情況下，基于 OpenResty 的 Nginx 網(wǎng)關(guān)層可以直接在外網(wǎng)上提供服務(wù)。
• 對(duì)于內(nèi)層的 HAProxy internal，由于我們當(dāng)前還沒有實(shí)現(xiàn)服務(wù)治理，所以需要內(nèi)層的 HAProxy internal 進(jìn)行一層轉(zhuǎn)發(fā)；當(dāng)實(shí)現(xiàn)了服務(wù)治理，可以消除內(nèi)層 HAProxy 代理，減少轉(zhuǎn)發(fā)消耗。

在我們當(dāng)前的系統(tǒng)量級(jí)下，這兩層 HAProxy 轉(zhuǎn)發(fā)消耗非常小可以被接受，所以調(diào)整架構(gòu)的優(yōu)先級(jí)還不高，以后再慢慢演進(jìn)。

3.2.2 接口網(wǎng)關(guān)

接下來這一節(jié)是最為重點(diǎn)的接口網(wǎng)關(guān)的設(shè)計(jì)。接口網(wǎng)關(guān)主要利用前文所述的 OpenResty 執(zhí)行階段對(duì)請(qǐng)求與響應(yīng)進(jìn)行流程處理，包括接口地址的重寫，IP 與資源白名單的控制，請(qǐng)求的解密與驗(yàn)簽，請(qǐng)求的路由以及響應(yīng)的簽名與加密等。

這里分成主流程，配置服務(wù)，安全服務(wù)三部分進(jìn)行講述。

3.2.2.1 主流程設(shè)計(jì)

主流程是網(wǎng)關(guān)的核心，是請(qǐng)求處理的控制中心；它是通過 OpenResty 的 Lua 腳本處理流程來實(shí)現(xiàn)對(duì)請(qǐng)求的處理。

A. 主流程

1. 在 OpenResty 服務(wù)啟動(dòng)之后，首先通過 init_by_lua_block 階段初始化常量（包括調(diào)用配置服務(wù)以及安全服務(wù)所需的主機(jī)地址、端口、URL 地址等）、引入依賴（包括常用的 http 以及 cjson 依賴等）等作為全局使用；
2. 接著通過 init_worker_by_lua_file 階段設(shè)置定時(shí)任務(wù)調(diào)用內(nèi)網(wǎng)配置服務(wù)來緩存配置，為處理第三方的請(qǐng)求做準(zhǔn)備，其中加載的配置可供 URL 重寫（即接口映射）、IP 以及資源（URI）白名單限制、請(qǐng)求的解密驗(yàn)簽以及響應(yīng)的簽名加密使用，詳情查看配置服務(wù)一節(jié)。
3. 當(dāng)?shù)谌秸?qǐng)求通過 HAProxy Internet 進(jìn)入到網(wǎng)關(guān)后，根據(jù)配置通過 rewrite_by_lua_file 階段做 URL 重寫（即接口映射）。

• 服務(wù)接口 URL 發(fā)生變更，為了兼容舊的第三方調(diào)用，需要重寫第三方請(qǐng)求 URL 到新服務(wù)接口上
• Restful 接口的 Path Variable 在 Nginx 環(huán)境與在 Tomcat 環(huán)境上正則匹配的差異
• 需要重寫的原因可能有：
• URL 重寫后，通過 rewrite_by_lua_file 進(jìn)入訪問控制階段，此時(shí)根據(jù)授權(quán)的第三方 IP 白名單列表，授權(quán)予第三方的開放接口列表，校驗(yàn)請(qǐng)求的 IP 以及 URL。
• IP 與 URI 校驗(yàn)通過后，同樣在 rewrite_by_lua_file 階段根據(jù)配置調(diào)用內(nèi)網(wǎng)的安全服務(wù)進(jìn)行請(qǐng)求的解密與驗(yàn)簽，獲取明文。
• 在 content_by_lua_file 階段通過 ngx.location.capture 將原請(qǐng)求頭部信息以及參數(shù)等信息封裝到子請(qǐng)求中，借助自請(qǐng)求轉(zhuǎn)發(fā)原請(qǐng)求到開發(fā)接口服務(wù)中。
• 注意：根據(jù)官方文檔說明，ngx.location.capture 發(fā)送子請(qǐng)求會(huì)緩存響應(yīng)在內(nèi)存中，直到整個(gè)請(qǐng)求處理結(jié)束。那么，當(dāng)有響應(yīng)報(bào)文特別長(zhǎng)或者請(qǐng)求并發(fā)非常高時(shí)，需要使用 cosocket 來替代 ngx.location.capture，避免因內(nèi)存不足造成網(wǎng)關(guān)服務(wù)失效。
• 同樣在 content_by_lua_file 階段根據(jù)配置調(diào)用安全服務(wù)進(jìn)行響應(yīng)的簽名與加密，獲取簽名與密文返回給第三方。
• B. 文件結(jié)構(gòu)
• 項(xiàng)目的大致結(jié)構(gòu)如下，主要分為 Lua 代碼目錄和環(huán)境配置目錄。

--openapi --lua --access_by_lua.lua --cache_management.lua --content_by_lua.lua --init_work_by_lua.lua --rewrite_by_lua.lua --security.lua --prod --Dockerfile --nginx.conf --sit --Dockerfile --nginx.conf --README.md

•  
• C. 主流程在 conf 中的配置

# Nginx worker 進(jìn)程個(gè)數(shù)，直接影響性能。# 如果確認(rèn)不會(huì)出現(xiàn)阻塞式調(diào)用，那么有多少 CPU 內(nèi)核設(shè)置多少個(gè)進(jìn)程# 如果有可能出現(xiàn)阻塞式調(diào)用，需要配置多一些進(jìn)程worker_processes 1; events { worker_connections 1024;}http { # 內(nèi)網(wǎng)地址 resolver xxx.x.x.xxx yyy.y.y.yyy; # 日志格式配置 log_format graylog2_format '$remote_addr - $remote_user [$time_local] "$request" ' '$status $body_bytes_sent "$http_referer" ' '"$http_user_agent" "$http_x_forwarded_for" ' '<msec=$msec|connection=$connection|connection_requests=$connection_requests|millis=$request_time>'; # 日志路徑配置 access_log syslog:server=<host>:<port> graylog2_format; error_log syslog:server=<host>:<port> warn; # 配置 Lua 包地址 lua_package_path '$prefix/lua/?.lua;;'; init_by_lua_block { # 引入依賴（可能會(huì)污染全局環(huán)境，待研究） http = require "resty.http" cjson = require "cjson" cache_management = require "cache_management" ... } # 設(shè)置定時(shí)任務(wù)緩存配置，及上面的 cache_management 模塊 init_worker_by_lua_file lua/init_work_by_lua.lua; # Nginx Web 服務(wù)配置 server { listen 80; # ngx.location.capture 子請(qǐng)求代理，轉(zhuǎn)發(fā)原請(qǐng)求到接口服務(wù) location = /ngx_proxy/ { internal; proxy_set_header Accept-Encoding ''; proxy_pass http://$context$http_host_suffix$proxy_uri; } # 匹配所有請(qǐng)求，進(jìn)行 URL 重寫、訪問控制、轉(zhuǎn)發(fā)請(qǐng)求以及響應(yīng)處理（各階段的處理在此配置）。 location / { set $context ''; ... rewrite_by_lua_file lua/rewrite_by_lua.lua; access_by_lua_file lua/access_by_lua.lua; content_by_lua_file lua/content_by_lua.lua; } }}

•  
• D. URL 規(guī)范
• 內(nèi)網(wǎng)服務(wù)遵循的 URL 格式為 http://<host>:<port>/<context>/path/to/your/api，應(yīng)用上下文根緊跟在 <host>:<port> 之后，以便統(tǒng)一獲取來找到配置。比如：http://172.0.8.177:8080/user/users/{uid}/info，其中 user 為應(yīng)用上下文根，緊跟在 172.0.8.177:8080 之后。
• E. 樣例
• 內(nèi)網(wǎng)用戶信息服務(wù)由原來的 API：/user/users/{uid}/info 提供，后來遷移至 API：/user/users/{uid}/user-info，當(dāng)?shù)谌?CampA (IP 為 172.0.1.172) 發(fā)起 GET 請(qǐng)求時(shí)，請(qǐng)求 URL 為 http://openapi.company.com/user/users/27/info?thirdparty=CampA&cp=fj375x...sign=abxuos8nb...。

1. 初始化常量和依賴等
2. 通過 CampA 與 user Context 獲取第三方配置
3. HAProxy Internet 接收請(qǐng)求發(fā)到 OpenApi 接口網(wǎng)關(guān)，OpenApi 把 /user/users/27/info URI 重寫為 /user/users/27/user-info/
4. 校驗(yàn)第三方請(qǐng)求 IP，在 IP 白名單中，校驗(yàn)通過；校驗(yàn) URI /user/users/27/user-info 在授權(quán)的 URI 中，校驗(yàn)通過
5. 調(diào)用安全服務(wù)對(duì)請(qǐng)求進(jìn)行解密與驗(yàn)簽，解密成功，驗(yàn)簽通過，獲取明文
6. 將擁有明文的請(qǐng)求轉(zhuǎn)發(fā)到開放接口服務(wù)
7. 獲取響應(yīng)，調(diào)用安全服務(wù)對(duì)響應(yīng)報(bào)文進(jìn)行簽名與加密，返回給第三方 CampA。

• 3.2.2.2 配置服務(wù)設(shè)計(jì)

•  
• A. 數(shù)據(jù)庫(kù)表設(shè)計(jì)
• openapi_thirdparty_config

•  
• openapi_api_config

•  
• openapi_api_mapping

•  
• B. 配置服務(wù)接口響應(yīng)

{ # 接口映射配置 "apiMapping":{ "$context":{ "$fromApi":"$toApi" } }, # 接口白名單配置、加解密配置 "apiConfig":{ "$channel $context":{ "$httpMethod $uri":{ "reqNeedDecrypt":false, "respNeedEncrypt":false } } }, # IP 白名單配置，驗(yàn)簽名配置 "channelConfig":{ "$channel":{ ips:{ "$ip":1 }, "reqNeedVerifySign":false, "respNeedSign":false, "needCheckIp":false } }}

• 3.2.2.3 安全服務(wù)設(shè)計(jì)
• 為了保證請(qǐng)求或響應(yīng)的完整性、以及請(qǐng)求或響應(yīng)來源的合法性，雙方傳輸需要進(jìn)行簽名；另外，由于可能開放接口的請(qǐng)求或響應(yīng)會(huì)包含敏感信息，需要進(jìn)行加密傳輸。這里的安全服務(wù)就是指請(qǐng)求的解密與驗(yàn)簽和響應(yīng)的簽名與加密服務(wù)。

•  
• A. 算法約定
• 對(duì)稱加密算法：3DES（DESede/ECB/PKCS5Padding）
• 非對(duì)稱加密算法：RSA（RSA/ECB/PKCS1Padding）
• 簽名算法：SHA1WithRSA
• B. 公鑰約定
• 雙方預(yù)先交換 RSA 公鑰
• 雙方公鑰編碼方式：UTF-8 編碼的 Base64String
• 雙方進(jìn)行加解密與驗(yàn)簽名可使用同一把 RSA 公私鑰或者分別使用各自的公私鑰，雙方約定即可
• C. 第三方請(qǐng)求流程示意

•  
• 其中，添加統(tǒng)一參數(shù)為必選步驟，請(qǐng)求簽名、請(qǐng)求加密、響應(yīng)解密、以及響應(yīng)驗(yàn)簽都是可選步驟。
• 無論是 GET、POST 或者其他方式的請(qǐng)求，第三方在訪問平臺(tái)開放接口前，都需要添加統(tǒng)一參數(shù)到 request parameter 中
• 統(tǒng)一參數(shù)包括第三方應(yīng)用名、請(qǐng)求時(shí)間戳、隨機(jī)不重復(fù)字符串 nonce 等
• 驗(yàn)簽名屬于應(yīng)用維度 —— 針對(duì)應(yīng)用做驗(yàn)簽名（比如：按照約定需要對(duì)第三方應(yīng)用 A 進(jìn)行驗(yàn)簽，則應(yīng)用 A 訪問數(shù)禾任何接口都需要簽名）
• 加解密屬于接口維度 —— 針對(duì)接口做加解密（比如：同一個(gè)第三方訪問 A 接口需要加密，而訪問 B 接口可以不需加密）
• D. 加解密示意（以第三方請(qǐng)求為例）

•  
• E. 驗(yàn)簽名示意（以第三方請(qǐng)求為例）

•  
• 3.2.3 架構(gòu)總結(jié)
• 由于 Nginx 與 Lua 本身杰出的性能，在當(dāng)前的系統(tǒng)量級(jí)與整體 IT 架構(gòu)下，我們使用這樣的接口網(wǎng)關(guān)架構(gòu)已經(jīng)可以支撐較大的并發(fā)請(qǐng)求。在最后的這一節(jié)，我們不妨回顧一下前文講述的接口網(wǎng)關(guān)架構(gòu)，看看目前性能上仍存在著的兩個(gè)主要待改進(jìn)的地方。

1. 兩層 HAProxy 代理：在使用更優(yōu)產(chǎn)品替代 Openshift 架構(gòu)的情況下，直接部署接口網(wǎng)關(guān)到公網(wǎng)，可消除外層 HAProxy 代理；在實(shí)現(xiàn)服務(wù)治理的情況下，由接口網(wǎng)關(guān)直接轉(zhuǎn)發(fā)請(qǐng)求到服務(wù)，可消除內(nèi)層 HAProxy 代理。
2. 安全服務(wù)性能：加解密驗(yàn)簽名等安全服務(wù)是以內(nèi)部服務(wù)的方式提供給接口網(wǎng)關(guān)，而且使用了性能不太好的 ngx.location.capture 轉(zhuǎn)發(fā)原請(qǐng)求，在系統(tǒng)量級(jí)增大后會(huì)遇到性能瓶頸，可通過使用高性能的 Lua 腳本在接口網(wǎng)關(guān)層提供安全服務(wù)，從而提升安全服務(wù)性能。

• 除了以上主要的兩點(diǎn)，隨著系統(tǒng)量級(jí)的提升與整體 IT 架構(gòu)的演進(jìn)，接口網(wǎng)關(guān)的架構(gòu)也會(huì)隨之調(diào)整和演進(jìn)，在各個(gè)方面都盡可能地優(yōu)化性能，以適應(yīng)更大系統(tǒng)量級(jí)的需求。