关于后端:Java扩展Nginx之五五大handler系列最核心

欢送拜访我的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)：

名称	链接	备注
我的项目主页	https://github.com/zq2599/blog_demos	该我的项目在GitHub上的主页
git仓库地址(https)	https://github.com/zq2599/blog_demos.git	该我的项目源码的仓库地址，https协定
git仓库地址(ssh)	git@github.com:zq2599/blog_demos.git	该我的项目源码的仓库地址，ssh协定

这个git我的项目中有多个文件夹，本篇的源码在nginx-clojure-tutorials文件夹下的handler-demo子工程中，如下图红框所示：
本篇波及到nginx.conf的批改，残缺的参考在此：https://raw.githubusercontent.com/zq2599/blog_demos/master/ng…

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（日志输入）

欢送关注思否：程序员欣宸

评论

发表回复取消回复

更多文章

苹果iOS打包的ipa应用无法安装？一篇文章带你了解可能的原因及排查方法

图解Golang：从零开始实现简易版过期LRU缓存

深入解析：基于Delta的线性数据结构模型，打造高效富文本编辑器

轻松管理社交媒体：使用Automa插件实现一键拉黑功能

关于后端: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（日志输入）

欢送关注思否：程序员欣宸

评论

发表回复 取消回复

更多文章

苹果iOS打包的ipa应用无法安装？一篇文章带你了解可能的原因及排查方法

图解Golang：从零开始实现简易版过期LRU缓存

深入解析：基于Delta的线性数据结构模型，打造高效富文本编辑器

轻松管理社交媒体：使用Automa插件实现一键拉黑功能

发表回复取消回复