分布式、实时和嵌入式 (DRE) 系统是一类重要的应用，它们兼具企业分布式系统和资源受限的实时和嵌入式系统的特性。特别是，DRE 系统中的应用类似于企业应用，即它们分布在一个较大的域中。此外，与实时和嵌入式系统一样，DRE 系统中的应用通常是任务关键型的，并具有严格的安全、可靠性和服务质量 (QoS) 要求。
除了上述复杂性之外，在DRE 系统中部署应用和基础设施组件也会带来自身的一系列独特挑战。首先，DRE 系统域中的应用可能对目标环境具有特定的依赖性，例如特定的硬件/软件（例如，GPS、传感器、执行器、特定的实时操作系统等）。其次，DRE 系统的部署基础设施必须应对资源有限环境中的严格资源要求（例如，CPU、内存、网络带宽等）。
基于组件的软件工程 (CBSE) [1] 越来越被用作开发企业[2] 和DRE 系统[3] 中应用的范例。CBSE 通过鼓励开发人员创建通过定义良好的接口相互交互及其环境的黑盒组件来促进系统的软件重用。CBSE 还通过提供标准化的机制来控制应用的配置和生命周期，简化了高度复杂的分布式系统的部署[4]。这些机制能够从更小、更易于管理的功能单元（例如，商用现货组件和预先存在的应用程序构建块）组合大型、复杂的应用程序。这些应用程序可以与描述性和配置元数据一起打包，并可用于部署到生产环境中。
基于从ACE ORB (TAO) [5]（公共对象请求代理体系结构 (CORBA) 标准的开源实现）开发中获得的专业知识，我们在过去十年中一直将CBSE 原则应用于DRE 系统。由于这些努力，我们开发了一个高质量的OMG CORBA 组件模型 (CCM) 开源实现，我们称之为组件集成 ACE ORB (CIAO) [6]。CIAO 实施了所谓的轻量级 CCM [7] 规范，它是完整CCM 标准的一个子集，针对资源受限的DRE 系统进行了优化。
在我们关于将CBSE 原则应用于DRE 系统的工作背景下，我们也一直在研究同样具有挑战性的问题，即如何促进这些领域中基于组件的系统的部署和配置。管理基于组件的应用程序的部署和配置是一个具有挑战性的问题，原因如下
组件依赖项和版本管理。各个组件之间可能存在复杂的依赖关系。组件可能相互依赖才能正常运行，或者专门需要或排除特定版本。如果这些关系没有被描述和执行，组件应用程序可能无法正确部署；更糟糕的是，可能会以微妙和有害的方式出现故障。
组件配置管理。组件可能会公开配置钩子来更改其行为，而部署基础设施必须管理和应用任何所需的配置信息。此外，部署中的几个组件可能具有相关的配置属性，而部署基础设施应确保这些属性在整个应用程序中保持一致。
分布式连接和生命周期管理。对于企业系统，必须在远程主机上安装组件并管理其连接和激活。
为了应对上述挑战，我们于 2005 年开始为CIAO 开发部署引擎。这个工具，我们称之为部署和配置引擎 (DAnCE) [8]，是OMG 部署和配置 (D&C) 规范 [9] 的实现。在大部分历史中，DAnCE 主要作为研究生开发新颖的部署和配置方法的研究载体，这对其实现产生了两个重要影响
作为研究载体，DAnCE 的开发时间表主要由论文截止日期和赞助商的功能演示驱动。因此，其测试用例相对简单且重点狭窄。
随着研究项目的完成和新项目的启动，DAnCE 的管理权多次易手。因此，整个基础设施通常没有统一的架构愿景。
这两个因素对 DAnCE 产生了几个影响。例如，狭窄且集中的用例通常使评估真实世界应用程序部署中的端到端性能成为低优先级。此外，缺乏统一的架构愿景加上紧张的截止日期，通常意味着为了权宜之计做出了糟糕的架构选择，并且后来没有得到纠正。当我们开始与我们的商业赞助商合作将 DAnCE 应用于更大规模的部署时，这些问题就变得更加突出，这些部署涉及数百到数千个组件在数十到数百个硬件节点上的部署。虽然较小、集中的用例将具有可接受的部署时间，但这些较大的部署将花费不可接受的长的时间，大约需要一个小时或更长时间才能完全完成。
| 标题 | 原则 | 网络中的示例 |
|---|---|---|
| 避免浪费 | 避免明显的浪费 | 零拷贝 [11] |
| 时间上的转移 | 及时转移计算（/预计算、惰性求值、共享费用、批处理） | 写时复制 [12] [13]、集成层处理 [13] |
| 放宽规范 | 放宽规范（以确定性换取时间，以准确性换取时间，并及时转移计算） | 公平队列 [14]、IPv6 分片 |
| 利用其他组件 | 利用其他系统组件（利用局部性、以内存换取速度、利用硬件） | Lulea IP 查找 [15]、TCP 校验和 |
| 添加硬件 | 添加硬件以提高性能 | 流水线 IP 查找 [16]、计数器 |
| 高效的例程 | 创建高效的例程 | UDP 查找 |
| 避免通用性 | 避免不必要的通用性 | Fbufs [17] |
| 规范与实现 | 不要混淆规范和实现 | 上行调用 [18] |
| 传递提示 | 在接口中传递诸如提示的信息 | 数据包过滤器 [19] [20] [21] |
| 传递信息 | 在协议头中传递信息 | 标签交换 [22] |
| 预期用例 | 优化预期情况 | 报头预测 [23] |
| 利用状态 | 添加或利用状态以提高速度 | 活动 VC 列表 |
| 自由度 | 优化自由度 | IP Trie 查找 [24] |
| 利用有限的宇宙 | 对有限的宇宙使用特殊技术 | 定时轮 [25] |
| 高效的数据结构 | 使用高效的数据结构 | 4 级交换 |
为了应对这些问题，我们着手全面评估 DAnCE 的架构、设计和实现，并创建一个新的实现，我们称之为支持局部性的 DAnCE (LE-DAnCE) [26] [27]。本章重点记录和应用构成LE-DAnCE 核心的优化原则模式，使其适用于DRE 系统。表 6.1 总结了常见的优化模式 [10]，其中许多我们在LE-DAnCE 中应用。本文的另一个目标是在我们关于LE-DAnCE 的工作中补充此目录，并添加我们识别的新模式。
本章的其余部分组织如下：DAnCE 概述 提供了OMG D&C 规范的概述；将优化原则模式应用于 DAnCE 确定了 DAnCE 性能问题最显着的来源（从XML 解析部署信息、在运行时分析部署信息以及序列化执行部署步骤），并将其用作案例研究来识别优化原则，这些原则 (1) 通常适用于DRE 系统，以及 (2) 我们应用于LE-DAnCE；以及结束语 给出了结束语。
OMG D&C 规范为在整个基于组件的应用程序开发生命周期中使用的元数据提供了标准交换格式，以及用于打包和计划的运行时接口。这些运行时接口通过组件部署计划将部署指令传递到中间件部署基础设施，该计划包含组件实例及其关联连接信息的完整部署和配置信息。在DRE 系统初始化期间，必须及时解析此信息、将组件部署到物理硬件资源并激活系统。
本节简要总结了标准兼容的 D&C 实现必须提供的核心架构元素和流程。我们使用此摘要作为基础来讨论 DAnCE 中的重大性能和可扩展性问题，DAnCE 是我们对OMG 部署和配置 (D&C) 规范 [9] 的开源实现，如引言 中所述。此摘要分为三个部分：(1) DAnCE 运行时架构，描述了系统中存在的守护进程和参与者，(2) 数据模型，描述了描述组件应用程序的“部署计划”的结构，以及 (3) 部署过程，提供部署的分布式应用程序实现过程的高级概述。
OMG D&C 规范为组件的部署和配置定义的运行时接口由图 6.1所示的两层架构组成。
图 6.2 - OMG D&C 架构概述和关注点分离
此架构由以下部分组成：(1) 一组用于协调部署的全局（系统范围）实体和 (2) 一组用于实例化组件实例并配置其连接和 QoS 属性的本地（节点级）实体。这些全局和本地层中的每个实体都对应以下三个主要角色之一
此角色（在全局级别称为ExecutionManager，在节点级别称为NodeManager）是一个单例守护进程，它在一个上下文中协调所有部署实体。管理器充当所有部署活动的入口点，以及ApplicationManager角色实现的工厂。
此角色（在全局级别称为DomainApplicationManager，在节点级实体称为NodeApplicationManager）协调基于组件的应用程序正在运行的实例的生命周期。每个 ApplicationManager 代表一个基于组件的应用程序，并用于启动该应用程序的部署和拆卸。此角色还充当Application角色实现的工厂。
此角色（在全局级别称为DomainApplication，在节点级实体称为NodeApplication）表示基于组件的应用程序的已部署实例。它用于完成组成应用程序的相关组件实例的配置，并开始执行已部署的基于组件的应用程序。
除了上面描述的运行时实体之外，D&C 规范还包含一个广泛的数据模型，用于在整个部署生命周期中描述组件应用程序。规范定义的元数据旨在用作
各种工具（例如，开发工具、应用程序建模和打包应用程序以及部署计划工具）之间用于创建应用程序的交换格式，以及
描述运行时基础架构使用的配置和部署的指令。
D&C 元数据中的大多数实体都包含一个部分，其中可以以名称/值对序列的形式包含配置信息，其中值可以是任意数据类型。此配置信息可用于描述从基本配置信息（例如共享库入口点和组件/容器关联）到更复杂的配置信息（例如 QoS 属性或使用用户定义数据类型初始化组件属性）的所有内容。
这些元数据可以大致分为三类：打包、域和部署。打包描述符从应用程序开发的开始就用于指定组件接口、功能和需求。创建实现后，此元数据将进一步用于将单个组件分组到程序集中，描述与实现工件（例如共享库（也称为动态链接库））的配对，并创建包含元数据和实现的包，这些包可以安装到目标环境中。域描述符由硬件管理员用于描述域中存在的功能（例如，CPU、内存、磁盘空间和GPS接收器等特殊硬件）。
组件应用程序部署在一个由OMG D&C 标准编纂的四阶段过程中执行。Manager和ApplicationManager负责前两个阶段，Application负责最后两个阶段，如下所述
计划准备。在此阶段，将部署计划提供给ExecutionManager，它 (1) 分析计划以确定哪些节点参与部署，以及 (2) 将计划拆分为“局部约束”计划，每个节点一个，其中仅包含对应节点的信息。这些局部约束计划仅包含单个节点的实例和连接信息。然后联系每个NodeManager并提供其局部约束计划，这会导致创建NodeApplicationManagers并返回其引用。最后，ExecutionManager使用这些引用创建一个DomainApplicationManager。
启动启动。当DomainApplicationManager收到启动启动指令时，它会将工作委托给每个节点上的NodeApplicationManagers。每个NodeApplicationManager创建一个NodeApplication，将所有组件实例加载到内存中，执行初步配置，并收集部署计划中描述的所有端点的引用。然后，这些引用由DomainApplicationManager创建的DomainApplication实例缓存。
完成启动。此阶段由DomainApplication实例上的操作启动，该操作将其从上一阶段收集的对象引用分配给每个NodeApplication，并导致它们启动此阶段。所有组件实例都接收最终配置，然后创建所有连接。
启动。此阶段再次在DomainApplication上启动，它委托给NodeApplication实例，并导致它们指示所有已安装的组件实例开始执行。
本节考察了在将 DAnCE 应用于大型生产DRE系统中的基于组件的应用程序时，我们发现的三个最麻烦的性能问题。我们首先描述一个案例研究，该案例研究突出了许多这些性能挑战。然后，我们确定性能下降的原因，并利用此讨论来提出优化原则，这些原则是在其他情况下和应用程序中应用以补救或防止性能问题的指南。
一个揭示 DAnCE 存在重大性能问题的DRE系统示例是与阿拉斯加大学在东南阿拉斯加监测科学、电信、教育和研究网络(SEAMONSTER) 平台上的合作。 SEAMONSTER 是一个位于阿拉斯加东南大学 (UAS) 的冰川和流域传感器网络 [28]。此传感器网络监控和收集有关柠檬溪流域和柠檬冰川及其周围地区冰川动力学和质量平衡、流域水文、沿海海洋生态以及人类影响/危害的数据。收集到的数据用于研究冰川速度、冰川湖泊形成和排水、流域水文和温度变化之间的相关性。
SEAMONSTER 传感器网络包括部署在冰川上和整个流域中的传感器和防风雨计算机平台，以收集科学感兴趣的数据。传感器收集的数据通过无线网络中继到服务器集群，这些服务器对数据进行过滤、关联和分析。在SEAMONSTER现场硬件上有效部署数据收集和过滤应用程序，以及对不断变化的环境条件和资源可用性的动态适应，对SEAMONSTER的有效运行提出了重大的软件挑战。虽然SEAMONSTER服务器提供了大量的计算资源，但现场硬件的计算能力有限。
传感器网络中的现场节点在其感兴趣区域通常有大量可观察的现象。这些现象的类型、持续时间和观察频率可能会随着时间的推移而发生变化，这取决于环境的变化、环境中瞬态事件的发生以及传感器网络科学任务中不断变化的目标和目的。此外，有限的功率、处理能力、存储和网络带宽限制了这些节点以所需的频率和保真度持续执行观察的能力。环境条件的动态变化加上有限的资源可用性，需要传感器网络的各个节点快速修改当前操作和未来计划，以最大程度地利用其资源。
为了应对这些挑战，我们建议将数据收集和处理任务转换为构建在简介和DAnCE 概述中分别描述的CIAO和 DAnCE 中间件之上的中间件平台。我们开发了一个运行时计划程序 [29]，用于分析传感器节点的物理观测。根据这些信息以及网络的操作目标，计划程序会生成描述所需软件配置的部署计划。
但是，使用 DAnCE 应用运行时计划程序请求的部署更改揭示了其性能的一些缺点。这些缺点因现场硬件性能有限、连接节点的网络相对缓慢以及系统的严格实时要求而加剧。下面描述了每个缺点。
OMG D&C 的组件应用程序部署由一个数据结构描述，该数据结构包含组件实例的所有相关配置元数据、它们到各个节点的映射以及所需的任何连接信息。此部署计划以XML文件的形式序列化到磁盘上，其结构由 D&C 规范定义的XML模式描述。这种XML文档格式通过为在建模工具之间交换部署计划文件提供简单的交换格式提供了显著的优势 [30]。
例如，在SEAMONSTER案例研究中，此格式为规划前端和部署基础架构之间提供了一个方便的交换格式。此格式也易于使用流行编程语言的广泛可用XML模块生成和操作。此外，它使文本处理工具（如 perl、grep、sed 和 awk）能够轻松修改和数据挖掘。
但是，在部署甚至运行时处理这些部署计划文件可能会导致大量的性能损失。这些性能损失源于以下原因
随着部署中组件实例和连接数量的增加，XML部署计划文件的大小会大幅增加，这会导致将计划加载到内存中以及根据模式验证结构以确保其格式良好的重大 I/O 开销。
部署基础架构无法直接使用XML文档格式，因为基础架构是一个实现OMG接口定义语言(IDL) 接口的CORBA应用程序。因此，必须首先将XML文档转换为部署框架运行时接口使用的IDL格式。
在DRE系统中，数量达数千的组件部署并不少见。此外，这些域中的组件实例将表现出高度的连接性。这两个因素都会导致大型计划。但是，计划不必很大才能显着影响系统的运行。尽管上面描述的SEAMONSTER案例研究中的计划明显较小，但极其有限的计算资源意味着即使较小计划的处理开销也常常过于耗时。
有两种解决问题中概述的XML解析挑战的一般方法。
XSC生成的C++数据绑定创建了许多类（基于XML模式的内容），这些类提供对XML文档中数据的强类型面向对象访问。此外，此接口利用C++ STL的功能来帮助程序员编写简洁高效的代码来与其数据交互。填充这些包装器的常规过程是：1）使用DOM XML解析器解析XML文档；2）解析DOM树以填充生成的类层次结构。为了增强与STL算法和仿函数的兼容性，XSC将其数据存储在STL容器类内部。
XSC数据绑定的初始版本效率非常低。即使是相对适中的部署（组件数量仅为几百到一千个），也需要近半个小时才能完成处理。在使用Rational Quantify等工具分析此过程的执行情况后，发现了一个非常简单的问题：生成的XSC代码以一种天真的方式将元素逐个插入其内部数据结构（在本例中为std::vector）。结果，在插入每个额外元素时，会花费大量时间重新分配和复制这些容器内部的数据。
下面我们介绍开发人员必须注意的具体指南
注意抽象的成本。 高级抽象（例如C++ STL中提供的容器类）可以通过减少重现复杂且容易出错的低级（主要是样板）代码的需求来极大地简化程序。重要的是要描述和记录（在编写抽象时）并理解（在使用抽象时）使用抽象提供的更高级别操作可能产生的隐藏成本。
为您的用例使用合适的抽象。 通常，在提供类似功能的抽象之间需要做出选择。一个例子可能是std::vector和std::list之间的选择；每个都提供了自身的优势。在XSC中，最初使用std::vector是因为我们希望随机访问数据绑定中的元素；由于插入性能差，解析XML文档时的成本非常高。但是，我们的用例只需要顺序访问，因此std::list的更好的插入性能最终更可取。
通过理解我们生成的XML数据绑定的特定用例的具体需求——特别是大多数节点只访问一次并且可以按顺序访问——我们能够通过应用其他两个优化模式来应用预期用例模式。避免泛化模式在这种情况下适用，因为我们有意识地避免泛化，通过生成不包含随机访问容器的数据绑定。然后，我们选择使用最有效的数据结构（有效数据结构模式）来满足这种缺乏泛化的情况。
这种优化方法通过将部署计划转换为更有效的二进制格式的代价高昂的转换转移到应用程序部署的关键路径之外，应用了时间转移优化模式。在应用此模式时，我们首先将部署计划转换为其运行时IDL表示。然后，我们使用CORBA规范定义的通用数据表示（CDR）[32]二进制格式将结果序列化到磁盘。 SEAMONSTER在线规划器可以通过生成这些二进制计划而不是基于XML的部署计划来利用此优化，从而显着减少延迟。
用于将部署计划存储在磁盘上的独立于平台的CDR二进制格式与在运行时通过网络传输计划时使用的格式相同。这种方法的优点在于它利用了底层CORBA实现提供的经过高度优化的反序列化处理程序。这些处理程序从磁盘上的二进制流创建部署计划数据结构的内存表示。
在将组件部署计划加载到内存表示中后，必须由中间件部署基础设施进行分析，然后才能执行任何后续的部署活动。此分析发生在OMG D&C部署过程中描述的计划准备阶段。此分析的目标是确定（1）部署计划中包含的部署子问题的数量，以及（2）哪些组件实例属于每个子问题。
如OMG D&C部署过程中所述，此分析过程的输出是一组“位置受限”的子计划。位置受限的子计划包含成功执行部署所需的所有必要元数据。因此，它包含原始计划中包含的信息的副本（在D&C部署数据模型中描述）。
运行时计划分析实际上在部署的计划准备阶段进行两次：一次在全局级别，另一次在每个节点上。全局部署计划根据分配给各个实例的节点进行拆分。这种两部分分析会为每个节点生成一个新的子计划，该子计划仅包含该节点所需的实例、连接和其他组件元数据。
我们DAnCE对D&C规范的实现使用的计划拆分算法很简单。对于计划中要部署的每个实例，算法都会确定哪个子计划应该包含它并检索相应的（或创建一个新的）子计划数据结构。在确定此关系时，该组件实例所需的所有元数据都会复制到子计划中，包括连接、描述可执行文件的元数据、共享库依赖项等。
虽然这种方法在概念上很简单，但它充满了意外的复杂性，在实践中产生了以下低效之处
IDL中的引用表示。 部署计划通常通过网络传输，因此必须遵守CORBA IDL语言映射的规则。由于IDL没有任何引用或指针的概念，因此必须使用某种替代机制来描述计划元素之间的关系。部署计划将所有主要元素存储在序列中，因此对其他实体的引用可以用这些序列中的简单索引来表示。虽然此实现可以在恒定时间内遵循引用，但这也意味着当计划实体复制到子计划时，这些引用将失效，因为它们在部署计划序列中的位置很可能不同。如果不搜索子计划，也无法确定引用的目标是否已被复制，这非常耗时。
部署计划序列中的内存分配。 CORBA IDL映射要求序列存储在连续的内存地址中。因此，如果调整序列的大小，其内容很可能将复制到内存中的另一个位置以适应增加的序列大小。使用上面总结的方法，随着计划大小的增长，会发生大量的复制开销。这种开销在资源受限的系统（例如我们的SEAMONSTER案例研究）中尤其成问题，这些系统必须为应用程序组件保留有限的运行时内存。如果部署基础设施在其资源使用方面效率低下，它要么会耗尽可用内存，要么会导致任何可用虚拟内存的重大抖动（两者都会影响部署延迟和闪存存储的使用寿命）。
计划分析的低效并行化。 上述算法似乎可以从并行化中获益匪浅，因为分析单个组件并确定哪些元素必须复制到子计划的过程独立于所有其他组件。但是，多线程此算法可能无效，因为必须序列化对子计划的访问以复制实例元数据，以避免数据损坏。在实践中，部署计划中的组件实例通常根据节点和/或进程进行分组，因为部署计划通常是从建模工具生成的。结果，多个线程可能会争夺同一个子计划的锁，这会导致“并行化”算法基本上顺序运行。虽然并行化历来被认为不适用于资源受限的DRE系统（如SEAMONSTER），但单板计算机中多核处理器的出现正在推动这些环境中的更多并行性。
可以通过应用规范与实现模式，并利用前面为XSC工具描述的一些相同的优化原则来解决此性能挑战，特别是注意抽象的成本和为用例使用合适的容器。例如，可以使用指针/引用而不是序列索引来引用相关的数据结构，从而潜在地消除在计划实体在计划之间复制时仔细重写引用的需要。同样，关联容器（例如STL映射）而不是序列可以存储计划对象，从而提高将计划实体插入子计划的效率。
虽然这些和其他类似的选项很诱人，但D&C标准的要求中存在一些固有的复杂性，使得这些优化不太有吸引力。由于此数据必须作为部署过程的一部分传输到其他实体，因此使用更有效的表示进行分析将在部署过程中引入另一个转换步骤。此转换可能会压倒此新表示带来的任何收益。
一个更吸引人的结果是将一组不同的优化原则应用于此问题，如下所示
缓存先前计算的结果以供以后使用。 这是时间推移和利用状态模式的一个示例。可以执行一个简单的预分析步骤来预先计算一些稍后执行起来会比较耗时的值。在本例中，首先遍历计划以确定包含计算出的子计划所需的最终大小，并缓存该状态以供以后使用。
在可能的情况下，预先分配所有数据结构。 由于通过上面描述的预分析步骤收集到的额外状态，我们可以应用避免浪费原则，并通过预先分配之前每次发现新计划元素时都会重新分配的序列来避免不必要的浪费。
设计您的算法以利用并行化。 虽然这可以被视为添加硬件的应用，但这种模式更多地是利用硬件的内在特性，例如字大小缓存效应。此外，这种模式还涉及添加专用硬件来执行专门的计算。
利用多个通用处理器是一个重要的新兴原则。由于多核计算机在台式机和服务器领域普遍存在，并且即使在嵌入式领域也变得越来越普遍，因此设计此重要的硬件特性变得越来越重要。因此，我们提出了一种额外的模式，我们将其称为设计用于并行化，其中一个优化算法和接口的设计以实现并行化，如所示。
构建共享数据访问以避免需要使用同步。 同步（例如，使用互斥锁来保护对共享数据的访问）使用起来既繁琐又容易出错。此外，过度使用同步通常会完全抵消算法的任何并行化。一种更可取的方法是构建您的算法以完全消除对同步的需求；仅需要对数据进行共享读取访问，而不是共享写入访问。
此优化原则不仅是上面提出的设计用于并行化的重要伴侣，而且通常也是一种明智的编程实践：由不正确的同步引起的死锁和竞争条件是难以诊断的严重错误。事实上，我们最近在用于分段航天器的软件框架中的工作提出了一种组件模型，该模型完全消除了应用程序代码中的同步 [33]。为此，我们提出了另一种优化模式，我们称之为避免同步，其中应该避免过度同步和锁定，如下所示。
这些原则可以应用于上面描述的算法，以创建一个更易于优化的版本；新算法（以及上述原则如何影响设计）将在下面描述。
阶段 1：确定要生成的子计划的数量。 在此阶段，单个线程迭代部署计划中包含的所有组件实例，以确定必要的子计划的数量。当此操作在全局级别执行时，它只需要每个实例进行恒定时间操作。当在本地级别执行时，它需要评估局部性约束（在D&C 部署数据模型中描述）。由于此阶段可能比较耗时，因此会缓存结果以供以后使用。这是时间推移和利用状态的一个示例。
阶段 2：为子计划预分配数据结构。 使用在上述阶段 1 中收集的信息，预分配组装子计划所需的数据结构。作为此预分配的一部分，可以为子计划数据结构中的每个序列预留内存，以避免重复调整大小和复制。在阶段 1 中收集统计信息以有效地估计这些长度。这是一个避免浪费的例子。
阶段 3：组装节点特定的子计划。 新分析过程的此阶段类似于本节开头描述的算法。主要区别在于缓存的预分析阶段结果用于指导子计划的创建。而不是按顺序考虑每个实例（就像原始的 DAnCE 实现所做的那样），LE-DAnCE 每次完全构建一个子计划，方法是基于每个节点处理实例。这种方法通过为每个子计划分配一个线程来简化此阶段的并行化，并消除了线程之间的任何共享状态，除了对原始计划的只读访问。因此，无需使用任何锁定机制来保护对子计划的访问。这是一个设计用于并行化和避免同步的示例。
上述修改后的算法是计划分析的一个更高效的实现，即使在SEAMONSTER用例中典型的单核嵌入式处理器上也能显示出改进：上述方法在内存效率方面更高，无论是在使用空间方面还是在必要的重新分配方面。使用多核嵌入式处理器将大大提高运行时性能，优于旧算法。
下面介绍的复杂性涉及部署任务的串行（非并行）执行。DAnCE 中相关的延迟来源存在于全局和节点级别。在全局级别，这种缺乏并行性是由于 DAnCE 使用的基础CORBA 传输导致的。然而，在本地级别的缺乏并行性是由于 D&C 实现与 D&C 规范中包含的目标组件模型的接口方面缺乏特异性导致的。
在OMG D&C 部署过程中介绍的 D&C 部署过程使全局实体能够将部署过程划分为多个节点特定的子任务。每个子任务使用单个远程调用调度到各个节点，任何由节点产生的数据都通过“out”参数传递回全局实体，这些参数是IDL中描述的操作签名的一部分。由于用于实现 DAnCE 的CORBA 消息传递协议的同步（请求/响应）性质，传统方法是将这些子任务串行调度到每个节点。与使用CORBA异步方法调用(AMI)机制的复杂性相比，这种方法易于实现 [34]。
为了最大程度地降低初始实现的复杂性，我们在最初的 DAnCE 实现中使用了一个（不可否认有些短视的）设计选择，即同步调用。对于组件数量少于 100 的相对较小的部署，这种全局同步工作得很好。然而，随着分配给这些节点的节点和实例数量的增加，这种全局/本地序列化在部署延迟方面带来了巨大的成本。
这种序列化执行在我们SEAMONSTER案例研究中产生了最成问题的性能下降，即现场硬件上有限的计算资源通常需要几分钟才能完成。节点级别的这种延迟很快就会变得灾难性。特别是，即使是涉及数十个节点的相对适度的部署，也会很快使系统的部署延迟延长到半小时或更长时间。
但是，此序列化问题不仅限于全局/本地任务调度；它也存在于基础设施的节点特定部分中。D&C 规范没有提供有关 NodeApplication 如何与目标组件模型（例如CORBA 组件模型(CCM)）交互的指导，而是将此类接口作为实现细节留给实现。
在 DAnCE 中，D&C 架构使用三个进程实现，如图 6.3所示。
图 6.3 - 简化的、序列化的 DAnCE 架构
ExecutionManager 和 NodeManager 进程在其地址空间中实例化其关联的 ApplicationManager 和 Application 实例。当 NodeApplication 安装具体组件实例时，它会根据需要生成一个（或多个）单独的应用程序进程。这些应用程序进程使用从旧版本的CCM规范派生的接口，允许 NodeApplication 分别实例化容器和组件实例。这种方法类似于CARDAMOM [35]（这是另一个针对企业DRE系统（如空中交通管理系统）定制的开源CCM实现）采用的方法。
图6.3中所示的 DAnCE 架构在并行化方面存在问题，因为其 NodeApplication 实现集成了安装、配置和连接实例所需的所有逻辑（如图 6.4所示），
图 6.4 - 以前的 DAnCE NodeApplication 实现
而不是仅执行某些处理并将其余具体部署逻辑委托给应用程序进程。这种紧密集成使得难以并行化节点级安装程序，原因如下
通用部署逻辑（解释计划的 NodeApplication 实现的一部分）和特定部署逻辑（具有如何操作组件的特定知识的部分）共享的数据量使得难以在单个组件服务器的上下文中并行化它们的安装，因为必须在安装期间修改该数据。
安装到单独应用程序进程的组件组被视为单独的部署子任务，因此这些分组是按顺序一个接一个地处理的。
与前面描述的分析问题类似，这是一个过度序列化影响性能的问题。但是，在本例中，我们不会重新评估部署过程的算法方法，而是会重新考虑系统的架构设计。为了解决这种情况下的性能挑战，我们将以下优化原则应用于 DAnCE
不要让规范过度约束您的设计。 根据规范实现系统或软件框架时，通常会自然地根据规范的结构和隐含假设来建模您的设计。通常可以设计您的实现，以便引入在规范结构内保持的架构元素或行为。这是一个规范与实现模式和自由度模式的示例。
保持严格的关注点分离。 确保您的系统在层或模块中运行，这些层或模块通过定义良好的接口进行交互。这有助于确保每一层或模块的状态都包含良好，简化应用程序逻辑上不同部分之间的交互，并使应用设计用于并行化模式变得更容易。此外，确保每一层的的状态是自包含的有助于应用避免同步模式。
此外，模块化您的软件设计通常可以揭示可以应用其他优化原则模式的方法。因此，我们提出了另一个原则模式，分离关注点，利用关注点分离来模块化架构（总结于。虽然传统上可能不赞成间接级别，因为它可能导致性能损失，但有时它可以揭示新的机会或帮助应用其他优化。
确保这些层或模块可以异步交互。如果架构中的模块或层具有假设同步操作的接口，则难以利用并行操作来提高性能。即使接口本身是同步的，也通常可以使用其他技术，例如利用允许您以异步方式与同步接口交互的抽象。避免同步交互是面向并行化设计模式的另一个重要应用。
在全局级别（例如，运行时D&C架构中描述的ExecutionManager）应用这些原则，由于它和节点级资源位于不同的进程中，并且很可能位于不同的物理节点中，因此关注点的分离得以维持。在这种情况下，异步也很容易实现，因为我们能够利用CORBA异步方法调用（AMI）允许客户端（在本例中为全局基础设施）与同步服务器接口（在本例中为节点级基础设施）异步交互，并并行地将多个请求分派到各个节点。这是一个自由度的例子，因为规范没有拒绝这些实体之间异步交互的概念。
然而，在节点级基础设施中应用这些原则更具挑战性。如上所述，我们的初始实现关注点分离较差，使得为了在节点级别并行化部署活动而应用多个执行线程变得极其困难。为了支持这一点，我们在节点级别创建了一个新的抽象，我们称之为Locality Manager，它是应用上述优化原则的结果。
LE-DAnCE Locality Manager概述。LE-DAnCE节点级架构（例如，NodeManager、NodeApplicationManager和NodeApplication）现在充当OMG D&C架构全局部分的节点约束版本。与其让NodeApplication直接触发具体组件实例的安装，不如将此责任委托给LocalityManager实例。节点级基础设施通过将组件实例分组到一个或多个应用程序进程中，对从全局级别接收的计划执行第二次“拆分”。然后，NodeApplication生成多个LocalityManager进程，并将这些“进程约束”（即仅包含与单个进程相关的组件和连接）计划并行地委托给每个应用程序进程。
Locality Manager是规范与实现模式的一个例子。规范建议NodeApplication是与组件中间件交互的最终实体；通过认识到我们的实现可以引入另一层抽象，我们能够应用许多其他优化模式。
与之前的DAnCE NodeApplication实现不同，LE-DAnCE LocalityManager充当一个通用应用程序进程，严格分离分析计划所需的通用部署逻辑与安装和管理具体组件中间件实例生命周期所需的特定部署逻辑。这种分离是通过称为实例安装处理程序的实体实现的，这些实体提供了一个定义明确的接口来管理组件实例的生命周期，包括安装、删除、连接、断开连接和激活。安装处理程序也用于NodeApplication的上下文中，以管理LocalityManager进程的生命周期。
这些安装处理程序的起源是自由度模式的一个例子；通过对与组件中间件的显式交互进行欠规范，它使我们能够自由地设计我们自己的交互。在这样做的时候，我们应用了分离关注点模式。
使用Locality Manager减少部署步骤的串行执行。LE-DAnCE的新LocalityManager和安装处理程序使并行化比DAnCE更容易得多。LocalityManager和NodeApplication中的并行性是使用一个称为部署调度程序的实体实现的，该实体在图6.5中显示。
图6.5 - DAnCE部署调度程序
部署调度程序结合了命令模式 [36]和活动对象模式 [37]。单个部署操作（例如，实例安装、实例连接等）封装在Action对象中，以及任何所需的元数据。每个单独的部署操作都是对安装处理程序上方法的调用，因此无需为每个潜在的部署目标重写这些操作。错误处理和日志记录逻辑也完全包含在单个操作中，进一步简化了LocalityManager。
单个操作（例如，安装组件或创建连接）由可配置的线程池计划执行。根据应用程序需求，此池可以提供用户选择的单线程或多线程行为。此线程池还可以用于实现更复杂的调度行为，例如基于优先级的调度算法，该算法根据计划中存在的元数据动态重新排序组件实例的安装。
LocalityManager确定在部署的每个特定阶段执行哪些操作，并为每个指令创建一个Action对象。然后将这些操作传递给部署调度程序以执行，而主控制线程等待来自部署调度程序的完成信号。完成后，LocalityManager从已完成的操作中获取返回值或错误代码，并完成部署阶段。
为了在同一节点上的LocalityManager实例之间提供并行性，LE-DAnCE部署调度程序也用于NodeApplication的实现中，以及LocalityManager进程的安装处理程序。在此级别使用部署调度程序有助于克服在执行节点级部署时出现的主要延迟源。与组件实例所需的部署时间相比，生成LocalityManager实例可能需要大量时间，因此并行化此过程可以在应用程序部署每个节点上具有许多LocalityManager进程时实现显着的延迟节省。
总而言之，部署事件的动态重新排序和LocalityManager实例的并行安装是一种很有希望的方法，可以改善SEAMONSTER域中的部署延迟。通过将高优先级附加到关键部署事件（例如，观察当前自然现象的传感器的激活或配置更改），DAnCE可以帮助确保及时满足关键任务需求。此外，这种设计带来的并行性可以通过允许其他LocalityManager实例在其中一个实例因加载新的组件实现而被I/O阻塞时执行来减少延迟，或者通过利用更新的多核嵌入式处理器来减少延迟。
本章概述了部署和配置引擎（DAnCE），它是OMG部署和配置规范的实现。作为一种研究工具，DAnCE用于演示在DRE系统中部署和配置（D&C）基于组件的应用程序的新技术。虽然它的性能对于出版物和演示所需的狭窄和集中的演示来说是令人满意的，但当应用于更大规模的生产DRE系统时，它的性能并不令人满意。一些因素，包括不断变化的架构所有权和DAnCE开发以演示为中心的性质，导致一些糟糕的设计选择在早期就根深蒂固在其架构和设计中，严重阻碍了性能。
描述了一个DAnCE的典型用例，在本例中为东南阿拉斯加科学、电信、教育和研究监测网络（SEAMONSTER）平台，以突出DAnCE中存在的许多优化机会。受此用例的启发，本文描述了我们如何应用网络领域的一系列优化原则来重新评估和重新设计DAnCE的设计和实现，以弥补上述缺陷。此外，我们描述了三个额外的优化原则：处理并行化、同步和关注点分离。这些额外的模式——与初始目录中描述的模式结合——用于开发LE-DAnCE，它大大提高了DAnCE的性能和可靠性。原始模式目录以及我们的补充内容的摘要显示在。同样，对性能增强结果的全面定量讨论在 [27]中进行了描述。
| 模式 | 说明 | DaNCE中的示例 |
|---|---|---|
| 避免浪费 | 避免明显的浪费 | 解析部署计划时预分配内存。 |
| 时间上的转移 | 及时转移计算（/预计算、惰性求值、共享开支、批处理） | 将部署计划预转换为二进制格式， 可能预计算计划拆分. |
| 放宽规范 | 放宽规范（以确定性换取时间，以准确性换取时间，并及时转移计算） | 可能预计算计划拆分. |
| 利用其他组件 | 利用其他系统组件（利用局部性、以内存换取速度、利用硬件） | （n/a） |
| 添加硬件 | 添加硬件以提高性能 | （n/a） |
| 高效的例程 | 创建高效的例程 | XML-IDL数据绑定 |
| 避免通用性 | 避免不必要的通用性 | 优化计划解析 |
| 规范与实现 | 不要混淆规范和实现 | LocalityManager |
| 传递提示 | 在接口中传递诸如提示的信息 | 可能用于预计算计划拆分 |
| 传递信息 | 在协议头中传递信息 | （n/a） |
| 预期用例 | 优化预期情况 | XML-IDL数据绑定 |
| 利用状态 | 添加或利用状态以提高速度 | 在计划分析期间预分配子计划。 |
| 自由度 | 优化自由度 | LocalityManager安装处理程序 |
| 利用有限的宇宙 | 对有限的宇宙使用特殊技术 | （n/a） |
| 高效的数据结构 | 使用高效的数据结构 | 优化XML-IDL数据绑定 |
| 面向并行化设计 | 优化面向并行化的设计 | 并行处理子计划 |
| 避免同步 | 避免同步和锁定 | 在计划分析期间异步访问父计划。 |
| 分离关注点 | 使用严格的关注点分离来模块化架构 | Locality Manager |
根据我们在本章中将描述的优化应用于LE-DAnCE并观察结果的经验，我们学习了以下经验教训
利用并行化是一个关键的优化机会。随着多核处理器成为即使是嵌入式设备的标准功能，算法和流程的设计必须能够利用此功能至关重要。在优化算法和流程以实现并行化时，谨慎地应用同步，因为不正确地使用锁会导致并行系统以串行方式运行，或者更糟糕的是，以微妙的方式发生故障。
在可能的情况下，将耗时的操作从关键路径中移出。虽然我们对D&C流程的计划分析部分的优化（在优化计划分析中描述）有效地减少了大规模部署的总部署延迟，但可以通过进一步应用及时转移模式来实现额外的改进。就像优化部署计划解析中描述的XML解析问题一样，此操作的结果在生成XML计划时很可能固定下来。此过程可以类似地进行预计算并提供给D&C基础设施以进一步节省延迟。传递这些预计算的计划（全局拆分和本地拆分）将是传递提示优化模式的一个示例应用程序。
流程的串行执行是DRE系统中性能问题的重大来源。在设计分布式系统时以串行方式执行任务提供了显着的概念和实现简单性。但是，这种简单性通常会带来明显的性能损失。通常，异步交互的额外复杂性非常值得付出额外的复杂性。
缺乏明确的架构和技术领导力不利于开源项目。开发人员通常会参与开源项目以解决一个狭窄的问题，并在不久之后离开。如果没有明确的领导力，个别贡献者做出的糟糕的架构和技术决策最终会滚雪球般地发展成一个几乎无法使用的项目。
TAO、CIAO和LE-DAnCE可在开源形式从download.dre.vanderbilt.edu下载。
[1]G. T. Heineman和B. T. Councill，基于组件的软件工程：将各个部分整合在一起。Addison-Wesley，2001年。
[2]A. Akkerman，A. Totok和V. Karamcheti，“分布式环境中J2EE应用自动动态部署的基础设施”，载于第3届组件部署国际研讨会（CD 2005），法国格勒诺布尔，2005年，第17-32页。
[3]D. Suri，A. Howell，N. Shankaran，J. Kinnebrew，W. Otte，D. C. Schmidt和G. Biswas，“使用自适应网络架构的车载处理”，载于第六届年度NASA地球科学技术会议论文集，2006年。
[4]J. White，B. Dougherty，R. Schantz，D. C. Schmidt，A. Porter和A. Corsaro，“高度复杂分布式系统的研发挑战和解决方案：中间件视角”，Springer互联网服务与应用期刊关于中间件未来的特刊，第2卷，第3期，2011年12月。
[5]D. C. Schmidt，B. Natarajan，A. Gokhale，N. Wang和C. Gill，“TAO：面向模式的对象请求代理，用于分布式实时和嵌入式系统”，IEEE分布式系统在线，第3卷，第2期，2002年2月。
[6]软件集成系统研究所，“组件集成ACE ORB（CIAO）”。www.dre.vanderbilt.edu/CIAO，范德比尔特大学。
[7]轻量级CCM FTF便捷文档，Ptc/04-06-10。对象管理组，2004年。
[8]G. Deng，J. Balasubramanian，W. Otte，D. C. Schmidt和A. Gokhale，“DAnCE：一个支持QoS的组件部署和配置引擎”，载于第3届组件部署研讨会论文集（CD 2005），2005年，第67-82页。
[9]基于组件的分布式应用的部署和配置，v4.0，文档formal/2006-04-02。OMG，2006年。
[10]G. Varghese，网络算法：设计快速网络设备的跨学科方法。旧金山，CA：Morgan Kaufmann出版商（爱思唯尔），2005年。
[11]V. S. Pai，P. Druschel和W. Zwaenepoel，“IO-Lite：一个统一的I/O缓冲和缓存系统”，ACM计算机系统汇刊，第18卷，第1期，第37-66页，2000年。
[12]M. Accetta，R. Baron，W. Bolosky，D. Golub，R. Rashid，A. Tavanian和M. Young，“Mach：UNIX开发的新内核基础”，载于1986年夏季USENIX技术会议和展览论文集，1986年，第93-112页。
[13]D. D. Clark和D. L. Tennenhouse，“新一代协议的架构考虑”，载于通信架构和协议研讨会论文集（SIGCOMM），ACM，1990年，第200-208页。
[14]M. Shreedhar和G. Varghese，“使用赤字轮询实现高效的公平排队”，载于SIGCOMM ’95：计算机通信应用、技术、架构和协议会议论文集，ACM出版社，1995年，第231-242页。
[15]M. Degermark，A. Brodnik，S. Carlsson和S. Pink，“用于快速路由查找的小型转发表”，载于ACM SIGCOMM ’97计算机通信应用、技术、架构和协议会议论文集，ACM出版社，1997年，第3-14页。
[16]J. Hasan和T. N. Vijaykumar，“动态流水线：使IP查找真正可扩展”，载于SIGCOMM ’05：2005年计算机通信应用、技术、架构和协议会议论文集，ACM出版社，2005年，第205-216页。
[17]P. Druschel和L. L. Peterson，“Fbufs：一个高带宽跨域传输工具”，载于第14届操作系统原理研讨会论文集（SOSP），1993年。
[18]N. C. Hutchinson和L. L. Peterson，“x-Kernel的设计”，载于SIGCOMM ’88研讨会论文集，1988年，第65-75页。
[19]S. McCanne和V. Jacobson，“BSD数据包过滤器：一种用于用户级数据包捕获的新架构”，载于冬季USENIX会议论文集，1993年，第259-270页。
[20]J. C. Mogul，R. F. Rashid和M. J. Accetta，“数据包过滤器：一种用于用户级网络代码的高效机制”，载于第11届操作系统原理研讨会论文集（SOSP），1987年。
[21]D. R. Engler和M. F. Kaashoek，“DPF：使用动态代码生成实现快速、灵活的消息多路分解”，载于ACM SIGCOMM ’96计算机通信评论会议论文集，ACM出版社，1996年，第53-59页。
[22]Y. Rekhter，B. Davie，E. Rosen，G. Swallow，D. Farinacci和D. Katz，“标签交换架构概述”，IEEE会刊，第85卷，第12期，第1973-1983页，1997年12月。
[23]D. D. Clark，V. Jacobson，J. Romkey和H. Salwen，“TCP处理开销分析”，IEEE通信杂志，第27卷，第6期，第23-29页，1989年6月。
[24]S. Sahni和K. S. Kim，“用于IP查找的多比特Trie的高效构建”，IEEE/ACM网络汇刊，第11卷，第4期，第650-662页，2003年。
[25]G. Varghese和T. Lauck，“散列和分层定时轮：用于高效实现计时器工具的数据结构”，IEEE网络汇刊，1997年12月。
[26]W. R. Otte，A. Gokhale和D. C. Schmidt，“基于组件的企业分布式实时和嵌入式系统中的可预测部署”，载于第14届国际ACM Sigsoft基于组件的软件工程研讨会论文集，ACM，2011年，第21-30页。
[27]W. Otte，A. Gokhale，D. Schmidt和A. Tackett，“基于组件的企业分布式实时和嵌入式系统中高效且确定性的应用程序部署”，Elsevier信息与软件技术期刊（IST），第55卷，第2期，第475-488页，2013年2月。
[28]D. ~. R. Fatland，M. ~. J. Heavner，E. Hood和C. Connor，“SEAMONSTER传感器网络：一年后的经验教训和机遇”，AGU秋季会议摘要，2007年12月。
[29]J. S. Kinnebrew，W. R. Otte，N. Shankaran，G. Biswas和D. C. Schmidt，“分布式实时和嵌入式传感器网络系统中的智能资源管理和动态自适应”，范德比尔特大学，ISIS-08-906，2008年。
[30]A. Gokhale，B. Natarajan，D. C. Schmidt，A. Nechypurenko，J. Gray，N. Wang，S. Neema，T. Bapty和J. Parsons，“CoSMIC：一个用于分布式实时和嵌入式组件中间件和应用程序的MDA生成工具”，载于2002年OOPSLA关于模型驱动架构环境下的生成技术研讨会论文集，ACM，2002年。
[31]J. White，B. Kolpackov，B. Natarajan和D. C. Schmidt，“使用特定词汇的XML语言绑定减少应用程序代码复杂性”，载于ACM-SE 43：第43届年度东南地区会议论文集，2005年。
[32]通用对象请求代理：架构和规范版本3.1，第2部分：CORBA互操作性，OMG文档formal/2008-01-07。对象管理组，2008年。
[33]A. Dubey，W. Emfinger，A. Gokhale，G. Karsai，W. Otte，J. Parsons，C. Czabo，A. Coglio，E. Smith和P. Bose，“用于分段航天器的软件平台”，载于2012年IEEE航空航天会议论文集，IEEE，2012年，第1-20页。
[34]A. B. Arulanthu，C. O’Ryan，D. C. Schmidt，M. Kircher和J. Parsons，“用于CORBA异步消息传递的可扩展ORB架构的设计和性能”，载于2000年中间件会议论文集，纽约帕利塞兹：ACM/IFIP，2000年。
[35]ObjectWeb联盟，“CARDAMOM - 用于构建任务和安全关键型应用程序的企业中间件”。cardamom.objectweb.org，2006年。
[36]E. Gamma，R. Helm，R. Johnson和J. Vlissides，设计模式：可复用面向对象软件的元素。艾迪生-韦斯利，1995年。
[37]D. C. Schmidt，M. Stal，H. Rohnert和F. Buschmann，面向模式的软件架构：并发和网络对象的模式，第2卷。纽约：Wiley & Sons，2000年。
