全功能web應用服務器Openresty介紹

openresty簡介

• 官網地址
  http://openresty.org/

• 介紹
  OpenResty （也稱爲 ngx_openresty）是一個全功能的 Web 應用服務器，它打包了標準的 Nginx
  核心，不少的經常使用的第三方模塊，以及它們的大多數依賴項。

  OpenResty 經過匯聚各類設計精良的 Nginx 模塊,
  從而將 Nginx 有效的變成一個強大的 Web 應用服務器,
  這樣, Web 開發人員可使用 Lua 腳本語言調動 Nginx 支持的各類C以及Lua 模塊,
  快速構造出足以勝任 10K+ 併發鏈接響應的超高性能Web 應用系統.

  OpenResty 的目標是讓你的Web服務直接跑在 Nginx 服務內部,
  充分利用 Nginx 的非阻塞 I/O 模型,
  不單單對 HTTP 客戶端請求,甚至於對遠程後端諸如
  MySQL,PostgreSQL,Memcaches 以及 Redis 等都進行一致的高性能響應.

---

編譯安裝

下載編譯安裝包

wget http://openresty.org/download/ngx_openresty-1.7.10.2.tar.gz

解壓以後進入解壓目錄進行編譯參數配置

./configure --prefix=/data/soft/openresty --user=nginx --group=nginx

以上編譯參數可根據本身的實際需求調整，./configure --help 查看參數
make & make install 編譯安裝

安裝後的目錄介紹

---

Nginx對請求的多階段處理

瞭解openresty以前，咱們先熟悉下nginx對請求的處理過程。
nginx接收到客戶端的請求以後，對請求的處理，是分階段的，總共有11個

1. NGX_HTTP_POST_READ_PHASE
   接收完請求以後的第一個處理階段，位於uri重寫以前，不多使用
2. NGX_HTTP_SERVER_REWRITE_PHASE
   server級別的重寫，處理位於server塊內和location以外的重寫指令
   好比 index（位於server 塊內) 指令
   好比 try_files(位於server塊內) 指令（在nginx裏面也是推薦使用try_files,等效於if-rewrite)
3. NGX_HTTP_FIND_CONFIG_PHASE
   查找location配置，該階段使用上一階段重寫後的uri,查找對應的location
   該階段可能會被執行屢次
4. NGX_HTTP_REWRITE_PHASE
   location級別的uri重寫，該階段執行location的基本重寫命令
   如 rewrite trye_files
5. NGX_HTTP_POST_REWRITE_PHASE
   location重寫的最後一個階段，檢查上一階段是否有uri重寫，若是有，跳轉到合適的階段
   nginx 限制了最大重寫次數10次
6. NGX_HTTP_PREACCESS_PHASE
   訪問權限控制的前一階段，該階段在權限控制階段以前，通常也用於訪問控制，好比限制訪問頻率，連接數等
7. NGX_HTTP_ACCESS_PHASE
   訪問權限控制階段，好比基於ip黑白名單的權限控制，基於用戶名密碼的權限控制等；
8. NGX_HTTP_POST_ACCESS_PHASE
   訪問權限控制的後一階段，該階段根據權限控制階段的執行結果進行相應處理
9. NGX_HTTP_TRY_FILES_PHASE（特殊，順序不固定)
   try_files指令的處理階段，若是沒有配置try_files指令，則該階段被跳過
10. NGX_HTTP_CONTENT_PHASE
    內容生成階段，該階段產生響應，併發送到客戶端
11. NGX_HTTP_LOG_PHASE
    日誌記錄階段，該階段記錄訪問日誌

按照大類分：POST_READ階段，SERVER_REWRITE階段，FIND_CONFIG階段，REWRITE階段，POST_REWRITE階段，PREACCESS階段，ACCESS階段，POST_ACCESS階段，TRY_FILES階段，CONTENT階段，LOG階段

由於openresty裏面集成了不少模塊，實際上就是在不一樣的處理階段註冊相應的函數，lua模塊的加入讓nginx自己有了處理lua腳本的能力

---

爲何openresty快

nginx對請求的處理模式是異步非阻塞的，經過參數配置的優化(linux 內核參數優化），能夠達到10萬左右的併發處理能力
openresty基於nginx，加上了不少第三方模塊，主要是lua，可以使得nginx在內部處理lua的腳本，
lua雖然是腳本語言，可是lua的性能很好，尤爲是基於lua-jit的運行

這個圖片是nginx+php-fpm的模型，當nginx接收到php請求，就會轉交給php-fpm

php-fpm接收到請求要進行一系列初始化工做，完了執行腳本，以後釋放本次請求分配的資源，執行一些回收操做

openresty接收到動態請求，用lua去處理，直接是在nginx內部，後續的一些動做沒有，並且lua-jit是很是高效的，所以openresty快是情理之中

因爲lua和nginx結合的如此緊密，使得咱們能夠在nginx請求的各個階段靈活的處理

openresty經常使用參數或者接口

github地址
https://github.com/openresty/lua-nginx-module

nginx.conf中可使用的執行lua的指令

• lua_package_path(http)
  設置運行查找庫文件的目錄 ;;默認地址
• lua_package_cpath(http)
• lua_code_cache(http, server, location, location if)
  開啓以後對性能提高很是明顯，線上開啓
• init_by_lua init_by_lua_file(http)
• init_worker_by_lua init_worker_by_file(http)
• set_by_lua set_by_lua_file(server, server if, location, location if)
• content_by_lua content_by_lua_file content_by_block(location, location if)
• rewrite_by_lua rewrite_by_lua_file(http, server, location, location if)
• access_by_lua access_by_lua_file
• header_filter_by_lua header_filter_by_lua_file
• body_filter_by_lua body_filter_by_lua_file
• log_by_lua log_by_lua_file
• lua_shared_dict
  lua_shared_dict dogs 10m;

lua中可使用的nginx api

• ngx.arg (set_by_lua, body_filter_by_lua**)
• ngx.var.VARIABLE(set_by_lua, rewrite_by_lua, access_by_lua, content_by_lua, header_filter_by_lua, body_filter_by_lua, log_by_lua*)
• print[ngx.log(NOTICE,...]
• ngx.ctx(nit_worker_by_lua, set_by_lua, rewrite_by_lua, access_by_lua, content_by_lua, header_filter_by_lua, body_filter_by_lua, log_by_lua, ngx.timer.**)
• ngx.location.capture
• ngx.header.HEADER
• ngx.req.start_time
• ngx.req.get_method
• ngx.req.read_body
• ngx.redirect
• ngx.print ngx.say ngx.log ngx.eof
• ngx.now ngx.utctime
• ngx.shared.DICT
• ngx.timer.at

實際應用案例

• 使用 resty.memcached訪問操做memcache
• 使用 resty.mysql訪問 msyql

注意要點

• 儘可能在聲明變量時使用local，使用ngx.var ngx.print等的時候也儘可能設定爲本地變量
• 錯誤處理須要使用pcall 包裝要執行的代碼
• 使用require加載模塊
• 請求返回能夠繼續執行任務(fastcgi_finish, ngx.eof())
• 尾調用
• 鏈接池使用
• 數組下標1 #aa 能夠獲取數組大小，可是千萬不要使用
• ....