前言

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

網(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)作為所有請求的流量入口，主要承擔(dān)著安全，限流，熔斷降級，監(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)主要承載著將請求路由到各個(gè)應(yīng)用層網(wǎng)關(guān)的功能

另一種是應(yīng)用層網(wǎng)關(guān)，比如現(xiàn)在流行的微服務(wù)，各個(gè)服務(wù)可能是用不同的語言寫的，如 PHP，Java 等，那么接入層就要將請求路由到相應(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)承載著公司的所有流量，對性能有很高的要求，它的設(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ī)則將請求分發(fā)到對應(yīng)的后端集群」，所以要實(shí)現(xiàn)如下幾個(gè)功能模型 。

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

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

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

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

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

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

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

技術(shù)選型

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

?

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

?

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

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

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

「1.詳盡的文檔和測試用例」

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

「2.同步非阻塞」

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

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

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

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

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

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

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

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

OpenResty 原理剖析

工作原理剖析

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

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

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

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

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

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

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

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

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

OpenResty 請求生命周期

Nginx 的每個(gè)請求有 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)答頭過濾處理； body_filter_by_lua：應(yīng)答體過濾處理； log_by_lua：日志記錄。

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

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

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

# 加密協(xié)議版本 location /request { access_by_lua '...'; # 請求體解密 content_by_lua '...'; # 處理請求，不需要關(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ù)的問題， OpenResty 提供了一種高效的數(shù)據(jù)結(jié)構(gòu): shared dict ,可以實(shí)現(xiàn)在 worker 間共享數(shù)據(jù)，shared dict 對外提供了 20 多個(gè) Lua API，都是原子操作的，避免了高并發(fā)下的競爭問題。

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

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

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

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

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

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

需要注意的是為了避免重復(fù)去 MySQL 中拉取數(shù)據(jù)，某個(gè) worker 從 MySQL 拉取完規(guī)則（此步需要加鎖，避免所有 worker 都去拉取）或者后端集群等配置信息后要將其保存在 shared dict 中，這樣之后所有的 worker 請求只要從 shared dict 中獲取這些規(guī)則，然后將其映射成對應(yīng)模塊的函數(shù)即可，如果配置規(guī)則有變動呢，配置后臺通過接口通知 OpenResty 重新加載一下即可

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

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

在 Nginx 中配置 upstream 的格式如下

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

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

--動態(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 就解決了動態(tài)配置 upstream 的問題

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

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

總結(jié)

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