從 Java8 到 Java11 ： PrettyZoo 開發回顧（模塊化在 GUI 中的實踐）

原由

elastic-job-lite 是公司使用的一款定時任務調度框架，該框架將全部的任務調度信息都註冊進了 zookeeper 中。

爲了方便定位相關的問題，我去網上搜了 zookeeper 相關的圖形化客戶端，結果沒有一款符合本身的需求，因而就乾脆本身寫一個算了。

該客戶端是去年國慶假期寫的，經歷了從 Java8 到 Java11 的重構（主要是模塊化），該文章主要是對整個過程的一個回顧

從需求分析到實現

面向用戶：zookeeper 用戶

軟件名稱：PrettyZoo

功能：

• 節點 CRUD
• 節點實時同步

交互與原型：

交互分兩部，第一步啓動頁面要求用戶輸入 zookeeper 的服務地址，鏈接成功後會跳到節點操做頁面

技術方案：

• 語言採用 Java
• UI 框架採用 Swing
• 採用傳統的分層架構
• Zookeeper Client 採用 Apache Curator

最終實現：

不足：

• 受限於交互流程，一次只能管理一個 zookeeper server
• 因爲是 Java8，運行須要安裝額外的 JRE（或 JDK），影響了受衆面
• 顏值不足
• 工程質量方面，架構分層不清晰，致使層與層之間相互滲透，隨時膨脹爲一個 Big Bom

界面與架構的重構規劃

重構主要是爲了解決上一版的不足，而第一步就是分析產生這些問題的根本緣由，再提出對應的解決方案

• 一次只能管理一個 server

  這是由於交互和設計上致使的，要解決該問題須要從新思考交互和軟件的佈局。

  通過網上的調研，最終決定採用 「三欄佈局」，即解決了之前交互模式的分割感，又知足了一次性管理多個 server 的需求。

• 須要額外安裝 JRE

  既然選擇了 Java 做爲開發語言，那麼程序必然會依賴 JRE 來運行。此時再切換語言天然是不現實的，好在 Java9 的 模塊化系統（Jigsaw）提供了另外一個選擇，細節就不在此深刻討論了。

  總之就是模塊化改造之後，最終打包出來的程序不須要安裝額外的 JRE 也能夠運行，由於打包出來的程序已經提供了運行時須要的最小依賴集合。

  因爲最新的 JDK LTS 版本是 11，因此跳過 9 和 10，直接升級到 Java11

• 顏值不足

  初版的 UI 採用的是 Java Swing 技術， 相對來講過於沉重，乾脆就將 UI 框架切換到了 JavaFX.

  JavaFX 是下一代的 Java 客戶端技術，能夠經過 CSS 來調整軟件的總體樣式，並且 JavaFX 對還支持數據綁定。

• 分層架構致使的模塊邊界不清晰

  架構的改造對用戶的感知幾乎沒有，但依然是一個重中之重的事情，由於隨着功能的增長，每次改動的成本也會成倍的增長，最終可能致使該軟件沒法維護下去。

  架構的總體框架依然是分層，不過加入了 SPI 層用於反轉層與層之間的依賴關係，能夠參見下圖

這樣就將傳統的自上而下的依賴關係改爲了一個插件式的架構。

模塊的依賴入下圖

再說一個額外的問題，不少時候服務端的 zookeeper 在內網，是不能直連的，而爲了應對這樣的場景，此次改造也加入了 SSH 隧道的功能。

重構的實現

整個軟件重構的難點在於從 Java8 遷移到 Java11 的模塊化平臺，由於 Java 的模塊化平臺並非兼容的，不少依賴的庫還不支持模塊化。

而打包用的工具 Jlink 是隻支持標準模塊的，爲了將第三庫轉爲標準模塊就須要用到構建插件（推薦 https://badass-jlink-plugin.beryx.org/releases/latest/）

最終重構完成後，打包出來的軟件接近 60M，不須要安裝 Java 運行環境就能夠運行，仍是至關滿意的。

下圖展現了佈局和交互

總結

該軟件最終的成品我開源在了 Github上，詳情點擊 https://github.com/vran-dev/PrettyZoo，歡迎 star 和 issue。

實際的體驗下來， Java 的模塊系統仍是挺不錯的，JavaFX 配合模塊化尤爲適用於桌面客戶端，奈何如今已是移動互聯網的天下了......

參考

1. PrettyZoo
2. OpenJFX
3. badass-jlink-plugin

本文使用 mdnice 排版