分布式反应系统软件架构详解
1. 数据位置与状态信息
在相关系统中，为了区分不同的报告，会为其附上唯一的索引。通过关联和识别过程，单个航班的进度会被记录在分类轨道（sort track）中。状态向量通常包含相关航班号的位置和速度信息，这些信息是通过连续测量计算得出的。时间戳则用于标识状态向量最后一次更新的时间。
2. 应用交互与协调原语
2.1 应用与共享数据空间的交互
应用程序主要通过读写操作与共享数据空间进行交互。在该系统中，没有全局删除元素的操作，而是使用覆盖机制隐式地移除数据。这种机制常用于随着系统环境的演变，用更新的值替换旧数据。此外，应用程序在读取数据后，可以将其从视图中隐藏，这使得应用程序能够通过连续的读取操作逐步遍历共享数据空间。
共享数据空间建模为一个动态变化的信息存储库，数据只能被读取或写入，这与数据元素代表可被应用程序实际消耗的共享资源的观点不同。
2.2 协调原语的定义
系统扩展了现有的（顺序）编程语言，引入了用于创建进程和与共享数据空间交互的协调原语，具体如下：
-
create(f)
：从名为
f
的可执行文件创建一个新的应用程序进程，并与现有应用程序并行运行。
-
write(a, x)
：将类型为
a
的元素
x
插入共享数据空间。如果共享数据空间中已经存在与
x
具有相同键值的同类型元素，则用
x
替换该现有元素。
以下是一些类型定义的示例：
sort flightplan
key flightnumber : string
departure : time
arrival : time
aircraft : string
sort track
key flightnumber : string
timestamp : time
state : vector
sort report
key index : integer
measurement : vector
timestamp : time
-
read(a, q, t)：从共享数据空间读取满足查询q的类型为a的元素。查询以类型a的记录字段上的谓词形式表述。如果没有匹配的元素，操作将阻塞，直到有匹配元素可用或超时时间t到期。如果超时发生，操作将返回超时错误。超时是一个可选参数，如果省略，读取操作将一直阻塞，直到有匹配元素可用。如果找到多个匹配元素，将非确定性地选择一个。 -
get(a, q, t)：操作与read操作相同，不同之处在于从共享数据空间返回的元素将从应用程序的视图中隐藏，即应用程序不能再次读取相同的元素。
2.3 覆盖机制的冲突问题与解决
在将数据元素插入共享数据空间时，覆盖机制可能会导致冲突。如果两个不同的应用程序同时写入相同类型和相同键值的数据元素，其中一个元素将以非确定性的顺序覆盖另一个元素，从而导致其中一个更新丢失。为避免这种非确定性行为，系统架构规定对于每种类型，最多只能有一个应用程序写入具有相同键值的数据元素。
2.4 航空交通控制示例
以航空交通控制为例，考虑一个跟踪航班号为
n
的应用程序进程。该应用程序持续从监视雷达读取新报告，并相应地更新航班号为
n
的轨道数据。其代码示例如下：
t := get(track, flightnumber = n);
repeat
r := get(report, true);
if correlates(r, t) then
update(t, r);
write(track, t);
end if
until terminated(t);
该应用程序首先从共享数据空间读取航班号为
n
的初始轨道数据，然后进入一个循环。在循环中，它先读取一个新报告
r
，如果报告与当前轨道
t
相关联，则使用
update(t, r)
过程更新轨道
t
，并将更新后的轨道插入共享数据空间，替换之前的轨道数据。这个过程会一直重复，直到轨道
t
终止。
3. 架构的细化
3.1 分布式软件架构
为了实现共享数据空间在计算机系统网络上的分布，对基本架构进行了细化，引入了两个额外的组件：代理（agents）和通信网络。
每个应用程序进程只与一个代理交互。代理包含一个本地数据库，用于存储数据元素，并具备处理应用程序进程所有通信需求的处理设施。所有代理都是相同的，不需要关于应用程序进程或其通信需求的先验信息。代理之间的通信通过消息传递机制建立，消息由互连的通信网络处理。通信网络必须支持广播，最好还支持代理的直接寻址和多播。
应用程序进程通过之前介绍的交互原语与分配的代理进行交互，这种交互对于共享数据空间模型是透明的，应用程序进程继续在逻辑上的共享数据空间上操作。
代理是应用程序进程的被动服务器，但积极参与建立和维护所需的代理间通信。通信需求由代理根据应用程序进程发出的读写操作动态推导得出。代理管理通信的协议基于订阅范式，具体如下：
-
写操作
：应用程序执行写操作时，数据元素被传输到其代理，代理首先将元素存储到本地数据库中，覆盖任何相同类型和相同键值的现有元素。
-
读请求
：应用程序发出读请求时，其代理首先检查这是否是对该特定类型的首次请求。如果是，代理会在网络上广播该类型的名称。其他代理收到消息后，会将执行广播的代理注册为该类型的订阅者。然后，每个代理会检查其本地数据库中是否包含该请求类型的、由其应用程序进程先前写入的数据元素，如果有，则将这些元素的副本传输给新订阅的代理。此后，任何后续写入的该请求类型的数据将立即转发给所有订阅的代理。
每个订阅的代理将初始和后续传输的副本存储到本地数据库中，覆盖任何相同类型和相同键值的现有数据。在所有传输过程中，使用的协议会保留应用程序写入相同类型数据元素的顺序。这种机制结合架构的设计约束（每种类型最多只有一个应用程序写入具有相同键值的数据元素），保证了所有代理上的覆盖操作按相同顺序进行。否则，代理之间的通信是异步进行的。
读请求的搜索由每个代理在本地进行。如果没有找到匹配的元素，操作将暂停，直到有该请求类型的新数据到达或指定的超时时间到期。
get
操作的处理与
read
操作类似，不同之处在于返回的数据元素会从代理的本地数据库中移除。
这种协议使得共享数据空间在网络中的代理之间有选择地复制。每个代理的本地数据库只包含其服务的应用程序实际读写的类型的数据。这种方法对于大规模分布式系统是可行的，因为应用程序通常只对所有类型的一小部分感兴趣。而且，代理之间交换数据的通信模式相对静态，只有在系统操作模式改变或系统配置发生变化（如扩展或故障恢复）时才会改变。因此，从性能角度来看，维护订阅注册是有益的。每次引入新类型后，经过短暂的初始阶段，代理将适应新的通信需求，并利用这些知识将新生成的数据分发给所有持有订阅的代理。由于订阅注册由代理动态维护，系统配置的所有更改都将自动导致通信模式的调整。
需要注意的是，不需要将数据元素分发给订阅代理的集合的操作组合成一个原子事务，这使得数据可以异步分发，数据实际生产和使用之间的延迟主要取决于消费应用程序进程，对于定时要求在毫秒级的分布式嵌入式系统来说，这种延迟上限是可以接受的。
以下是分布式软件架构的简单流程图：
graph LR
classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
classDef agent fill:#FFF6CC,stroke:#FFBC52,stroke-width:2px;
classDef network fill:#FFEBEB,stroke:#E68994,stroke-width:2px;
P0(应用程序进程 P0):::process --> A0(代理 A0):::agent
P1(应用程序进程 P1):::process --> A1(代理 A1):::agent
Pn(应用程序进程 Pn):::process --> An(代理 An):::agent
A0 <-->|消息传递| N(通信网络):::network
A1 <-->|消息传递| N
An <-->|消息传递| N
subgraph 共享数据空间
style 共享数据空间 fill:#ffffff,stroke:#000000,stroke-width:1px
end
3.2 时间方面
最初引入的共享数据空间建模为一个持久存储：一旦写入的数据将一直可供所有应用程序使用，直到被新实例覆盖或通过执行
get
操作从应用程序视图中隐藏。数据的持久性在时间上解耦了应用程序，例如，一个在数据写入时不存在的应用程序可以读取该数据，反之，最初写入数据的应用程序在数据实际被读取时可能已经不存在。
嵌入式系统领域的应用程序主要处理代表连续量的数据实例，这些数据要么是从系统环境中采样的观测值，要么是通过数据关联和相关过程从这些样本中推导出来的。数据本身的结构相对简单，只有几种数据类型，而且由于样本的易失性，只有最近的值才是有意义的。然而，样本可能会以非常短的间隔进入系统，因此足够的吞吐量和低延迟是关键特性。此外，嵌入式系统还会维护离散信息，这些信息要么直接与外部事件相关，要么是通过对采样输入的定性推理得出的。
基于这些观察，对共享数据空间进行了细化，以支持易失性和持久性数据。之前介绍的类型定义的基本格式扩展了一个额外的属性，用于指示类型的实例是易失性还是持久性的。对于持久性数据，读写操作的语义保持不变。而对于易失性数据，只有在数据写入时存在的应用程序集合才能看到它，之后创建的应用程序将无法读取该数据。
以航空交通控制示例为例，
report
类型可以分类为易失性，而
track
和
flightplan
类型是持久性的。因此，跟踪过程不会收到在其创建之前由监视雷达生成的报告。在跟踪过程创建后，它首先获取初始轨道数据，然后等待下一个报告可用。
由于初始轨道数据只生成一次，跟踪过程必须保证能够访问它，否则可能会无限期阻塞。这意味着
track
类型必须是持久性的。
用于管理计算机系统网络中数据分布的基于订阅的协议可以进行细化，以利用易失性和持久性数据的区别。由于易失性数据只对写入时存在的应用程序可用，因此不需要保留历史记录。因此，如果应用程序写入一个数据元素，它将立即转发给订阅的代理，而不会在应用程序的本地数据库中存储副本。这种优化减少了所需的存储量，并且消除了应用程序对某一类型执行首次读取操作时任何先前写入的数据元素的初始传输。这使得新创建的应用程序能够无初始延迟地集成到通信模式中，更适合处理易失性数据的典型定时特性。
3.3 容错性
由于大规模嵌入式系统对可用性和安全性有严格要求，因此需要冗余来掩盖操作期间的硬件故障。容错性通常是一个非常复杂的要求，在软件中只能部分解决。在该系统中，可以对代理进行细化，以提供容错行为的机制，该机制基于数据和进程的复制。通过使容错性成为软件架构的一个特性，可以显著降低应用程序的设计复杂度。
假设处理单元发生故障时会停止执行，并且通信不会无限期失败，数据也不会损坏。如果网络中的一个处理单元发生故障，存储在该单元中的数据将永久丢失。解决方案是将每个数据元素的副本存储在不同的故障单元中。之前介绍的基于订阅的协议已经实现了一种复制存储方案，其中每个数据元素的副本存储在生产者和每个消费者处。然而，基本协议通常不足以实现容错性数据存储。例如，如果特定类型的数据元素已经写入但尚未被读取，这些元素仅存储在生产者处。如果某一类型的生产者和消费者恰好位于同一处理单元上，也会出现类似的问题。
为了解决这些问题，在架构中扩展了一种额外类型的组件：持久数据库。该组件执行专门版本的订阅协议。启动时，持久数据库会在网络上广播每个持久性类型的名称。由于代理集合执行的订阅协议，应用程序写入的任何持久性类型的数据元素将自动转发到持久数据库。可以在不同的处理单元上运行一个或多个持久数据库实例，具体取决于系统所需的可用性级别。此外，还可以将两个或多个持久数据库加载不同的类型名称集合，从而实现持久性数据的分布式存储。
当处理单元发生故障时，在该单元上执行的应用程序也会丢失。架构可以进行细化，以支持应用程序在网络中不同处理单元上的被动和主动复制。
-
被动复制
：只有一个进程实际执行，而一个或多个备份进程处于离线状态，存储在主内存或二级存储中。当执行活动进程的处理单元发生故障时，其中一个备份进程将被激活。为了能够恢复故障进程的内部状态，每个被动复制的应用程序在每次状态更新时都需要将其状态的副本写入共享数据空间。内部状态可以由一个或多个持久性类型表示。当备份进程被激活时，它将首先从共享数据空间恢复当前状态，然后继续执行。
-
主动复制
：当时间至关重要时，进程的主动复制通常是更可行的解决方案。在这种情况下，同一应用程序的多个实例在不同的处理单元上并行执行，所有实例都进行读写操作。主动复制通常用于不能容忍服务中断的情况。
基于订阅的协议可以进行细化，以透明地支持主动复制。如果复制应用程序的某个实例执行写操作，其代理会为数据元素附加一个唯一的复制索引作为键字段。该索引允许订阅的代理区分从复制应用程序收到的各种副本。当收到读请求时，代理首先尝试返回具有固定默认索引的匹配元素。如果在适当的超时时间到期后，请求的元素仍然不可用，则返回具有非默认索引的匹配元素。从那时起，假设对应于默认索引的应用程序已经失败，并相应地更新订阅注册。实际返回的数据元素的索引现在成为新的默认索引。
以下是支持容错性的分布式软件架构的简单示意图：
graph LR
classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
classDef agent fill:#FFF6CC,stroke:#FFBC52,stroke-width:2px;
classDef network fill:#FFEBEB,stroke:#E68994,stroke-width:2px;
classDef db fill:#CCFFCC,stroke:#73A6FF,stroke-width:2px;
P0(应用程序进程 P0):::process --> A0(代理 A0):::agent
P1(应用程序进程 P1):::process --> A1(代理 A1):::agent
Pn(应用程序进程 Pn):::process --> An(代理 An):::agent
A0 <-->|消息传递| N(通信网络):::network
A1 <-->|消息传递| N
An <-->|消息传递| N
N <-->|数据传输| DB(持久数据库):::db
subgraph 共享数据空间
style 共享数据空间 fill:#ffffff,stroke:#000000,stroke-width:1px
end
3.4 系统修改和扩展
在嵌入式系统领域，由于对可用性的要求，通常需要在当前系统保持在线的情况下支持修改和扩展。需要考虑两种不同的情况：
-
系统扩展
：升级是对系统的扩展，引入新的应用程序和类型，但不对现有系统进行进一步修改。由于代理动态维护订阅注册，当前协议可以在不进行进一步细化的情况下处理这种情况。安装并启动新应用程序后，它将自动集成到系统中。
-
现有应用程序修改
：这种情况显然更困难。一种特殊但重要的修改类别可以通过对代理进行简单的细化来处理。例如，考虑通过用一个实现相同功能但使用更好算法的应用程序进程替换现有应用程序进程来升级系统的问题，这可以提高系统的性能和质量。
分布式反应系统软件架构详解
4. 总结与展望
通过上述对分布式反应系统软件架构的详细介绍，我们可以看到该架构在多个方面进行了精心设计和优化，以满足大规模分布式嵌入式系统的需求。下面对架构的关键特性和优势进行总结，并对未来的发展方向进行展望。
4.1 架构关键特性总结
| 特性 | 描述 |
|---|---|
| 分布式存储 | 通过代理和通信网络实现共享数据空间的分布式存储，支持广播、直接寻址和多播，提高了系统的可扩展性和灵活性。 |
| 订阅范式 | 基于订阅范式的通信协议，使得数据在代理之间有选择地复制，减少了不必要的数据传输，提高了系统性能。 |
| 易失性和持久性数据支持 | 扩展共享数据空间以支持易失性和持久性数据，满足不同类型数据的处理需求，优化了数据的使用和管理。 |
| 容错机制 | 通过数据和进程的复制，以及持久数据库的引入，提供了容错能力，确保系统在硬件故障时的可用性和稳定性。 |
| 系统可扩展性 | 支持系统的修改和扩展，能够在系统在线的情况下引入新的应用程序和类型，或对现有应用程序进行升级。 |
4.2 未来发展方向
- 更高效的通信协议 ：随着系统规模的不断扩大和数据量的增加，进一步优化通信协议以减少延迟和提高吞吐量是未来的一个重要方向。例如，研究更智能的订阅和数据分发策略，以更好地适应不同的应用场景。
- 实时性增强 ：对于一些对实时性要求极高的嵌入式系统，需要进一步优化架构以满足更严格的时间约束。这可能涉及到对数据处理和通信流程的重新设计，以及对硬件资源的更高效利用。
- 安全性提升 ：在分布式系统中，数据的安全性是至关重要的。未来的架构需要加强数据的加密和访问控制，防止数据泄露和恶意攻击。
- 与新兴技术的融合 ：随着人工智能、物联网等新兴技术的发展，将这些技术与分布式反应系统软件架构相结合，可以为系统带来更多的功能和价值。例如，利用人工智能算法进行数据预测和分析，提高系统的智能化水平。
5. 实际应用案例分析
为了更好地理解分布式反应系统软件架构的实际应用，下面以一个智能交通系统为例进行分析。
5.1 系统概述
智能交通系统旨在通过信息技术提高交通效率、减少拥堵和提高安全性。该系统包含多个传感器、监控设备和应用程序，需要实时处理大量的交通数据。
5.2 架构应用
- 数据存储与共享 ：采用分布式软件架构，将交通数据存储在多个代理的本地数据库中，并通过通信网络实现数据的共享。不同的应用程序可以根据需要订阅感兴趣的数据类型，提高了数据的利用效率。
- 易失性和持久性数据处理 ：交通数据中的实时路况信息属于易失性数据，只有在短时间内才有价值；而历史交通数据则属于持久性数据，可以用于数据分析和预测。通过对共享数据空间的细化，支持了不同类型数据的处理。
- 容错机制 ：在智能交通系统中，硬件故障可能会导致数据丢失或系统故障。通过数据和进程的复制，以及持久数据库的使用，确保了系统在故障时的可用性和数据的完整性。
- 系统扩展 ：随着智能交通系统的发展，可能需要引入新的传感器和应用程序。由于架构支持系统的扩展，新的组件可以轻松地集成到现有系统中，而不会影响系统的正常运行。
5.3 实际效果
通过应用分布式反应系统软件架构，智能交通系统取得了显著的效果。系统的响应速度加快，能够及时处理大量的交通数据；数据的准确性和完整性得到了提高，为交通管理决策提供了更可靠的依据；系统的可扩展性使得系统能够随着业务的发展不断升级和完善。
6. 操作指南与最佳实践
为了帮助开发者更好地应用分布式反应系统软件架构，下面提供一些操作指南和最佳实践。
6.1 开发环境搭建
- 选择合适的编程语言和开发工具，确保支持架构中定义的协调原语。
- 配置通信网络，确保代理之间能够正常进行消息传递。
- 部署持久数据库，根据系统的可用性要求确定数据库的数量和分布。
6.2 应用程序开发
- 遵循架构的设计约束，确保每个类型最多只有一个应用程序写入具有相同键值的数据元素，避免覆盖冲突。
- 在处理易失性和持久性数据时，根据数据的特性合理选择读写操作，确保数据的正确使用。
- 对于容错机制的应用，根据系统的实时性要求选择合适的复制策略（被动复制或主动复制），并确保数据的一致性。
6.3 系统测试与优化
- 进行全面的系统测试，包括功能测试、性能测试和容错测试，确保系统的稳定性和可靠性。
- 根据测试结果进行系统优化，例如调整通信协议的参数、优化数据存储策略等，以提高系统的性能和效率。
6.4 最佳实践总结
- 定期清理过期数据，避免占用过多的存储空间。
- 监控系统的运行状态，及时发现和处理潜在的问题。
- 保持代理和应用程序的版本一致性，避免因版本不兼容导致的问题。
7. 结论
分布式反应系统软件架构通过对共享数据空间的分布式存储、订阅范式的通信协议、易失性和持久性数据的支持、容错机制以及系统的可扩展性等方面的设计，为大规模分布式嵌入式系统提供了一个高效、可靠和灵活的解决方案。在实际应用中，该架构已经取得了显著的效果，能够满足智能交通、工业自动化等领域的需求。
随着技术的不断发展，分布式反应系统软件架构也将不断演进和完善。未来，我们可以期待该架构在实时性、安全性和智能化等方面取得更大的突破，为更多的应用场景提供支持。
graph LR
classDef startend fill:#F5EBFF,stroke:#BE8FED,stroke-width:2px
classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px
classDef decision fill:#FFF6CC,stroke:#FFBC52,stroke-width:2px
A([开始]):::startend --> B(开发环境搭建):::process
B --> C(应用程序开发):::process
C --> D(系统测试与优化):::process
D --> E{是否通过测试?}:::decision
E -->|是| F(系统部署与运行):::process
E -->|否| C
F --> G(定期维护与监控):::process
G --> H(系统升级与扩展):::process
H --> I([结束]):::startend
通过以上的介绍和分析，我们对分布式反应系统软件架构有了更深入的了解。希望这些内容能够为开发者和研究人员提供有益的参考，推动分布式反应系统的发展和应用。
扫一扫
11万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
