桌面采集程序架構優化：從單一進程走向多進程守護模式

問題背景：單一程序多窗口的隱憂

開發一個定時采集三個網站數據的桌面程序，初期採用單一進程、多窗口設計：一個主窗口統籌三個采集子窗口。雖然功能能跑通，但隨著業務擴展，這種架構暴露出明顯短板：

• 擴展性差：新增第 4、5 個采集站點時，需修改主程序代碼並重新編譯部署
• 容錯性低：任一采集窗口崩潰都會導致整個程序掛掉，其他正常采集任務被迫中斷
• 維護困難：所有采集規則、定時邏輯、入庫策略耦合在同一進程，代碼臃腫難維護

架構演進：多進程 + 守護進程方案

針對上述痛點，建議採用「多進程隔離 + 守護進程監控」的架構模式：

核心設計原則

1. 進程隔離：每個采集站點獨立為一個進程，擁有獨立的內存空間、定時器、數據庫連接池
2. 守護進程：引入一個輕量級監控進程，負責子進程的啟動、心跳檢測、異常重啟、日誌聚合
3. 配置化管理：采集規則、定時策略、入庫映射全部外部化為配置文件（JSON/YAML），新增站點無需改代碼

內存佔用評估與優化

關於擔心的「多進程增加系統負擔」問題，實際經驗表明：

• 現代作業系統對進程調度極其高效，5 個輕量級采集進程的內存佔用通常在 50-100MB 範圍內
• 可通過配置每個進程的采集緩衝區大小（如批次提交筆數、定時器間隔）精準控制內存佔用
• 若單進程內部邏輯複雜導致內存洩漏，反而比多進程隔離更難排查

落地建議

正式重構前，建議先進行壓測驗證：

1. 啟動 5 個獨立采集進程模擬真實負載
2. 監控 24 小時內存增長曲線、CPU 佔用峰值
3. 驗證守護進程在子進程 Crash、死鎖、網絡超時等場景下的自動恢復能力
4. 確認無內存洩漏、CPU 抖動後再投入生產

這種架構不僅解決了當前的擴展性與穩定性問題，更為後續接入分布式任務調度、容器化部署奠定了基礎。