OpenFaaS實戰之七：java11模板解析

時間 2021-05-25

標籤 java node git 程序員 github web spring docker shell 數據庫欄目 Java 简体版

原文原文鏈接

歡迎訪問個人GitHub

https://github.com/zq2599/blog_demosjava

內容：全部原創文章分類彙總及配套源碼，涉及Java、Docker、Kubernetes、DevOPS等；node

OpenFaaS實戰系列文章連接

本篇概覽

本文是《OpenFaaS實戰》系列的第七篇，通過前面的知識儲備，我們對OpenFaaS的服務調用和容器運行原理已經瞭然於胸，能夠更深刻的研究和使用了OpenFaaS了；
想要更加自由的開發函數，加入更多符合業務須要的特性，顯然官方提供的幾個模板是沒法知足我們的須要，以欣宸熟悉的Java爲例，現有的java11和java11-vert-x存在如下問題：
是基於Gradle的，而實際上習慣使用Maven的開發者並很多；
沒有Spring、SpringBoot；
不支持相似dubbo、SpringCloud等分佈式調用；
綜上所述，java程序員經常使用的技術棧很難在OpenFaaS的官方模板獲得支持，不要緊，我們能夠本身開發模板支持上述能力，不過這不是本章的任務，本章的目標是一塊兒深刻了解java11模板，摸清官方套路，爲後面的自定義模板開發作好充分的準備，本篇文章有如下內容：
解析Dockerfile
Java源碼學習
沒錯，java11模板很簡單，很快就能瞭解其中原理；

解析Dockerfile

回顧of-watchdog的http模式內部架構，以下圖：

從上圖可見函數功能代碼能被調用的關鍵有如下兩點：
有微服務（child）在監聽指定端口；
of-watchdog（parent）收到外部請求會轉發到微服務監聽的端口；
最爲關鍵的微服務和of-watchdog都彙集在同一個docker容器中，所以該docker鏡像的Dockerfile文件就是一切的關鍵，接下來一塊兒看看這個文件；
在OpenFaaS環境執行命令faas template pull能夠拉取所有官方模板，在template/java11目錄下是該模板的所有文件：

[root@node1 template]# tree java11
java11
├── build.gradle
├── Dockerfile
├── function
│   ├── build.gradle
│   ├── gradle
│   │   └── wrapper
│   │       ├── gradle-wrapper.jar
│   │       └── gradle-wrapper.properties
│   ├── gradlew
│   ├── gradlew.bat
│   ├── settings.gradle
│   └── src
│       ├── main
│       │   └── java
│       │       └── com
│       │           └── openfaas
│       │               └── function
│       │                   └── Handler.java
│       └── test
│           └── java
│               └── HandlerTest.java
├── gradle
│   └── wrapper
│       ├── gradle-wrapper.jar
│       └── gradle-wrapper.properties
├── README.md
├── settings.gradle
└── template.yml

打開Dockerfile閱讀，我在腳本的關鍵位置添加了註釋輔助理解，以下所示：

# 使用multi-stage builds特性，將整個鏡像構建分爲多個階段
# 名爲builder的鏡像裏面會生成java代碼編譯構建出來的結果
FROM openjdk:11-jdk-slim as builder

ENV GRADLE_VER=6.1.1
# 應用更新，而且安裝後面要用到的應用
RUN apt-get update -qqy \
  && apt-get install -qqy \
   --no-install-recommends \
   curl \
   ca-certificates \
   unzip

# 下載指定版本的gradle，並解壓，再刪除壓縮包(避免鏡像體積變大)
RUN mkdir -p /opt/ && cd /opt/ \
    && echo "Downloading gradle.." \
    && curl -sSfL "https://services.gradle.org/distributions/gradle-${GRADLE_VER}-bin.zip" -o gradle-$GRADLE_VER-bin.zip \
    && unzip gradle-$GRADLE_VER-bin.zip -d /opt/ \
    && rm gradle-$GRADLE_VER-bin.zip

# Export some environment variables
ENV GRADLE_HOME=/opt/gradle-$GRADLE_VER/
ENV PATH=$PATH:$GRADLE_HOME/bin

RUN mkdir -p /home/app/libs

ENV GRADLE_OPTS="-Dorg.gradle.daemon=false"
WORKDIR /home/app

# 把編譯構建涉及的全部內容都複製到鏡像的/home/app/目錄，
# 包括配置文件、java源碼等
COPY . /home/app/

# 開始編譯構建
RUN gradle build

# 打印文件列表
RUN find . 

# 名爲watchdog的鏡像，注意基礎鏡像是openfaas/of-watchdog
FROM openfaas/of-watchdog:0.7.6 as watchdog

# 這個ship纔是最終的鏡像，前面的builder和watchdog都是爲ship準備內容的
# 爲了控制體積，ship裏面是jre，而非jdk
FROM openjdk:11-jre-slim as ship
RUN apt-get update -qqy \
  && apt-get install -qqy \
   --no-install-recommends \
   unzip

# 爲了安全起見不使用root賬號，這裏增長名爲app的羣組和用戶
RUN addgroup --system app \
    && adduser --system --ingroup app app

# 從watchdog鏡像獲取可執行文件fwatchdog
COPY --from=watchdog /fwatchdog /usr/bin/fwatchdog

# 增長可執行權限
RUN chmod +x /usr/bin/fwatchdog

# 設置執行命令的目錄
WORKDIR /home/app

# 從builder獲取整個gradle項目的構建結果
COPY --from=builder /home/app/function/build/distributions/function-1.0.zip ./function-1.0.zip

# 執行運行容器進程的賬號是app
user app

# 解壓構建結果
RUN unzip ./function-1.0.zip

WORKDIR /home/app/

# of-watchdog轉發的地址，也就是微服務監聽的地址
ENV upstream_url="http://127.0.0.1:8082"
# of-watchdog的模式
ENV mode="http"

# 微服務是java應用，要用到這個classpath
ENV CLASSPATH="/home/app/function-1.0/function-1.0.jar:/home/app/function-1.0/lib/*"

# 啓動微服務的命令
ENV fprocess="java -XX:+UseContainerSupport com.openfaas.entrypoint.App"

# 對外暴露的端口，of-watchdog監聽的
EXPOSE 8080

# 監控檢查
HEALTHCHECK --interval=5s CMD [ -e /tmp/.lock ] || exit 1

# 容器啓動時執行的命令，既啓動of-watchdog
CMD ["fwatchdog"]

上述腳本的最後設置了好幾個環境變量，這些環境變量的定義來自of-watchdog官方Github，地址是：https://github.com/openfaas/o... ，內容以下圖：

爲了更清晰的看到腳本中三個任務是如何協同的，將整個Dockerfile的腳本用下圖表示，可見最終的鏡像來自ship，左側的builder和watchdog都是爲ship提供內容的：

java工程分析

從Dockerfile中得知微服務的啓動命令以下：

java -XX:+UseContainerSupport com.openfaas.entrypoint.App

只要搞清楚上述命令對應的實現，整個java11模板就所有掌握了，接下來就來研究這個com.openfaas.entrypoint.App類；
打開文件template/java11/function/build.gradle，看到依賴關係以下圖，紅框中的庫應該就是com.openfaas.entrypoint.App的來源了：

上圖紅框中的庫，代碼已經開源，地址是：https://github.com/openfaas/t...
打開App.java文件後，一切謎底都被揭開了，這個java11模板的源碼還真是簡單呀，先看入口的main方法：

public static void main(String[] args) throws Exception {
        // 監聽8082端口，和Dockerfile中of-watchdog轉發請求的端口保持一致
        int port = 8082;
        
        // handler是真正處理請求的實例
        HandlerProvider p = HandlerProvider.getInstance();
        IHandler handler = p.getHandler();
        
        // 配置監聽對象，並將handler綁定過來
        HttpServer server = HttpServer.create(new InetSocketAddress(port), 0);
        InvokeHandler invokeHandler = new InvokeHandler(handler);

        // 設置path，開始監聽
        server.createContext("/", invokeHandler);
        server.setExecutor(null); // creates a default executor
        server.start();
    }

有沒有以爲上述代碼和sockek編程很像；
App.java中還有靜態類InvokeHandler的定義，這個類的主要功能就是接收web請求的數據，加工成IRequest實例，丟給IHandler實例去處理，處理完成後包裝http響應，核心代碼片斷以下：

// 把request內容封裝到IRequest實例中
IRequest req = new Request(requestBody, reqHeadersMap,t.getRequestURI().getRawQuery(), t.getRequestURI().getPath());

// 執行業務邏輯處理請求            
IResponse res = this.handler.Handle(req);

// 獲得處理後的結果
String response = res.getBody();
...

上述代碼可見業務邏輯的執行的關鍵是this.handler.Handle(req)，而真正執行業務的代碼是我們本身寫的Handler.java，要搞清楚它們之間的關係，就要看HandlerProvider.java，以下圖，一些都清楚了，我們開發函數時，編寫的業務功能都在Handler.java中，而Handler是AbstractHandler的實現類，因而下圖紅框1中就會找到Handler，紅框2能夠返回Handler實例，在InvokeHandler執行this.handler.Handle(req)時，就是Handler實例在處理web請求了：