技術整合分散式系統
引言
Devil 框架是一個多平臺（Linux、OS X、Windows）、多使用者、多層、分散式平臺，用於開發流程和技術整合解決方案：開發人員可以輕鬆收集、整合、關聯、控制和視覺化異構網路硬體和軟體技術產生和消耗的所有資訊。
該專案始於 1999 年，作為一個網路安全資料整合系統，但當我們“發現”安全只是另一個流程時，它演變為一個更通用的流程管理基礎設施。
我們現在正將其用於為全國各地擁有分散式生產/業務單位的業務集團（製造、分銷等）實施業務/工廠整合解決方案。
我們正在將其作為開源產品釋出，提供非商業和商業許可證。
架構
Devil 框架系統由兩個不同的應用程式組成：應用程式伺服器元件和 IceBridge 圖形控制檯。兩者都是完全用 Python 編寫的多平臺應用程式：伺服器執行在 Linux 和 Windows 平臺（並且可以輕鬆移植到其他 Unix 系統），客戶端執行在 Linux、Windows 和 Mac OS X 上。
應用程式伺服器元件
應用程式伺服器元件是 Devil 框架產品線應用程式開發和監控控制平臺的核心。它們為資料收集、資料歷史記錄、通訊、流程自動化以及應用程式部署和整合提供了一個統一的環境。
應用程式伺服器元件架構 放大
元件被設計為一個基於外掛的系統。外掛可以在執行時手動或透過預定策略新增、刪除和更新。支援不同的策略，因此元件可以在預定時間更改功能和配置。元件的每個功能都透過外掛實現。
元件被設計為樹狀網路結構，其中一個主節點（MCP）負責所有配置和外掛的安裝和更新。所有其他節點（收集器和代理）自動獲取適當的配置和軟體更新。可以隨時新增新節點以擴充套件資料處理、達到新的地理區域或連線到新裝置。
樹狀分散式系統拓撲 放大
元件被設計為在不安全、不可靠且並非始終連線的通訊通道上工作。所有通訊都經過加密（使用 pycrypto 模組）並透過內部 PKI 基礎設施進行身份驗證（所有節點都有其 PKI 證書）。配置和程式碼傳播系統以及事件傳輸都使用儲存轉發機制。連線可以由任何元件發起：父節點可以呼叫子節點，子節點可以呼叫其父節點（連線可以在預定時間、當指定事件發生或當檢測到特殊條件時啟用）。
應用程式框架建立了一個分散式環境，從程式設計和操作的角度來看，所有節點都被視為一個公開單一 API 的獨特系統。可以在任何父節點上透明地對任何子節點執行操作。
IceBridge 圖形控制檯
IceBridge 控制檯是一個用 Python 編寫的多平臺應用程式（使用者介面使用 QT/PyQT 工具包/包裝器），它提供了應用程式伺服器系統開發、配置、管理和互動式使用所需的所有工具。
與應用程式伺服器的元件一樣，控制檯是一個基於外掛的系統。外掛在需要時或有新版本可用時從伺服器動態下載。無需使用者或管理員干預。外掛可以新增、更改、增強或隱藏任何控制檯功能，提供完整的每使用者可定製體驗。
控制檯中集成了完整的配置和視覺化開發環境（包括檢視的版本控制系統和互動式遠端 Python shell）。視覺化和控制表單（稱為檢視）可以即時新增、修改和測試。新的檢視元件（小部件）可以透過外掛動態提供。
使用“即時”小部件進行即時系統配置和介面設計 放大
可以輕鬆開發和部署特定於流程的小部件、檢視、視窗和應用程式。系統已準備好進行國際化；支援多種語言，每個使用者都可以使用其首選語言。此外，系統中還集成了翻譯工具（受 QT Linguist Tool 啟發）和類似 WikiWiki 的文件編輯和檢視工具。
在 Linux 和 KDE 上執行的帶有自定義 3D 視覺化小部件的控制檢視 放大
為什麼選擇 Python？
Python 並非我們最初選擇的主要程式語言，這只是一個巧合。當我們開始我們的專案時，我們非常精通 Perl，並且完全不知道 Python：所以我們選擇了 Perl。
當我們決定用基於 Web 的使用者介面替換 PerlTK 使用者介面時，我們發現了 Python。我們找到了 Zope，在嘗試將 Perl 與 Zope 整合後，我們轉向了 Python。長話短說，最終我們放棄了 Zope，但繼續使用 Python（並用它重寫了整個 Devil 框架）。
如果沒有這次幸運的轉換，我們認為 Devil 框架是不可能開發的，至少對於一個只有兩名開發人員的團隊來說。
專案統計
SLOCCount 的輸出說明了一切
Totals grouped by language (dominant language first): python: 233020 (97.72%) ansic: 2480 (1.04%) cpp: 1833 (0.77%) makefile: 571 (0.24%) sh: 560 (0.23%) Total Physical Source Lines of Code (SLOC) = 238,464 Development Effort Estimate, Person-Years (Person-Months) = 62.71 (752.50) (Basic COCOMO model, Person-Months = 2.4 * (KSLOC**1.05)) Schedule Estimate, Years (Months) = 2.58 (30.98) (Basic COCOMO model, Months = 2.5 * (person-months**0.38)) Estimated Average Number of Developers (Effort/Schedule) = 24.29 Total Estimated Cost to Develop = $ 8,471,018 (average salary = $56,286/year, overhead = 2.40). SLOCCount, Copyright (C) 2001-2004 David A. Wheeler Please credit this data as "generated using David A. Wheeler's 'SLOCCount'."
在人員-年方面，兩名開發人員從頭開始開發 2.0 版本用了四年時間（1.x 版本已投入生產使用但從未釋出）。
結果
如前所述，我們認為如果沒有采用 Python 作為主要開發語言，這個專案是不可能完成的，無論是由於其強大的功能，還是因為它在採用 PyQT（在嘗試使用 PerlTK、Web、wxPython 之後）、pycrypto 和其他庫方面發揮了作用，使我們能夠在相對較短的時間內構建一個可靠且便攜的系統。
生產力
Python 是我們的“秘密武器”。由於以下原因，它使我們的生產力提高了幾個數量級：
- 簡單的語法和清晰的編碼風格：它毫不費力地迫使我們使用一致且富有表現力的編碼風格。現在，檢視一段程式碼並一眼就能理解其工作原理變得很容易（這在第一個 Perl 版本中幾乎是不可能的）。
- 快速開發週期：Python 消除了繁瑣漫長的程式碼/構建/執行/崩潰開發週期。
- 它使我們能夠開發我們系統中最熱門的功能之一：當我們升級或安裝新程式碼到系統中時，它會自動動態更新自身，無論是客戶端還是伺服器。想象一下：只需雙擊一下，您就可以在中央伺服器上安裝一個外掛，更新它（將更改傳播到使用它的所有系統節點），執行它，將其客戶端內容下載到控制檯並使其啟用（動態更新 GUI）。所有這些都無需重啟伺服器或客戶端。
- 廣泛而完整的標準庫和出色的外部模組。
- 當沒有標準庫或外部模組時，圍繞第三方庫構建包裝器非常容易（尤其是使用 ctypes 模組）
- 輕鬆快速的程式碼重構：我們有一些舊程式碼會一直更新。
跨平臺開發
由於 Python 和 PyQT 以及我們在專案中使用的許多外部模組都具有出色的可移植性，因此將我們的應用程式移植到不同的支援平臺非常簡單。我們遇到的唯一真正的問題是由特定於平臺的模組（主要在 Windows 上）和安裝系統的開發（又是 Windows）引起的。
GUI 開發
選擇 PyQT/QT 工具包對於客戶端應用程式的開發至關重要。在接觸 PyQT 之前，我們廣泛使用了其他工具包（Tk 和 wxPython）。沒有哪個工具包能與它的易用性、功能、穩定性和可移植性相媲美。
例如，IceBridge 控制檯的 Mac OS X 移植在不到一週的時間內完成，大部分時間都花在學習如何正確地從原始碼構建單個軟體包和配置打包系統上。
IceBridge 控制檯在 Mac OS X 下執行 放大
速度、可伸縮性和穩定性
我們關注的一個問題是系統的速度。Python 被證明“足夠快”以滿足我們的用途，因為大多數處理器密集型工作已經用 C 編寫（GUI 工具包、GUID 生成器、數值操作等）。我們只需要用 Python 編寫我們自定義的 RPC 協議，因為 XML-RPC（及其 Python 實現）被證明太慢且處理器密集。
可伸縮性是我們設計時解決的一個問題，但 Python 讓我們建立了程式設計構造，例如透明的分散式 RPC 系統和可擴充套件的 API 系統。
關於穩定性，我們認為 Python 出色的異常處理機制給了我們巨大的優勢。我們的編碼錯誤幾乎從未停止應用程式，並且幾乎總是可恢復的。
實際應用
我們使用 Devil 框架的一些示例場景包括：
- 管理和控制大型零售商從當地商店和總部（空調系統、功耗控制和降低、資料分析等）的所有技術系統。
- 為在歐洲各地設有不同生產工廠和業務部門的製造集團整合生產系統和會計系統（即時價格模擬、即時生產資料分析和視覺化、自動化異常檢測和響應、資料關聯等）。
- 管理和控制遠端環境監測單元（GPS 連線、單元的自動更新和重新配置、資料標準化和分析等）。
怪癖
我們只遇到了 Python 語言本身的一些小問題，其中只有一個對我們的專案產生了真正的影響：
- 執行緒管理。我們知道執行緒是邪惡的，但有時它們是無價的。沒有辦法殺死它們是很難接受的。
- Windows 和世界其他地區浮點表示不一致。我們不得不採取一些棘手的技巧來（部分地）規避這種不一致。
結論
經過如此長時間的開發和如此多的程式碼行，我們可以毫不猶豫地說：“Python 萬歲，我們相信你！”
用這樣一種友好而強大的語言進行開發過去是，現在仍然是，一種樂趣。