通過(guò)對(duì)網(wǎng)關(guān)設(shè)計(jì)的介紹來(lái)簡(jiǎn)單總結(jié)一下OpenResty的相關(guān)知識(shí)點(diǎn)

前言

希望通過(guò)對(duì)網(wǎng)關(guān)設(shè)計(jì)的介紹來(lái)簡(jiǎn)單總結(jié)一下 OpenResty 的相關(guān)知識(shí)點(diǎn)，爭(zhēng)取讓大家對(duì) OpenResty 這種高性能 Web 平臺(tái)有一個(gè)比較全面的了解。本文會(huì)從以下幾個(gè)方面來(lái)講解。

網(wǎng)關(guān)的作用

接入層網(wǎng)關(guān)架構(gòu)設(shè)計(jì)與實(shí)現(xiàn)

技術(shù)選型

OpenResty 原理剖析

網(wǎng)關(guān)的作用

網(wǎng)關(guān)作為所有請(qǐng)求的流量入口，主要承擔(dān)著安全，限流，熔斷降級(jí)，監(jiān)控，日志，風(fēng)控，鑒權(quán)等功能，網(wǎng)關(guān)主要有兩種類型

一種是接入層網(wǎng)關(guān)（access gateway），主要負(fù)責(zé)路由，WAF（防止SQL Injection, XSS, 路徑遍歷, 竊取敏感數(shù)據(jù),CC攻擊等），限流，日志，緩存等，這一層的網(wǎng)關(guān)主要承載著將請(qǐng)求路由到各個(gè)應(yīng)用層網(wǎng)關(guān)的功能

另一種是應(yīng)用層網(wǎng)關(guān)，比如現(xiàn)在流行的微服務(wù)，各個(gè)服務(wù)可能是用不同的語(yǔ)言寫(xiě)的，如 PHP，Java 等，那么接入層就要將請(qǐng)求路由到相應(yīng)的應(yīng)用層集群，再由相應(yīng)的應(yīng)用層網(wǎng)關(guān)進(jìn)行鑒權(quán)等處理，處理完之后再調(diào)用相應(yīng)的微服務(wù)進(jìn)行處理，應(yīng)用層網(wǎng)關(guān)也起著路由，超時(shí)，重試，熔斷等功能。

目前市面上比較流行的系統(tǒng)架構(gòu)如下

可以看到接入層網(wǎng)關(guān)承載著公司的所有流量，對(duì)性能有很高的要求，它的設(shè)計(jì)決定著整個(gè)系統(tǒng)的上限。所以我們今天主要談?wù)劷尤雽泳W(wǎng)關(guān)的設(shè)計(jì)。

接入層網(wǎng)關(guān)架構(gòu)設(shè)計(jì)與實(shí)現(xiàn)

首先我們要明白接入層網(wǎng)關(guān)的核心功能是：「根據(jù)路由規(guī)則將請(qǐng)求分發(fā)到對(duì)應(yīng)的后端集群」，所以要實(shí)現(xiàn)如下幾個(gè)功能模型 。

1、 路由：根據(jù)請(qǐng)求的 host, url 等規(guī)則轉(zhuǎn)發(fā)到指定的上游（相應(yīng)的后端集群） 2、 路由策略插件化：這是網(wǎng)關(guān)的「靈魂所在」，路由中會(huì)有身份認(rèn)證，限流限速，安全防護(hù)（如 IP 黑名單，refer異常，UA異常，需第一時(shí)間拒絕）等規(guī)則，這些規(guī)則以插件的形式互相組合起來(lái)以便只對(duì)某一類的請(qǐng)求生效，每個(gè)插件都即插即用，互不影響，這些插件應(yīng)該是「動(dòng)態(tài)可配置」的，動(dòng)態(tài)生效的（無(wú)須重啟服務(wù)），為啥要可動(dòng)態(tài)可配置呢，因?yàn)槊總€(gè)請(qǐng)求對(duì)應(yīng)的路由邏輯，限流規(guī)則，最終請(qǐng)求的后端集群等規(guī)則是不一樣的

如圖示，兩個(gè)請(qǐng)求對(duì)應(yīng)的路由規(guī)則是不一樣的，它們對(duì)應(yīng)的路由規(guī)則（限流，rewrite）等通過(guò)各個(gè)規(guī)則插件組合在一起，可以看到，光兩個(gè)請(qǐng)求 url 的路由規(guī)則就有挺多的，如果一個(gè)系統(tǒng)大到一定程度，url 會(huì)有不少，就會(huì)有不少規(guī)則，這樣每個(gè)請(qǐng)求的規(guī)則就必須「可配置化」，「動(dòng)態(tài)化」，最好能在管理端集中控制，統(tǒng)一下發(fā)。

3、后端集群的動(dòng)態(tài)變更

路由規(guī)則的應(yīng)用是為了確定某一類請(qǐng)求經(jīng)過(guò)這些規(guī)則后最終到達(dá)哪一個(gè)集群，而我們知道請(qǐng)求肯定是要打到某一臺(tái)集群的 ip 上的，而機(jī)器的擴(kuò)縮容其實(shí)是比較常見(jiàn)的，所以必須支持動(dòng)態(tài)變更，總不能我每次上下線機(jī)器的時(shí)候都要重啟系統(tǒng)讓它生效吧。

4、監(jiān)控統(tǒng)計(jì)，請(qǐng)求量、錯(cuò)誤率統(tǒng)計(jì)等等

這個(gè)比較好理解，在接入層作所有流量的請(qǐng)求，錯(cuò)誤統(tǒng)計(jì)，便于打點(diǎn)，告警，分析。

要實(shí)現(xiàn)這些需求就必須對(duì)我們采用的技術(shù)：OpenResty 有比較詳細(xì)的了解，所以下文會(huì)簡(jiǎn)單介紹一下 OpenResty 的知識(shí)點(diǎn)。

技術(shù)選型

有人可能第一眼想到用 Nginx,沒(méi)錯(cuò)，由于 Nginx 采用了 epoll 模型（非阻塞 IO 模型），確實(shí)能滿足大多數(shù)場(chǎng)景的需求（經(jīng)過(guò)優(yōu)化 100 w + 的并發(fā)數(shù)不是問(wèn)題），但是 Nginx 更適合作為靜態(tài)的 Web 服務(wù)器，因?yàn)閷?duì)于 Nginx 來(lái)說(shuō)，如果發(fā)生任何變化，都需要修改磁盤(pán)上的配置，然后重新加載才能生效，它并沒(méi)有提供 API 來(lái)控制運(yùn)行時(shí)的行為，而如上文所述，動(dòng)態(tài)化是接入層網(wǎng)關(guān)非常重要的一個(gè)功能。所以經(jīng)過(guò)一番調(diào)研，我們選擇了 OpenResty，啥是 OpenResty 呢，來(lái)看下官網(wǎng)的定義：

?

OpenResty 是一個(gè)基于 Nginx 與 Lua 的高性能 Web 平臺(tái)，其內(nèi)部集成了大量精良的 Lua 庫(kù)、第三方模塊以及大多數(shù)的依賴項(xiàng)。用于方便地搭建能夠處理超高并發(fā)、擴(kuò)展性極高的動(dòng)態(tài) Web 應(yīng)用、Web 服務(wù)和動(dòng)態(tài)網(wǎng)關(guān)。OpenResty 的目標(biāo)是讓你的Web服務(wù)直接跑在 Nginx 服務(wù)內(nèi)部，充分利用 Nginx 的非阻塞 I/O 模型，不僅僅對(duì) HTTP 客戶端請(qǐng)求,甚至于對(duì)遠(yuǎn)程后端諸如 MySQL、PostgreSQL、Memcached 以及 Redis 等都進(jìn)行一致的高性能響應(yīng)。

?

可以簡(jiǎn)單理解為，OpenResty = Nginx + Lua, 通過(guò) Lua 擴(kuò)展 Nginx 實(shí)現(xiàn)的可伸縮的 Web 平臺(tái) 。它利用了 Nginx 的高性能，又在其基礎(chǔ)上添加了 Lua 的腳本語(yǔ)言來(lái)讓 Nginx 也具有了動(dòng)態(tài)的特性。通過(guò) OpenResty 中 lua-Nginx-module 模塊中提供的 Lua API，我們可以動(dòng)態(tài)地控制路由、上游、SSL 證書(shū)、請(qǐng)求、響應(yīng)等。甚至可以在不重啟 OpenResty 的前提下，修改業(yè)務(wù)的處理邏輯，并不局限于 OpenResty 提供的 Lua API。

關(guān)于靜態(tài)和動(dòng)態(tài)有一個(gè)很合適的類比：如果把 Web 服務(wù)器當(dāng)做是一個(gè)正在高速公路上飛馳的汽車，Nginx 需要停車才能更換輪胎，更換車漆顏色，而 OpenResty 中可以邊跑邊換輪胎，更換車漆，甚至更換發(fā)動(dòng)機(jī)，直接讓普通的汽車變成超跑！

除了以上的動(dòng)態(tài)性，還有兩個(gè)特性讓 OpenResty 獨(dú)出一格。

「1.詳盡的文檔和測(cè)試用例」

作為開(kāi)源項(xiàng)目，文檔和測(cè)試毫無(wú)疑問(wèn)是其是否靠譜的關(guān)鍵，它的文檔非常詳細(xì)，作者把每個(gè)注意的點(diǎn)都寫(xiě)在文檔上了，多數(shù)時(shí)候只要看文檔即可，每一個(gè)測(cè)試案例都包含完整的 Nginx 配置和 lua 代碼。以及測(cè)試的輸入數(shù)據(jù)和預(yù)期的輸出數(shù)據(jù)。

「2.同步非阻塞」

OpenResty 在誕生之初就支持了協(xié)程，并且基于此實(shí)現(xiàn)了同步非阻塞的編程模型。

「畫(huà)外音：協(xié)程（coroutine）我們可以將它看成一個(gè)用戶態(tài)的線程，只不過(guò)這個(gè)線程是我們自己調(diào)度的，而且不同協(xié)程的切換不需要陷入內(nèi)核態(tài)，效率比較高。（一般我們說(shuō)的線程是要指內(nèi)核態(tài)線程，由內(nèi)核調(diào)度，需要從用戶空間陷入內(nèi)核空間，相比協(xié)程，對(duì)性能會(huì)有不小的影響）」

啥是同步非阻塞呢。假設(shè)有以下兩個(gè)兩行代碼：

localres,err=query-mysql(sql) localvalue,err=query-redis(key)

「同步」：必須執(zhí)行完查詢 mysql，才能執(zhí)行下面的 redis 查詢，如果不等 mysql 執(zhí)行完成就能執(zhí)行 redis 則是異步。

「阻塞」：假設(shè)執(zhí)行 sql 語(yǔ)句需要 1s，如果在這 1s 內(nèi)，CPU 只能干等著不能做其它任何事，那就是阻塞，如果在 sql 執(zhí)行期間可以做其他事（注意由于是同步的，所以不能執(zhí)行以下的 redis 查詢），則是非阻塞。

同步關(guān)注的是語(yǔ)句的先后執(zhí)行順序，如果上一個(gè)語(yǔ)句必須執(zhí)行完才能執(zhí)行下一個(gè)語(yǔ)句就是同步，如果不是，就是異步，阻塞關(guān)注的是線程是 CPU 是否需要在 IO 期間干等著，如果在 IO（或其他耗時(shí)操作期間）期間可以做其他事，那就是非阻塞，不能動(dòng)，則是阻塞。

那么 OpenResty 的工作原理是怎樣的呢，又是如何實(shí)現(xiàn)同步非阻塞的呢。

OpenResty 原理剖析

工作原理剖析

由于 OpenResty 基于 Nginx 實(shí)現(xiàn)的，我們先來(lái)看看 Nginx 的工作原理

Nginx 啟動(dòng)后，會(huì)有一個(gè) master 進(jìn)程和多個(gè) worker 進(jìn)程 ， master 進(jìn)程接受管理員的信號(hào)量（如 Nginx -s reload, -s stop）來(lái)管理 worker 進(jìn)程，master 本身并不接收 client 的請(qǐng)求，主要由 worker 進(jìn)程來(lái)接收請(qǐng)求，不同于 apache 的每個(gè)請(qǐng)求會(huì)占用一個(gè)線程，且是同步IO，Nginx 是異步非阻塞的，每個(gè) worker 可以同時(shí)處理的請(qǐng)求數(shù)只受限于內(nèi)存大小，這里就要簡(jiǎn)單地了解一下 nginx 采用的 epoll 模型：

epoll 采用多路復(fù)用模型，即同一時(shí)間雖然可能會(huì)有多個(gè)請(qǐng)求進(jìn)來(lái)， 但只會(huì)用一個(gè)線程去監(jiān)視，然后哪個(gè)請(qǐng)求數(shù)據(jù)準(zhǔn)備好了，就調(diào)用相應(yīng)的線程去處理，就像圖中所示，如同撥開(kāi)關(guān)一樣，同一時(shí)間只有一個(gè)線程在處理， Nginx 底層就是用的 epoll ，基于事件驅(qū)動(dòng)模型，每個(gè)請(qǐng)求進(jìn)來(lái)注冊(cè)事件并注冊(cè) callback 回調(diào)函數(shù)，等數(shù)據(jù)準(zhǔn)入好了，就調(diào)用回調(diào)函數(shù)進(jìn)行處理，它是異步非阻塞的，所以性能很高。

打個(gè)簡(jiǎn)單的比方，我們都有訂票的經(jīng)驗(yàn)，當(dāng)我們委托酒店訂票時(shí)，接待員會(huì)先把我們的電話號(hào)碼和相關(guān)信息等記下來(lái)（注冊(cè)事件），掛斷電話后接待員在操作期間我們就可以去做其他事了（非阻塞），當(dāng)接待員把手續(xù)搞好后會(huì)主動(dòng)打電話給我們通知我們票訂好了（回調(diào)）。

worker 進(jìn)程是從 master fork 出來(lái)的，這意味著 worker 進(jìn)程之間是互相獨(dú)立的，這樣不同 worker 進(jìn)程之間處理并發(fā)請(qǐng)求幾乎沒(méi)有同步鎖的限制，好處就是一個(gè) worker 進(jìn)程掛了，不會(huì)影響其他進(jìn)程，我們一般把 worker 數(shù)量設(shè)置成和 CPU 的個(gè)數(shù)，這樣可以減少不必要的 CPU 切換，提升性能，每個(gè) worker 都是單線程執(zhí)行的。那么 LuaJIT 在 OpenResty 架構(gòu)中的位置是怎樣的呢。

首先啟動(dòng)的 master 進(jìn)程帶有 LuaJIT 的機(jī)虛擬，而 worker 進(jìn)程是從 master 進(jìn)程 fork 出來(lái)的，在 worker 內(nèi)進(jìn)程的工作主要由 Lua 協(xié)程來(lái)完成，也就是說(shuō)在同一個(gè) worker 內(nèi)的所有協(xié)程，都會(huì)共享這個(gè) LuaJIT 虛擬機(jī)，每個(gè) worker 進(jìn)程里 lua 的執(zhí)行也是在這個(gè)虛擬機(jī)中完成的。

同一個(gè)時(shí)間點(diǎn)，worker 進(jìn)程只能處理一個(gè)用戶請(qǐng)求，也就是說(shuō)只有一個(gè) lua 協(xié)程在運(yùn)行，那為啥 OpenResty 能支持百萬(wàn)并發(fā)請(qǐng)求呢，這就需要了解 Lua 協(xié)程與 Nginx 事件機(jī)制是如何配合的了。

如圖示，當(dāng)用 Lua 調(diào)用查詢 MySQL 或 網(wǎng)絡(luò) IO 時(shí)，虛擬機(jī)會(huì)調(diào)用 Lua 協(xié)程的 yield 把自己掛起，在 Nginx 中注冊(cè)回調(diào)，此時(shí) worker 就可以處理另外的請(qǐng)求了（非阻塞），等到 IO 事件處理完了， Nginx 就會(huì)調(diào)用 resume 來(lái)喚醒 lua 協(xié)程。

事實(shí)上，由 OpenResty 提供的所有 API，都是非阻塞的，下文提到的與 MySQL，Redis 等交互，都是非阻塞的，所以性能很高。

OpenResty 請(qǐng)求生命周期

Nginx 的每個(gè)請(qǐng)求有 11 個(gè)階段，OpenResty 也有11 個(gè) *_by_lua 的指令，如下圖示:

各個(gè)階段 *_by_lua 的解釋如下

set_by_lua：設(shè)置變量； rewrite_by_lua：轉(zhuǎn)發(fā)、重定向等； access_by_lua：準(zhǔn)入、權(quán)限等； content_by_lua：生成返回內(nèi)容； header_filter_by_lua：應(yīng)答頭過(guò)濾處理； body_filter_by_lua：應(yīng)答體過(guò)濾處理； log_by_lua：日志記錄。

這樣分階段有啥好處呢，假設(shè)你原來(lái)的 API 請(qǐng)求都是明文的

# 明文協(xié)議版本 location /request { content_by_lua '...'; # 處理請(qǐng)求 }

現(xiàn)在需要對(duì)其加上加密和解密的機(jī)制，只需要在 access 階段解密， 在 body filter 階段加密即可，原來(lái) content 的邏輯無(wú)需做任務(wù)改動(dòng)，有效實(shí)現(xiàn)了代碼的解藕。

# 加密協(xié)議版本 location /request { access_by_lua '...'; # 請(qǐng)求體解密 content_by_lua '...'; # 處理請(qǐng)求，不需要關(guān)心通信協(xié)議 body_filter_by_lua '...'; # 應(yīng)答體加密 }

再比如我們不是要要上文提到網(wǎng)關(guān)的核心功能之一不是要監(jiān)控日志嗎，就可以統(tǒng)一在 log_by_lua 上報(bào)日志，不影響其他階段的邏輯。

worker 間共享數(shù)據(jù)利器: shared dict

worker 既然是互相獨(dú)立的進(jìn)程，就需要考慮其共享數(shù)據(jù)的問(wèn)題， OpenResty 提供了一種高效的數(shù)據(jù)結(jié)構(gòu): shared dict ,可以實(shí)現(xiàn)在 worker 間共享數(shù)據(jù)，shared dict 對(duì)外提供了 20 多個(gè) Lua API，都是原子操作的，避免了高并發(fā)下的競(jìng)爭(zhēng)問(wèn)題。

路由策略插件化實(shí)現(xiàn)

有了以上 OpenResty 點(diǎn)的鋪墊，來(lái)看看上文提的網(wǎng)關(guān)核心功能 「路由策略插件化」,「后端集群的動(dòng)態(tài)變更」如何實(shí)現(xiàn)

首先針對(duì)某個(gè)請(qǐng)求的路由策略大概是這樣的

整個(gè)插件化的步驟大致如下

1、每條策略由 url ,action, cluster 等組成，代表請(qǐng)求 url 在打到后端集群過(guò)程中最終經(jīng)歷了哪些路由規(guī)則，這些規(guī)則統(tǒng)一在我們的路由管理平臺(tái)配置，存在 db 里。

2、OpenResty 啟動(dòng)時(shí)，在請(qǐng)求的 init 階段 worker 進(jìn)程會(huì)去拉取這些規(guī)則，將這些規(guī)則編譯成一個(gè)個(gè)可執(zhí)行的 lua 函數(shù)，這一個(gè)個(gè)函數(shù)就對(duì)應(yīng)了一條條的規(guī)則。

需要注意的是為了避免重復(fù)去 MySQL 中拉取數(shù)據(jù)，某個(gè) worker 從 MySQL 拉取完規(guī)則（此步需要加鎖，避免所有 worker 都去拉?。┗蛘吆蠖思旱扰渲眯畔⒑笠獙⑵浔４嬖?shared dict 中，這樣之后所有的 worker 請(qǐng)求只要從 shared dict 中獲取這些規(guī)則，然后將其映射成對(duì)應(yīng)模塊的函數(shù)即可，如果配置規(guī)則有變動(dòng)呢，配置后臺(tái)通過(guò)接口通知 OpenResty 重新加載一下即可

經(jīng)過(guò)路由規(guī)則確定好每個(gè)請(qǐng)求對(duì)應(yīng)要打的后端集群后，就需要根據(jù) upstream 來(lái)確定最終打到哪個(gè)集群的哪臺(tái)機(jī)器上，我們看看如何動(dòng)態(tài)管理集群。

后端集群的動(dòng)態(tài)配置

在 Nginx 中配置 upstream 的格式如下

upstreambackend{ serverbackend1.example.comweight=5; serverbackend2.example.com; server192.0.0.1backup; }

以上這個(gè)示例是按照權(quán)重（weight）來(lái)劃分的，6 個(gè)請(qǐng)求進(jìn)來(lái)，5個(gè)請(qǐng)求打到 backend1.example.com, 1 個(gè)請(qǐng)求打到 backend2.example.com,如果這兩臺(tái)機(jī)器都不可用，就打到 192.0.0.1，這種靜態(tài)配置的方式 upstream 的方式確實(shí)可行，但我們知道機(jī)器的擴(kuò)縮容有時(shí)候比較頻繁，如果每次機(jī)器上下線都要手動(dòng)去改，并且改完之后還要重新去 reload 無(wú)疑是不可行的，出錯(cuò)的概率很大，而且每次配置都要 reload 對(duì)性能的損耗也是挺大的，為了解決這個(gè)問(wèn)題，OpenResty 提供了一個(gè) dyups 的模塊來(lái)解決此問(wèn)題， 它提供了一個(gè) dyups api,可以動(dòng)態(tài)增，刪，創(chuàng)建 upsteam，所以在 init 階段我們會(huì)先去拉取集群信息，構(gòu)建 upstream，之后如果集群信息有變動(dòng)，會(huì)通過(guò)如下形式調(diào)用 dyups api 來(lái)更新 upstream

--動(dòng)態(tài)配置upstream接口站點(diǎn) server{ listen127.0.0.1:81; location/{ dyups_interface; } } --增加upstream:user_backend curl-d"server10.53.10.191;"127.0.0.1:81/upstream/user_backend --刪除upstream:user_backend curl-i-XDELETE127.0.0.1:81/upstream/user_backend

使用 dyups 就解決了動(dòng)態(tài)配置 upstream 的問(wèn)題

網(wǎng)關(guān)最終架構(gòu)設(shè)計(jì)圖

通過(guò)這樣的設(shè)計(jì)，最終實(shí)現(xiàn)了網(wǎng)關(guān)的配置化，動(dòng)態(tài)化。

總結(jié)

網(wǎng)關(guān)作為承載公司所有流量的入口，對(duì)性能有著極高的要求，所以技術(shù)選型上還是要慎重，之所以選擇 OpenResty，一是因?yàn)樗咝阅?，二是目前也有小米，阿里，騰訊等大公司在用，是久經(jīng)過(guò)市場(chǎng)考驗(yàn)的，本文通過(guò)對(duì)網(wǎng)關(guān)的總結(jié)簡(jiǎn)要介紹了 OpenResty 的相關(guān)知識(shí)點(diǎn)，相信大家對(duì)其主要功能點(diǎn)應(yīng)該有所了解了，不過(guò) OpenResty 的知識(shí)點(diǎn)遠(yuǎn)不止以上這些，大家如有興趣，可以參考文末的學(xué)習(xí)教程深入學(xué)習(xí)，相信大家會(huì)有不少啟發(fā)的。