業務可視化-讓你的流程圖”Run”起來(2.問題與改進)

• 2022 年 7 月 12 日
• 筆記

前言

首先，感謝大家對上一篇文章[業務可視化-讓你的流程圖”Run”起來]的支援。

分享一下近期我對這個項目的一些改進。

問題&改進

問題1：

流程運行開始後，非同步執行，無法同步等待流程運行結束。

改進方法：
修正後流程（黃色部分為修改點）：

調用程式碼：

// 非同步調用(默認)
flow.start();
// 或者
flow.start(false);

// 同步調用
flow.start(true);

問題2：

工程需要自己下載編譯，無法自動引用。

改進方法：

將程式碼發布到maven倉庫，然後可以用下面的方法調用：

Maven

<!-- //mvnrepository.com/artifact/io.github.nobuglady/ladybugflow -->
<dependency>
    <groupId>io.github.nobuglady</groupId>
    <artifactId>ladybugflow</artifactId>
    <version>0.0.1</version>
</dependency>

Gradle

// //mvnrepository.com/artifact/io.github.nobuglady/ladybugflow
implementation 'io.github.nobuglady:ladybugflow:0.0.1'

發布到maven倉庫遇到的坑：

1. 自動發布到maven倉庫後，無法release。

首先，在創建了maven倉庫的帳號，並且完成相關配置後，發布流程如下

  a) 執行命令 mvn clean deploy

  b) 登錄sonatype倉庫，選擇Staging Repository，將發布的工程選中，選擇close。

  c) 登錄sonatype倉庫，選擇Staging Repository，將發布的工程選中，選擇release。

我遇到的問題：

  步驟a）執行完畢正常結束後，在sonatype倉庫中，在Staging Repository中看不到自己的工程。

  但是搜索自己的工程可以看到已經上傳的文件，也可以刪除（release狀態的文件應該不能刪除）。

  所以判斷是沒有自動release，但也沒法手工release，也沒有任何錯誤提示。

解決方法：

  本地打包，手工將bundle.jar上傳到Staging Repository，這樣可以看到中間狀態文件出的問題。

  果然，在手工上傳成功後，自動運行的一些校驗提示了一些pom文件問題，這可能是導致之前沒有自動release的原因。

本地打包方法：

  a) 執行

mvn release:clean release:prepare

  b) 在target目錄會看到類似下面的文件

ladybugflow-0.0.2.jar
ladybugflow-0.0.2.jar.asc
ladybugflow-0.0.2.pom
ladybugflow-0.0.2.pom.asc
ladybugflow-0.0.2-javadoc.jar
ladybugflow-0.0.2-javadoc.jar.asc
ladybugflow-0.0.2-sources.jar
ladybugflow-0.0.2-sources.jar.asc

c）進入到target目錄，運行下面命令來打包

jar -cvf bundle.jar ladybugflow*

d）將打包好的jar文件手工上傳到sonatype倉庫

e）在sonatype倉庫等待自己上傳的文件到close狀態，檢查沒問題後，選擇release。

2. 提示 can not upload bundle Because is xxxx is a RELEASE repository

解決方法：

在pom.xm的版本號中加入-SNAPSHOT，比如

<project xmlns="//maven.apache.org/POM/4.0.0" xmlns:xsi="//www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="//maven.apache.org/POM/4.0.0 //maven.apache.org/maven-v4_0_0.xsd">
  <modelVersion>4.0.0</modelVersion>
  <groupId>io.github.nobuglady</groupId>
  <artifactId>ladybugflow</artifactId>
  <packaging>jar</packaging>
  <version>0.0.2-SNAPSHOT</version>
  <name>ladybugflow</name>
  ......

項目優點

優點，也是難點，但不是亮點。設計過程複雜（花了很長時間做改進），設計結果的話又極其簡單（光看結果甚至會認為這個設計花不了一天）。

這種流程圖設計的最大問題就是流程圖狀態的更新，比如等待前面的一個或多個節點運行結束後，啟動自身節點。

第一版：每個節點提交到執行緒池後留下Future句柄，存起來。

後續節點運行前檢查前面所有join到自己節點的Future句柄，是否完成。

可以阻塞檢查，也可以sleep循環檢查。

問題：

看似解決了問題，但隱患多多，比如所有的Future句柄都要存起來，那就涉及到這些東東的管理問題，想起來又興奮又頭大。

還有檢查的時候是阻塞檢查，還是sleep循環檢查，還是。。。還是給每個節點加一個計數器，計數器清零則觸發本節點執行。。。

改進：

將多執行緒轉化為單執行緒或者可控的幾個執行緒，把圖（流程圖）單獨管理。

簡單的說，是一個人（一個邏輯）單獨的只負責更新圖，根據每個節點的狀態更新圖。更新圖後，輸出後續要運行的節點給調用者。

這樣就將節點運行，流程圖狀態分開管理。更新圖的流程入口和出口分別對應兩個隊列：

入口：運行完畢的節點隊列
出口：將要運行的節點隊列

更新圖的流程監聽入口，得到一個消息（節點運行完畢）後，更新該節點對應的流程圖，然後將後續要運行的節點輸出給出口（將要運行的隊列）。

節點的運行邏輯監聽出口隊列，然後怎麼運行節點都可以了，在本地，在遠程，在雲端都無所謂，只要節點運行後告知入口隊列，自己運行完畢，

則流程圖會自動更新，並且往出口上發消息（後續要運行的節點），如下圖所示：

這樣設計的優點：

將多執行緒轉化為單執行緒或者有限的幾個執行緒處理，避免了高並發編程帶來的各種問題和風險。

可以自由對流程圖模組進行升級，比如每條邊加條件，根據條件進行更新，異常後對流程的更新，根據節點返回值進行更新，綁定動態邏輯等等，我可以專心的設計路程圖更新的方法，不用考慮節點運行的事情。實現了流程圖更新自由。

可以自由對節點運行模組進行升級，雲端運行，api調用運行，shell運行，本地運行，分散式集群運行等等，不用考慮流程圖怎麼更新的問題。實現了節點運行自由。

感謝您看文章讀到這裡。

最後

源碼：//github.com/nobuglady/ladybugflow