技术集成分布式系统
引言
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 万岁，我们相信你！”
用这样一种友好而强大的语言进行开发过去是，现在仍然是，一种乐趣。