CS 架構軟體自動升級實現（一）：架構設計與版本控制機制

在企業內部工具分發場景中，頻繁的版本迭代與手動通知更新極大地增加了維護成本。本文介紹一套基於 Socket 通訊、XML 版本控制的通用自動升級模組，支援多檔案差異更新、歷史記錄自動推送與瀏覽，可獨立於業務系統運行，為各類 C/S 架構軟體提供標準化升級能力。

一、系統背景與設計目標

早期採用郵件通知用戶手動替換 JAR 包的方式，不僅效率低下，且易導致版本不一致。為解決此問題，設計了一套獨立的自動升級程式，核心目標包括：

• 通用性：脫離具體業務工具，單獨部署，支援任意 C/S 軟體接入。
• 自動化：客戶端啟動時自動連線伺服器檢查版本，無感知完成更新。
• 可視化：更新完成後自動開啟 history.htm，讓用戶直觀查看變更內容。
• 差異更新：僅傳輸版本號不一致的檔案，節省頻寬與時間。

二、核心配置檔：autoupdate.xml

版本控制中樞採用 XML 格式，結構清晰，易於擴展與解析（使用 dom4j）。

<?xml version="1.0" encoding="GBK"?>
<Info>
  <Version>1.0.3</Version>              <!-- 軟體主版本號 -->
  <UpdateServer>
    <Ip>122.2.14.212</Ip>               <!-- 升級伺服器 IP -->
    <Port>2110</Port>                    <!-- 升級伺服器埠 -->
  </UpdateServer>
  <Files>                                 <!-- 檔案清單與子版本 -->
    <File>
      <Name>mftest.jar</Name>
      <Path>.\bin</Path>
      <SubVer>1.0.0.3</SubVer>
    </File>
    <File>
      <Name>run.bat</Name>
      <Path>.</Path>
      <SubVer>1.0.0.3</SubVer>
    </File>
    <File>
      <Name>eglreco.fix</Name>
      <Path>.\config\resource</Path>
      <SubVer>1.0.0.0</SubVer>
    </File>
    <!-- 更多檔案節點... -->
  </Files>
</Info>

關鍵欄位說明：

• Version：軟體大版本號，優先比對，不一致即觸發全量檢查。
• UpdateServer：指定升級伺服器地址，客戶端讀取此處發起連線。
• Files/File：每個檔案獨立維護 SubVer，支援精細到單檔案的增量更新。

三、更新歷史記錄：history.htm

採用簡易 HTML 表格呈現版本演進脈絡，樣式內嵌，無外部依賴，客戶端接收後直接以瀏覽器或 Desktop.getDesktop().browse() 開啟。

<table width="600" border="1" align="center" cellpadding="2" cellspacing="0">
  <tr bgcolor="#ECECEC">
    <td width="50" align="center">版本</td>
    <td width="470" align="center">更新內容</td>
    <td width="80" align="center">日期</td>
  </tr>
  <tr>
    <td align="center">1.0.3</td>
    <td><p>1.實現自動升級功能<br>2.增加版本號顯示<br>3.修正錯誤</p></td>
    <td align="center">2008-12-25</td>
  </tr>
  <!-- 歷史版本列... -->
</table>

四、工作流程詳解

1. 客戶端啟動，讀取本地 autoupdate.xml，建立 Socket 連線至伺服器。
2. 發送版本資訊：將完整 XML 內容傳送給伺服器（指令 SENDCVER）。
3. 伺服器比對：
   • 優先比對 Version，一致則回覆 NNEEDUPD（無需更新）。
   • 不一致則遍歷 Files/File，比對 SubVer，收集需更新檔案清單。
   • 伺服器端存在而客戶端缺失的檔案亦納入傳輸清單。
4. 檔案傳輸：伺服器依序發送檔案路徑（SENDFILE）與二進制內容（STARTTSM ~ TERMTSMT），採 1KB 分塊傳輸。
5. 推送歷史記錄：所有檔案傳輸完畢後，發送 history.htm 並回覆 UPDESUCC。
6. 客戶端收尾：接收 UPDESUCC，寫入檔案、更新本地 XML、自動開啟 history.htm 展示變更日誌，最後啟動主程式。

五、技術選型亮點

• Socket 原生通訊：無需 Web 容器，輕量級部署，適合內網環境。
• dom4j 解析 XML：XPath 支援靈活，程式碼簡潔。
• 協議無狀態設計：指令與資料分離，擴展性強（如後續可加入斷點續傳、加密傳輸）。

此架構已在生產環境穩定運行，有效解決了多部門、多客戶端的版本同步難題。後續文章將深入原始碼層面，解析協議類 AUPD、伺服器監聽執行緒 AutoUpdateServer 及服務處理邏輯 AUpdSrvProc 的實作細節。