用于技术集成的分布式系统
引言
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 万岁，我们相信你！”
用这样一种友好而强大的语言进行开发是一种愉悦的体验，而且现在依然如此。