歡迎通路我的GitHub

這裡分類和彙總了欣宸的全部原創(含配套源碼)：https://github.com/zq2599/blog_demos

本篇概覽

本文是《Java擴充Nginx》系列的第五篇，如題，本篇是整個系列的最核心内容，咱們寫的代碼主要都集中在nginx-clojure定義的五種handler中，不同handler分别發揮着各自的作用，它們是：

Initialization Handler for nginx worker（初始化）
Content Ring Handler for Location（location對應的業務處理）
Nginx Rewrite Handler（位址重定向）
Nginx Access Handler（鑒權）
Nginx Log Handler（日志輸出）

接下來，一起在實戰中學習它們

源碼下載下傳

《Java擴充Nginx》的完整源碼可在GitHub下載下傳到，位址和連結資訊如下表所示(https://github.com/zq2599/blog_demos)：

這個git項目中有多個檔案夾，本篇的源碼在nginx-clojure-tutorials檔案夾下的handler-demo子工程中，如下圖紅框所示：

本篇涉及到nginx.conf的修改，完整的參考在此：https://raw.githubusercontent.com/zq2599/blog_demos/master/nginx-clojure-tutorials/files/nginx.conf

maven工程

建立名為handler-demo的maven工程，今天實戰的代碼都在這裡面

我這裡為了統一管理代碼和依賴庫，整個《Java擴充Nginx》系列的源碼都放在父工程nginx-clojure-tutorials下面，本篇的handler-demo也是nginx-clojure-tutorials的一個子工程
接下來，編碼實戰每種handler

Initialization Handler for nginx worker（初始化）

Initialization Handler，顧名思義，是用于執行初始化邏輯的handler，它在nginx配置中是http級别的，有以下幾個特性：

每個worker都是獨立的程序，啟動的時候都會調用一次Initialization Handler
Initialization Handler也是NginxJavaRingHandler接口的實作類，其invoke方法會被調用，是以初始化邏輯代碼應該寫在invoke方法中

接下來寫代碼試試，新增MyInitHandler.java，代碼如下：

package com.bolingcavalry.handlerdemo;

import nginx.clojure.NginxClojureRT;
import nginx.clojure.java.NginxJavaRingHandler;
import java.io.IOException;
import java.util.Map;

public class MyInitHandler implements NginxJavaRingHandler {
    @Override
    public Object[] invoke(Map<String, Object> map) throws IOException {
        // 可以根據實際需求執行初始化操作，這裡作為示範，隻列印日志
        NginxClojureRT.log.info("MyInitHandler.invoke executed");
        return null;
    }
}

用指令mvn clean package -U，生成名為handler-demo-1.0-SNAPSHOT.jar的檔案，将其放入nginx的jars目錄下
再在nginx.conf的http配置中增加以下兩行配置：

jvm_handler_type 'java';
jvm_init_handler_name 'com.bolingcavalry.handlerdemo.MyInitHandler';

重新開機nginx，打開logs/error.log檔案，發現裡面新增一行日志，這就是初始化日志：

2022-02-05 23:02:37[info][73954][main]MyInitHandler.invoke executed

如果之前部署的location還在，可以用postman發請求試試，應該可以正常響應，表示nginx的worker已經正常工作：

Content Ring Handler for Location（location對應的業務處理）

content handler是最常用的handler，這是個location配置，定義了nginx收到某個請求後應該如何處理，前面的文章中已經用到了
現在咱們再寫一個content handler，與之前不同的是新增了配置項content_handler_property，該配置項可以添加自定義配置，整個location如下所示：

location /contentdemo {
	# 第一個自定義屬性
    content_handler_property foo.name 'foo.value';
   # 第二個自定義屬性
   content_handler_property bar.name 'bar.value';
   # 邏輯處理類
   content_handler_name 'com.bolingcavalry.handlerdemo.MyContentHandler';
}

從上面的配置可見，通過content_handler_property增加了兩個配置項，名字分别是foo.name和bar.name
再來看MyContentHandler類的源碼，重點是實作了Configurable接口，然後在config方法被調用的時候，入參map中儲存的就是content_handler_property配置的key和value了，在invoke方法中可以直接使用：

package com.bolingcavalry.handlerdemo;

import nginx.clojure.Configurable;
import nginx.clojure.java.ArrayMap;
import nginx.clojure.java.NginxJavaRingHandler;
import java.io.IOException;
import java.time.LocalDateTime;
import java.util.Map;
import static nginx.clojure.MiniConstants.CONTENT_TYPE;
import static nginx.clojure.MiniConstants.NGX_HTTP_OK;

public class MyContentHandler implements NginxJavaRingHandler, Configurable {

    private Map<String, String> config;

    /**
     * location中配置的content_handler_property屬性會通過此方法傳給目前類
     * @param map
     */
    @Override
    public void config(Map<String, String> map) {
        this.config = map;
    }

    @Override
    public Object[] invoke(Map<String, Object> map) throws IOException {

        String body = "From MyContentHandler, "
                    + LocalDateTime.now()
                    + ", foo : "
                    + config.get("foo.name")
                    + ", bar : "
                    + config.get("bar.name");

        return new Object[] {
                NGX_HTTP_OK, //http status 200
                ArrayMap.create(CONTENT_TYPE, "text/plain"), //headers map
                body
        };
    }
}

編譯、配置、重新開機nginx，再用postman通路/contentdemo，響應如下，可見符合預期，content_handler_property配置的值可以在invoke方法中使用：

Nginx Rewrite Handler（位址重定向）

rewrite handler顧名思義，就是咱們常在nginx上配置的rewrite功能，在nginx-clojure中又略有不同，為了友善記憶，這裡将整個rewrite分為三段處理：

下面就是一個完整的rewrite handler，這些内容都是寫在http配置内的：

# 1. 定義變量，用于儲存路徑
set $myhost "";
       
location /myproxy {
	rewrite_handler_type 'java';
	# 2. java代碼中為變量指派
    rewrite_handler_name 'com.bolingcavalry.handlerdemo.MyRewriteProxyPassHandler';
     # 3. 用變量的值作為位址進行跳轉
     proxy_pass $myhost;
}

對應的MyRewriteProxyPassHandler.java如下：

package com.bolingcavalry.handlerdemo;

import nginx.clojure.NginxClojureRT;
import nginx.clojure.java.NginxJavaRequest;
import nginx.clojure.java.NginxJavaRingHandler;
import java.util.Map;
import static nginx.clojure.java.Constants.PHASE_DONE;

public class MyRewriteProxyPassHandler implements NginxJavaRingHandler {
    @Override
    public Object[] invoke(Map<String, Object> req) {
        // 根據業務情況定制計算出的path
        String myhost = computeMyHost(req);
        // 用setVariable方法設定myhost變量的值，這個myhost在這個location中被定義，跳轉的時候就用這個值作為path
        ((NginxJavaRequest)req).setVariable("myhost", myhost);
        // 傳回PHASE_DONE之後，nginx-clojure架構就會執行proxy_pass邏輯，
        // 如果傳回的不是PHONE_DONE，nginx-clojure架構就把這個handler當做content handler處理
        return PHASE_DONE;
    }

    /**
     * 這裡寫入業務邏輯，根據實際情況确定傳回的path
     * @param req
     * @return
     */
    private String computeMyHost(Map<String, Object> req) {
        // 确認是http還是https
        String scheme = (String)req.get("scheme");
        // 确認端口号
        String serverPort = (String)req.get("server-port");

        // /contentdemo是nginx.conf中配置的一個location，您可以根據自己的業務情況來決定傳回值
        String myhost = scheme + "://127.0.0.1:" + serverPort + "/contentdemo";

        NginxClojureRT.log.info("pass address [" + myhost + "]");

        return myhost;
    }
}

編譯建構運作起來，用postman通路/myproxy，效果如下圖，從傳回結果可見請求被成功轉發到/contentdemo：

此刻，相信聰明的您應該想到了：既然rewrite handler的邏輯代碼可以自己用java寫，那意味着可以按照自己的業務需求随意定制，那豈不是自己可以在nginx上寫一個負載均衡的功能出來了？沒錯，從下圖可見官方也是這麼說的：

如果您的環境中有注冊中心，例如eureka或者nacos，您還可以取得背景服務清單，這樣，不光是負載均衡，各種轉發排程邏輯都可以在nginx上開發出來了
還有一點要注意的，下圖是剛才寫的MyRewriteProxyPassHandler.java的源碼，注意紅框位置，是invoke方法的傳回值，如果傳回的不是PHASE_DONE，nginx-clojure架構就不再執行後面poss_proxy操作，而是把此handler當做普通的content handler來處理了：

Nginx Access Handler（鑒權）

access handler的定位，是用于執行鑒權相關的邏輯
其實看過了前面的rewrite handler，聰明的您應該會想到：rewrite handler既可以重定向，也可以直接傳回code和body，那豈不是直接用來做鑒權？鑒權不通過就在rewrite handler上傳回401 （Unauthorized）或者403 （Forbidden）

從技術實作的角度來看，您說得沒錯，access handler來自nginx-clojure對功能和職責的劃分，官方建議将鑒權的工作都交給access handler來做：

正常情況下，一次請求被前面幾種handler執行的順序如下：

寫一個access handler的配置和代碼驗證試試，為了省事兒，就在前面rewrite handler的基礎上改動吧
首先是配置，如下所示，在剛才的rewrite handler的配置中，增加了access_handler_type和access_handler_name，這就意味着該location的請求，先由MyRewriteProxyPassHandler處理，再交給BasicAuthHandler處理，如果鑒權通過，才會交給proxy_pass處理：

# 1. 定義變量，用于儲存路徑
set $myhost "";
       
location /myproxy {
	# 指定access handler的類型是java
    access_handler_type 'java';
    # 指定access handler的執行類類
    access_handler_name 'com.bolingcavalry.handlerdemo.BasicAuthHandler';

    rewrite_handler_type 'java';
    # 2. java代碼中為變量指派
    rewrite_handler_name 'com.bolingcavalry.handlerdemo.MyRewriteProxyPassHandler';
    # 3. 用變量的值作為位址進行跳轉
    proxy_pass $myhost;
}

BasicAuthHandler.java的内容如下，已添加詳細注釋，就不多贅述了：

package com.bolingcavalry.handlerdemo;

import nginx.clojure.java.ArrayMap;
import nginx.clojure.java.NginxJavaRingHandler;
import javax.xml.bind.DatatypeConverter;
import java.util.Map;
import static nginx.clojure.MiniConstants.DEFAULT_ENCODING;
import static nginx.clojure.MiniConstants.HEADERS;
import static nginx.clojure.java.Constants.PHASE_DONE;

public  class BasicAuthHandler implements NginxJavaRingHandler {

    @Override
    public Object[] invoke(Map<String, Object> request) {
        // 從header中擷取authorization字段
        String auth = (String) ((Map)request.get(HEADERS)).get("authorization");

        // 如果header中沒有authorization，就傳回401錯誤，并帶上body
        if (auth == null) {
            return new Object[] { 401, ArrayMap.create("www-authenticate", "Basic realm=\"Secure Area\""),
                    "<HTML><BODY><H1>401 Unauthorized.</H1></BODY></HTML>" };
        }

        // authorization應該是 : Basic xfeep:hello!，是以這裡先将"Basic "去掉，然後再用":"分割
        String[] up = auth.substring("Basic ".length()).split(":");

        // 隻是為了示範，是以賬号和密碼的檢查邏輯在代碼中是寫死的，
        // 如果賬号等于"xfeep"，并且密碼等于"hello!"，就傳回PHASE_DONE，這樣nginx-clojure就會繼續執行後面的content handler
        if (up[0].equals("xfeep") && up[1].equals("hello!")) {
            return PHASE_DONE;
        }

        // 如果賬号密碼校驗不過，就傳回401，body内容是提示賬号密碼不過
        return new Object[] { 401, ArrayMap.create("www-authenticate", "Basic realm=\"Secure Area\""),
                "<HTML><BODY><H1>401 Unauthorized BAD USER & PASSWORD.</H1></BODY></HTML>" };
    }
}

編譯建構部署之後，咱們來試試效果，用postman再次請求/myproxy，因為header中沒有authorization字段，是以傳回401錯誤：

然後在header中增加一個屬性，如下圖紅框，名字authorization，值Basic xfeep:hello!，再發一次請求，藍框中顯示傳回碼正常，并且傳回内容也是重定向後的location生成的：

然後故意用錯誤的密碼試試，如下圖，鑒權未通過，并且傳回body準确描述了具體的錯誤資訊：

Nginx Log Handler（日志輸出）

最後一個handler是作為輔助作用的日志輸出，盡管在其他handler中，我們可以直接調用NginxClojureRT.log方法将日志輸出到error.log檔案中，但還是可以猜出官方定義Log Handler的用意：

明确劃分各個handler的職責
讓日志與業務功能解耦合，讓Log Handler做純粹的日志輸出工作
日志子產品偏向于元件化，各個location可以按照需求選擇用或者不用，而且還可以設計成多個location複用

另外Log Handler也有屬于自己的特性：

依舊是NginxJavaRingHandler接口的實作，invoke方法被執行的時機是request被銷毀前
有專用的配置屬性log_handler_property
invoke方法的傳回值無意義，會被nginx-clojure忽略

接下來通過執行個體學習log handler，找到前面的content handler的demo，給它加上日志輸出試試，将配置檔案修改如下，可見增加了log_handler_name用于指定日志輸出的執行類，另外還有兩個log_handler_property配置項作為自定義屬性傳入：

location /contentdemo {
         # 第一個自定義屬性
         content_handler_property foo.name 'foo.value';
         # 第二個自定義屬性
         content_handler_property bar.name 'bar.value';
         content_handler_name 'com.bolingcavalry.handlerdemo.MyContentHandler';

         # log handler類型是java
         log_handler_type java;
         # log handler的執行類
         log_handler_name 'com.bolingcavalry.handlerdemo.MyLogHandler';
         # 自定義屬性，在MyLogHandler中作為是否列印User Agent的開關
         log_handler_property log.user.agent on;
         # 自定義屬性，在MyLogHandler中作為日志目錄
         log_handler_property log.file.path logs/contentdemo.log;
       }

對應的MyLogHandler.java，有幾處要注意的地方稍後會提到：

package com.bolingcavalry.handlerdemo;

import nginx.clojure.Configurable;
import nginx.clojure.NginxClojureRT;
import nginx.clojure.java.NginxJavaRequest;
import nginx.clojure.java.NginxJavaRingHandler;
import java.io.File;
import java.io.FileOutputStream;
import java.io.IOException;
import java.util.Map;

public class MyLogHandler implements NginxJavaRingHandler, Configurable {

    /**
     * 是否将User Agent列印在日志中
     */
    private boolean logUserAgent;

    /**
     * 日志檔案路徑
     */
    private String filePath;

    @Override
    public Object[] invoke(Map<String, Object> request) throws IOException {
        File file = new File(filePath);
        NginxJavaRequest r = (NginxJavaRequest) request;
        try (FileOutputStream out = new FileOutputStream(file, true)) {
            String msg = String.format("%s - %s [%s] \"%s\" %s \"%s\" %s %s\n",
                    r.getVariable("remote_addr"),
                    r.getVariable("remote_user", "x"),
                    r.getVariable("time_local"),
                    r.getVariable("request"),
                    r.getVariable("status"),
                    r.getVariable("body_bytes_sent"),
                    r.getVariable("http_referer", "x"),
                    logUserAgent ? r.getVariable("http_user_agent") : "-");
            out.write(msg.getBytes("utf8"));
        }
        return null;
    }

    @Override
    public void config(Map<String, String> properties) {
        logUserAgent = "on".equalsIgnoreCase(properties.get("log.user.agent"));
        filePath = properties.get("log.file.path");
        NginxClojureRT.log.info("MyLogHandler, logUserAgent [" + logUserAgent + "], filePath [" + filePath + "]");
    }

    // 下面這段代碼來自官方demo，實測發現這段代碼在列印日志的邏輯中并未發揮作用，
    // 不論是否删除，日志輸出的内容都是相同的
    /*
    @Override
    public String[] variablesNeedPrefetch() {
        return new String[] { "remote_addr", "remote_user", "time_local", "request", "status", "body_bytes_sent",
                "http_referer", "http_user_agent" };
    }
    */
}

上述代碼中，有下面幾處地方要注意：

以上代碼來自官方demo，我這裡做了點小的改動(主要是檔案路徑改為外部參數傳入)
整體功能是取出請求和響應的一些參數，列印在日志檔案中
logUserAgent參數控制了user agent是否列印，這個比較實用，可以通過配置來做一些開關控制
這個demo不要用于生産環境，從代碼可以看出，每一次請求都做了一次io操作，這是存在性能隐患的，官方的demo隻是展示log handler的作用而已，看看就好
variablesNeedPrefetch方法的代碼被我注釋掉了，因為實際嘗試發現不論這段代碼是否存在，都不回影響日志的輸出，去看源碼也沒弄明白…（水準有限，望了解），于是就注釋掉了，畢竟隻要日志輸出正常就行

編譯建構部署運作，先看logs/error.log，如下，可見MyLogHandler成功的接收到了配置項的值：

2022-02-08 08:59:22[info][69035][main]MyLogHandler, logUserAgent [true], filePath [logs/contentdemo.log]

再用postman請求/contentdemo試試，如下圖，首先確定響應和之前一緻，證明log handler不影響主業務：

去logs目錄下檢視，發現新增了contentdemo.log檔案，内容如下，postman自帶的header參數已經被成功擷取并列印在日志中了：

127.0.0.1 - x [08/Feb/2022:09:45:36 +0800] "GET /contentdemo HTTP/1.1" 200 "80" x PostmanRuntime/7.29.0

至此，五大handler咱們已經全部實戰體驗過了，對nginx-clojure的主要能力已經熟悉，接下來的章節會繼續深入挖掘，歡迎繼續關注欣宸原創

歡迎關注頭條号：程式員欣宸

學習路上，你不孤單，欣宸原創一路相伴...

Java擴充Nginx之五：五大handler(系列最核心)

歡迎通路我的GitHub

本篇概覽

源碼下載下傳

maven工程

Initialization Handler for nginx worker（初始化）

Content Ring Handler for Location（location對應的業務處理）

Nginx Rewrite Handler（位址重定向）

Nginx Access Handler（鑒權）

Nginx Log Handler（日志輸出）

歡迎關注頭條号：程式員欣宸

繼續閱讀

python的logging子產品handle的子類

Handler(上)那些事兒Handler概述ThreadLocalMessageQueueLooper的工作原理局部總結

Android Handler源碼淺析

再次了解handler，自己寫一個小例子替代handler

深入了解異步加載--Handler和Looper源碼解析（2）

安卓網絡程式設計1--ANR異常和Handler機制

重識Handler

阿裡，騰訊，位元組等大廠Android面試必須掌握的知識點：從源碼角度看Handler

android-Handler源碼解析

【Android】Handler機制源碼解析

Android中使用Handler以及CountDownTimer實作包含倒計時的閃屏頁面1. 實作效果如下：2. 實作方法

Android-Handle類總結

LeakCanary直面項目中的記憶體洩露

Android關于Hander的記憶體洩漏oom問題

“啥 Handler 原理你都不知道，還敢來面試……”Handler 的再了解與總結

Android中更新UI的三種方式