📚 课程目录第2章 EOS系统架构与运维接口

2. EOS系统架构与运维接口

在单台交换机上敲命令，和在两千台交换机上做运维，是两种完全不同的工程问题。理解 EOS 的软件架构与管理接口分层，是决定自动化方案能否规模化落地的前提。EOS 的核心设计思想是"控制面与状态面分离、所有状态集中可编程访问"，这一思想直接决定了 CLI、eAPI、SNMP、gNMI 各自的适用边界。

EOS 软件架构：从内核到 Sysdb 的分层

EOS 基于 Linux 内核构建，用户态运行着一组相互独立的 Agent 进程。每个 Agent 负责一个功能域，例如 Bgp、Ospf、Intf、Lag、Acl、Stp、Lldp、Config 等。这些 Agent 之间不直接互相调用，而是通过一个中心化的状态数据库——Sysdb——交换信息。Sysdb 是 EOS 架构的中枢，它保存了设备当前所有可读写的状态路径，路径形如 /Sysdb/interface/status/eth1/operStatus、/Sysdb/bgp/status/peer/10.0.0.1/state。

这种设计的工程意义在于：任何管理接口（CLI、eAPI、SNMP、gNMI、OpenConfig）本质上都是对 Sysdb 路径的读写封装。CLI 命令 show interfaces eth1 status 最终读取的是 Sysdb 中的接口状态路径；eAPI 的 JSON-RPC 请求同样映射到这些路径；gNMI 的 Get/Subscribe 也落在同一套路径体系上。因此，掌握 Sysdb 路径模型，等于掌握了所有接口的公共语义层。

各管理接口在大规模运维中的定位

CLI 是最直观的接口，适合人工排障和一次性验证。但在两千台设备的规模下，逐台 SSH 执行 CLI 存在明显瓶颈：会话建立开销大、输出为人类可读文本而非结构化数据、解析脆弱。CLI 在大规模运维中的正确定位是"兜底与验证"，而不是批量配置的主通道。

eAPI 是 EOS 原生的 JSON-RPC 接口，通过 HTTP/HTTPS 暴露。它支持 runCmds 执行 show 命令并返回 JSON，也支持 get/set 直接操作 Sysdb 路径。相比 CLI，eAPI 返回结构化 JSON，解析稳定，且单次请求可批量执行多条命令。在中等规模（数百台）自动化中，eAPI 是性价比最高的选择。典型调用如下：

POST https://switch-a/api/v1/json
{
  "jsonrpc": "2.0",
  "method": "runCmds",
  "params": {
    "version": 1,
    "cmds": ["show interfaces eth1 status", "show bgp summary"],
    "format": "json"
  },
  "id": 1
}

SNMP 是传统网管协议，通过 MIB 暴露指标，支持 Trap 主动上报。它的优势是生态成熟、监控平台普遍支持；劣势是 OID 语义晦涩、轮询效率低、不适合配置下发。在大规模运维中，SNMP 适合作为"存量监控兼容层"，用于对接既有 NMS，而不应作为新建自动化体系的主接口。

gNMI / OpenConfig 是面向流式遥测的现代接口，基于 gRPC，支持 Get、Set、Subscribe 三种操作。Subscribe 模式可以让设备主动、周期性地推送状态变化，替代传统轮询。在两千台设备的规模下，轮询模型会产生巨大的采集压力，而 gNMI Subscribe 配合 CloudVision 等控制器，可以把采集模式从"拉"转为"推"，显著降低控制面负载。gNMI 的路径模型与 OpenConfig YANG 对齐，跨厂商语义一致，是超大规模运维的首选。

接口选型的工程判断

把上述接口放在同一张决策表里，可以形成清晰的选型依据：

接口	传输	数据形态	适合场景	规模上限参考
CLI	SSH/Telnet	文本	人工排障、单点验证	数十台
eAPI	HTTP/HTTPS	JSON	批量配置、结构化采集	数百台
SNMP	UDP	OID/标量	存量监控对接	数百台（轮询受限）
gNMI	gRPC	YANG/流式	大规模遥测、配置同步	数千台以上

判断依据不是"哪个接口更先进"，而是"采集模式是拉还是推、数据是否需要结构化、设备数量是否超过轮询可承受范围"。当设备数超过约 500 台且需要秒级状态感知时，gNMI Subscribe 几乎是唯一可行方案。

Sysdb 路径的实操观察

理解 Sysdb 最直接的方式是在实验设备上观察路径。以下命令通过 eAPI 读取接口操作状态，返回的 JSON 中 operStatus 字段即来自 Sysdb 的 /Sysdb/interface/status/eth1/operStatus：

curl -k -u admin:pass https://switch-a/api/v1/json \
  -d '{"jsonrpc":"2.0","method":"runCmds","params":{"version":1,
       "cmds":["show interfaces eth1 status"],"format":"json"},"id":1}'

# 返回示例（节选）
{"result":[{"interfaceStatuses":{"Ethernet1":{
  "linkStatus":"connected","operStatus":"up",
  "lineProtocolStatus":"up","mtu":9214}}}]}

若改用 gNMI 读取同一状态，路径为 /interfaces/interface[name=Ethernet1]/state/oper-status，返回值为 UP。两者语义一致，只是编码与路径命名不同。这种"同一状态、多接口暴露"的特性，正是 EOS 架构分层带来的运维红利：自动化平台可以按场景选择接口，而不必为每个接口重建状态模型。

在生产环境中启用 eAPI 或 gNMI 前，必须确认管理面 ACL 已限制源地址，并优先使用 HTTPS/gRPC over TLS。管理接口一旦暴露在非受控网络，等同于把 Sysdb 的读写能力对外开放。

综上，EOS 的软件架构把状态集中到 Sysdb，再由 CLI、eAPI、SNMP、gNMI 等接口以不同协议和编码对外暴露。大规模运维的接口策略应当是：以 gNMI 流式遥测承担状态采集，以 eAPI 承担批量配置与结构化查询，以 SNMP 兼容存量监控，以 CLI 作为人工兜底。理解这一分层，后续的自动化工具选型与脚本设计才有稳定的语义基础。