用於技術整合的分散式系統
引言
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。
當我們決定將 PerlTK 使用者介面替換為基於 Web 的使用者介面時，我們發現了 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 以及我們在專案中使用的絕大多數外部模組的出色可移植性，將我們的應用程式移植到不同的支援平臺非常簡單。我們遇到的唯一真正的問題是由特定於平臺的模組（主要在 Window 上）和安裝系統的開發（再次是 Windows）引起的。
GUI 開發
選擇 PyQT/QT 工具包對於客戶端應用程式的開發至關重要。在接觸 PyQT 之前，我們廣泛使用了其他工具包（Tk 和 wxPython）。沒有哪個工具包能與它的易用性、功能、穩定性和可移植性相媲美。
例如，IceBridge 控制檯的 Mac OS X 移植在不到一週的時間內完成，大部分時間都花在了學習如何從原始碼正確構建單個軟體包和配置打包系統上。
在 Mac OS X 下執行的 IceBridge 控制檯 放大
速度、可擴充套件性和穩定性
我們關注的問題之一是系統的速度。Python 證明對於我們的用途來說“足夠快”，因為大部分處理器密集型工作已經用 C 編寫（GUI 工具包、GUID 生成器、數值操作等）。我們只需要用 Python 編寫我們自定義的 RPC 協議，因為 XML-RPC（以及它的 Python 實現）被證明太慢且處理器密集。
可擴充套件性是一個我們在設計時就解決的問題，但 Python 讓我們建立了諸如透明的分散式 RPC 系統和可擴充套件的 API 系統等程式設計結構。
在穩定性方面，我們認為 Python 出色的異常處理機制給了我們巨大的優勢。我們的編碼錯誤幾乎從不會停止應用程式，並且幾乎總是可以恢復的。
實際應用
以下是一些我們使用 Devil 框架的示例場景：
- 管理和控制大型零售商（包括當地門店和總部）的所有技術系統（空調系統、功耗控制和降低、資料分析等）。
- 將遍佈歐洲的不同生產工廠和業務部門的製造集團的生產系統和會計系統進行介面和整合（即時價格模擬、即時生產資料分析和視覺化、自動化異常檢測和響應、資料關聯等）。
- 管理和控制遠端環境監測單元（GPS 連線、單元的自動更新和重新配置、資料標準化和分析等）。
怪癖
我們在 Python 語言本身方面只遇到過一些小的怪癖，其中只有一個對我們的專案產生了實際影響。
- 執行緒管理。我們知道執行緒是邪惡的，但有時它們是無價的。無法終止它們是很難接受的事情。
- Windows 和世界其他地方之間浮點數表示不一致。我們不得不執行一些糟糕的技巧來（部分地）規避這種不一致。
結論
經過如此多的開發時間和如此多的程式碼行，我們可以毫不猶豫地說：“Python 萬歲，我們相信你！”
用這樣一種友好而強大的語言進行開發是一種愉悅的體驗，而且現在依然如此。