[[333889]]

本文轉(zhuǎn)載自微信公眾號「 碼?！梗髡?碼海。轉(zhuǎn)載本文請聯(lián)系 碼海公眾號。

前言

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

• 網(wǎng)關的作用
• 接入層網(wǎng)關架構(gòu)設計與實現(xiàn)
• 技術選型
• OpenResty 原理剖析
• 網(wǎng)關的作用

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

• 一種是接入層網(wǎng)關(access gateway)，主要負責路由，WAF(防止SQL Injection, XSS, 路徑遍歷, 竊取敏感數(shù)據(jù),CC攻擊等)，限流，日志，緩存等，這一層的網(wǎng)關主要承載著將請求路由到各個應用層網(wǎng)關的功能
• 另一種是應用層網(wǎng)關，比如現(xiàn)在流行的微服務，各個服務可能是用不同的語言寫的，如 PHP，Java 等，那么接入層就要將請求路由到相應的應用層集群，再由相應的應用層網(wǎng)關進行鑒權等處理，處理完之后再調(diào)用相應的微服務進行處理，應用層網(wǎng)關也起著路由，超時，重試，熔斷等功能。

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

可以看到接入層網(wǎng)關承載著公司的所有流量，對性能有很高的要求，它的設計決定著整個系統(tǒng)的上限。所以我們今天主要談談接入層網(wǎng)關的設計。

接入層網(wǎng)關架構(gòu)設計與實現(xiàn)

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

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

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

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

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

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

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

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

技術選型

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

?

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

?

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

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

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

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

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

「2.同步非阻塞」

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

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

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

local res, err  = query-mysql(sql) 
local value, err = query-redis(key) 

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

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

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

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

OpenResty 原理剖析

工作原理剖析

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

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

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

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

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

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

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

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

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

OpenResty 請求生命周期

Nginx 的每個請求有 11 個階段，OpenResty 也有11 個 *_by_lua 的指令，如下圖示:

各個階段 *_by_lua 的解釋如下

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

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

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

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

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

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

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

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

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

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

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

整個插件化的步驟大致如下

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

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

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

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

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

在 Nginx 中配置 upstream 的格式如下

upstream backend { 
    server backend1.example.com weight=5; 
    server backend2.example.com; 
    server 192.0.0.1 backup; 
} 

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

-- 動態(tài)配置 upstream 接口站點 
server { 
     listen 127.0.0.1:81; 
      location / { 
          dyups_interface; 
     } 
} 
 
 
-- 增加 upstream:user_backend 
curl -d "server 10.53.10.191;" 127.0.0.1:81/upstream/user_backend 
 
-- 刪除 upstream:user_backend 
curl -i -X DELETE 127.0.0.1:81/upstream/user_backend 

網(wǎng)關最終架構(gòu)設計圖

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

總結(jié)

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