Cisco ACI（Application Centric Infrastructure，应用中心基础设施）是以 APIC 控制器为核心的数据中心网络架构，所有配置都以策略对象的形式暴露在 MIT（管理信息树）上，可以通过 REST API 进行增删改查。要在 Vue 3 中做一个 ACI 管理控制台，本质上就是用前端工程化的方式，把这些 REST API 的调用、认证、状态管理做得可靠、可维护。这篇文章围绕认证、请求封装、数据解析和性能四个方面，给出一套完整的落地思路。
一、环境搭建与跨域代理：先解决浏览器同源限制
APIC 控制器的 REST API 默认走 HTTPS，且不会为你的开发环境配置 CORS 响应头，直接在浏览器里 fetch 大概率会被同源策略拦下来。开发阶段最省事的做法是利用 Vite 的代理能力，把请求转发到 APIC：
// vite.config.js
export default defineConfig({
server: {
proxy: {
'/api/aci': {
target: 'https://apic.example-ipipp.com',
changeOrigin: true,
secure: false, // APIC 常用自签名证书，开发环境关闭证书校验
rewrite: path => path.replace(/^\/api\/aci/, '/api')
}
}
}
})这样做的好处是前端代码里只写相对路径，浏览器认为请求是同源的，不会触发预检问题。而到了生产环境，代理这一层交给 Nginx 来做，配置思路完全一致，用 proxy_pass 把 /api/aci 指向 APIC 的地址即可。需要注意 APIC 的证书问题在生产环境同样存在，要么在 Nginx 侧配置 proxy_ssl_verify off，要么把 APIC 的证书导入信任链，后者更规范一些。
另外一个细节是超时设置。ACI 中某些查询（比如遍历整个 fvBD 的子对象）在大型 Fabric 上可能响应较慢，axios 的默认超时往往不够用，建议针对列表类请求单独放宽到 30 秒以上，避免用户看到一片空白却没有任何错误提示。
二、Token 认证与请求封装：用 Pinia 管理会话
APIC 的认证方式是先用用户名密码换一个 Token，之后所有请求在 Cookie 里带上 APIC-cookie 即可。Token 有有效期，过期后接口会返回 403，所以需要一套完整的获取、携带、刷新逻辑。先看登录换取 Token 的请求：
// src/api/auth.js
import request from './request'
export function login(username, password) {
// aaaLogin 是 APIC 的标准认证端点
return request.post('/aaaLogin.json', {
aaaUser: {
attributes: {
name: username,
pwd: password
}
}
})
}拿到响应后，从 imdata[0].aaaLogin.attributes.token 中提取 Token，存入 Pinia 的 store。相比直接塞 localStorage，放在 Pinia 里可以配合响应式做全局的登录状态联动，比如 Token 失效时自动把界面切回登录页。接着是 axios 实例的封装，关键在请求拦截器中注入 Token，响应拦截器中捕获 403 并触发重新认证：
// src/api/request.js
import axios from 'axios'
import { useAciStore } from '@/stores/aci'
const request = axios.create({ baseURL: '/api/aci', timeout: 30000 })
request.interceptors.request.use(config => {
const store = useAciStore()
if (store.token) {
config.headers.Cookie = `APIC-cookie=${store.token}`
}
return config
})
request.interceptors.response.use(
res => res.data,
err => {
if (err.response?.status === 403) {
const store = useAciStore()
store.forceLogout() // Token 失效，回到登录页
}
return Promise.reject(err)
}
)
export default request这里有个容易踩的坑：浏览器默认不允许 JS 直接设置 Cookie 请求头，这条路径只在 Node 环境（SSR 或 Electron）下直接可行。纯浏览器场景下，更稳妥的方案是让代理层（Vite 代理或 Nginx）负责注入 Cookie 头，或者改用 DevCookie 加 APIC-challenge 的 URL 参数方式传递 Token，具体以你使用的 APIC 版本文档为准。封装的原则是：认证细节对业务组件完全透明，组件只关心调用哪个接口。
三、解析 imdata 响应与对象树渲染
ACI 的 REST API 返回的 JSON 都是 imdata 数组结构，每个元素是一个对象类型作为 key，内部再分 attributes 和 children。比如查询租户列表，返回结构大致如下：
// GET /api/node/class/fvTenant.json 响应示例
{
"imdata": [
{
"fvTenant": {
"attributes": {
"dn": "uni/tn-production",
"name": "production",
"descr": "生产租户"
},
"children": []
}
}
],
"totalCount": "1"
}直接在组件里逐层取值会让代码变得难以复用，建议在 API 层做一次扁平化转换，把 imdata 映射成组件友好的数组：
// src/api/tenant.js
import request from './request'
export async function fetchTenants() {
const data = await request.get('/node/class/fvTenant.json')
return (data.imdata || []).map(item => {
const attrs = item.fvTenant.attributes
return {
name: attrs.name,
dn: attrs.dn, // dn 是 ACI 中对象的唯一标识，后续查询子对象全靠它
descr: attrs.descr,
childCount: item.fvTenant.children?.length ?? 0
}
})
}dn（Distinguished Name）是理解 ACI 数据模型的关键，它形如 uni/tn-production/BD-web，天然表达了对象在 MIT 中的层级位置。做树形界面时，可以直接基于 dn 的路径关系构建父子映射，也可以用 query-target-filter 参数让 APIC 在服务端完成过滤，减轻前端处理压力。两者结合效果最好：粗粒度查询走服务端过滤，精细的层级组装在前端用 dn 完成。
四、性能优化：虚拟滚动与按需加载子对象
大型 Fabric 上一个租户可能有几千个 EPG、上万条终结点，一次性拉全量数据再渲染，界面必卡。优化分两个方向。第一是按需加载：树形控件只在节点展开时才请求其 children，APIC 支持针对单个 dn 查询子对象，比如 /mo/uni/tn-production.json?rsp-subtree=children，这样首屏只加载租户列表，展开时再取下一层，体验会流畅很多。
第二是渲染层的虚拟滚动。Element Plus 的 el-table-v2 或者 vueuse 配合自研方案都能实现只渲染可视区域内的行。对于表格类视图，虚拟滚动配合分页请求，可以稳定支撑万级数据的展示。此外还可以订阅 APIC 的事件流（通过 WebSocket 监听 /socket classlist.json 的事件），实现拓扑和表格的实时刷新，替代低效的定时轮询。轮询如果一定要用，注意间隔不要太激进，给 APIC 留出喘息空间，否则高频查询本身就会成为控制器负载的来源。
五、总结
用 Vue 3 工程化对接 Cisco ACI，核心工作量不在 UI，而在于把认证、代理、数据转换这三件事封装干净。Vite 代理解决开发期跨域，Nginx 接管生产转发；Pinia 集中管理 Token 生命周期；API 层统一解析 imdata 并基于 dn 构建层级；最后用按需加载和虚拟滚动扛住大数据量。这套结构搭好之后，后续增加新的管理页面，只需要在 API 目录下新增一个模块文件，组件层几乎零成本接入，这正是工程化带来的收益。