软件架构概述

Juniper Apstra 的系统架构包含以下两个主要组件：

Apstra 服务器
Apstra 设备代理

Apstra 管理的每台设备都需要在其上安装 Apstra 代理。Apstra 服务器和所有 Apstra 代理充当分布式操作系统。

TCP 连接是节点之间的唯一要求。

Apstra 将高层次的业务需求（称为“意图”）转换为全面运行的数据中心网络环境。

Juniper Apstra 架构基于分布式状态管理基础设施，而该基础设施可以描述为：具有水平可扩展和容错内存数据存储的、以数据为中心的通信结构。特定参考设计应用的所有功能都通过一组无状态代理实现。代理通过基于发布 - 订阅的逻辑通信通道进行相互通信，并在本质上实现应用逻辑。

每个 Apstra 参考设计应用只是上述无状态代理的集合。从广义上讲，Apstra 中有三类代理：

交互（Web）代理负责与用户交互，即，获取用户输入，并向用户提供来自数据存储的相关上下文。
应用代理负责通过订阅输入实体和生成输出实体来执行特定于应用域的数据转换。
设备代理驻留在受托管的物理或虚拟系统（如交换机、服务器、防火墙、负载平衡器甚至控制器）上（或作为其代理），用于使用本机（特定于设备的）接口（通常是供应商的 API）写入配置和收集遥测数据。

这种交互可以通过一个示例来说明，该示例描述了 Apstra 数据中心网络参考设计应用的一部分。

Web 代理可接受用户输入，而在本例中，是指 L3 Clos 交换矩阵的设计，其中包含主干、叶和主干与叶之间的链路的数量，以及用于交换矩阵 IP 和 ASN 编号的资源池。Web 代理将此意图作为一组图形节点和关系及其各自的属性发布到数据存储中。

构建代理会订阅此意图，并且：

执行正确性和完整性验证
从资源池中分配资源

假设验证通过，构建代理将该意图与资源分配一起发布到数据存储中。

配置呈现代理订阅构建代理的输出。对于每个节点而言，配置代理将获取相关数据（包括资源在内），并将其与配置模板合并。

预期代理还订阅构建代理的输出，并生成需要满足的期望以验证结果。

设备遥测代理会订阅预期代理的输出，并开始收集相关遥测数据。IBA 探针负责处理原始遥测数据，并将其与预期进行比较，然后发布异常。

根本原因识别（RCI）代理将分析异常，并将其分类为症状、影响和已确认的根本原因。

代理通过发布实体和订阅实体中的更改，通过基于属性的接口（因此称为以数据为中心）进行通信。以数据为中心还意味着，数据定义属于是框架的一部分，并通过定义实体来实现（例如，与基于消息的系统相反）。

以数据为中心的发布 - 订阅系统部受基于消息的系统的问题所影响。在基于消息的系统中，消息的数量早晚会超过系统存储或使用这些消息的能力;处理此问题很困难，因为必须重放消息的历史记录才能达到一致的状态。以数据为中心的系统对状态变化的激增具有弹性，因为它基本上只依赖于最后的状态。这种状态将获取重要的上下文，并抽象出导致它的所有可能的（和不相关的）事件序列。

困难问题（例如，弹性、容错）代表所有代理解决一次。然后，典型的体系结构由几个无状态代理组成，这些代理可以在发生故障时重新启动，只需从数据库中重新读取它们所订阅的状态，即可从中断的位置恢复。