📚 课程目录第1章 CloudVision平台架构与核心组件

1. CloudVision平台架构与核心组件

CloudVision 是 Arista 面向数据中心与园区网络的统一运营与自动化平台。它并不是一个“大而全”的单体应用，而是由一组职责清晰的微服务协同工作：有的负责与交换机建立连接并采集数据，有的负责把海量遥测数据写入状态数据库，有的负责对外暴露 API，有的负责把数据渲染成可视化界面。理解这些组件的分工与数据流向，是后续做自动化、排障和容量规划的基础。

微服务架构：控制面与数据面分离

CloudVision 的微服务架构可以粗略分为三层：接入层、处理层和存储/服务层。接入层由 Telemetry 采集组件构成，负责与 EOS 设备建立 gNMI、SNMP、Syslog、eAPI 等通道；处理层由各类消费者服务组成，负责解析、归一化、聚合和告警判定；存储与服务层则包含状态数据库、配置数据库、API 网关和 UI 后端。各服务通过消息总线或内部 gRPC 通信，单个服务重启不会导致整个平台不可用，这是微服务架构在运维上的核心价值。

需要特别注意的是，CloudVision 的“状态”与“配置”是两条独立的数据通路。配置通路走的是 Configlet、Container、Change Control 这条线，最终通过 eAPI 或 gNMI 下发到设备；状态通路走的是 Telemetry 采集线，数据只读、只入状态库。两条通路在 UI 上可能出现在同一个页面，但在后端是解耦的，排障时要先判断问题出在哪条通路上。

Telemetry 采集层：数据从哪里来

Telemetry 采集层是 CloudVision 的“感官”。它支持多种采集方式，实际部署中最常用的是 gNMI Dial-out 和 gNMI Dial-in 两种模式。Dial-out 模式下，交换机主动向 CloudVision 的 gNMI 端点推送数据，适合大规模、高频次采集；Dial-in 模式下，CloudVision 主动向设备订阅，适合设备数量较少或需要按需拉取的场景。

采集频率直接决定数据量和平台负载。以一台 32 端口 100G 交换机为例，如果对每个接口订阅 interface/counters 路径，采样间隔设为 10 秒，那么单台设备每天产生的样本数约为 32 × 8640 = 276480 条。若集群有 200 台这样的设备，日样本量接近 5500 万条。这个量级决定了状态数据库必须采用时序友好的存储结构，也决定了采集路径不能“全量订阅”，而应按业务重要性分级。

# 示例：在 EOS 上配置 gNMI Dial-out 到 CloudVision
management api gnmi
   transport grpc cv-telemetry
      vrf management
      destination 10.10.20.5 port 6030
   provider cv-telemetry
      source 10.10.20.1
!
telemetry
   subscription if-counters
      path /interfaces/interface/state/counters
      send-interval 10000
      destination cv-telemetry

上述配置中，send-interval 10000 表示 10 秒推送一次，destination 指向 CloudVision 的 gNMI 接收端点。配置完成后，可以在 CloudVision 的 Telemetry 状态页看到该设备的订阅状态、最近一次上报时间和样本速率。如果状态长期为 Disconnected，优先检查管理 VRF 路由、6030 端口可达性和证书是否过期。

状态数据库：运营数据的“唯一事实源”

状态数据库是 CloudVision 区别于传统网管的关键组件。它不只存“当前值”，还存“历史变化”。设备接口的 up/down 事件、CPU 利用率曲线、BGP 邻居状态翻转、光模块收发光功率，都会以时间序列形式写入。UI 上的拓扑着色、告警时间线、趋势图，本质上都是对状态数据库的查询结果。

状态数据库的写入压力主要来自 Telemetry 采集层，读取压力主要来自 UI 和 API。因此在实际运营中，如果发现 UI 加载缓慢，不一定是 UI 本身的问题，也可能是状态数据库的查询并发过高，或者某个采集路径的基数（cardinality）过大。例如对 /interfaces/interface/state/counters 做全接口订阅时，接口数量就是基数；如果设备有大量子接口或隧道接口，基数会迅速膨胀，进而拖慢写入和查询。

API 网关与 UI 交互层：人与平台的接口

API 网关是 CloudVision 对外的统一入口，提供 REST、gRPC 和 Streaming 三种主要接口形式。REST 适合配置下发和资源查询，gRPC 适合高频、低延迟的自动化调用，Streaming 适合订阅事件流。UI 交互层并不直接访问状态数据库，而是通过 API 网关获取数据，再在前端渲染。这种设计意味着：你在 UI 上看到的数据，理论上都可以通过 API 拿到，自动化脚本可以复现甚至超越 UI 的操作。

一个常见的实践是：先用 UI 确认某个指标的位置和含义，再打开浏览器开发者工具或 CloudVision 的 API Explorer，找到对应的 API 路径和参数，最后把该调用封装进自动化脚本。这样既降低了学习成本，也保证了自动化逻辑与人工判断的一致性。

组件角色与真实运营中的判断

把上述组件放回真实运营场景，可以形成一条清晰的判断链。当设备指标没有出现在 UI 上时，按数据流反向排查：先看 Telemetry 采集层是否收到该设备的订阅数据，再看状态数据库是否有对应时间序列写入，最后看 API 网关和 UI 是否能查询到。如果采集层正常但状态库没有数据，问题可能在解析或写入环节；如果状态库有数据但 UI 不显示，问题可能在 API 查询条件或前端过滤。

当配置没有生效时，则走另一条链：检查 Change Control 的任务状态，确认配置是否成功下发到设备，再登录设备查看 running-config 是否包含目标配置。两条链不要混用，否则容易在错误的方向上浪费时间。

状态通路是只读的，配置通路是读写的。排障时先判断“是看不到”还是“改不了”，再选择对应的排查链路，可以显著缩短定位时间。

最后需要建立的一个认知是：CloudVision 的微服务架构不是为了“看起来先进”，而是为了在设备规模增长、采集频率提高、自动化调用并发上升时，仍然能够通过横向扩展单个服务来消化压力。理解每个组件的职责边界和数据流向，才能在容量规划、故障定位和自动化设计中做出正确决策。