Arova Nexus 系統架構

系統架構

Arova Nexus 系統架構

Arova Nexus — Phase 0 Product Definition ｜ 2026-03-31

版本： v1.0 ｜ 狀態： 提議（Proposed）｜ 最後更新： 2026-04-23
關聯文件： TECH_STACK.md（技術選型鎖定）、AI_Ops_Agent_Architecture.md（Agentic Framework 層深入設計）、Arova_Nexus_PRD_v1.3.md

1. 概述

Arova Nexus 是 AI-Native 的 IT 維運平台。目標使用者是「凌晨 3 點被吵醒的工程師」——他們要答案，不是更多介面。產品的核心差異化來自五層協同運作：使用者從 UI 發出意圖、治理層確認授權、Agent 編排層驅動多 Agent 協作、智能層用語意搜尋和 RAG 查資料、最底層的資料與整合層串接 Graylog / LibreNMS / CMDB 等既有系統。

本文件是整個系統的架構地圖，描述「層之間如何分工、元件怎麼放、事件如何流動」。細節由各層的獨立文件承擔：

AI Agent 內部設計 → AI_Ops_Agent_Architecture.md
技術選型鎖定 → TECH_STACK.md
UX 行為 → Nexus_MVP_UX_Blueprint.md
決策追溯 → adr/

1.1 不可妥協的架構約束

約束	說明	對應 PRD
On-Prem First	所有元件必須能在客戶地端（Docker Compose / K8s）運行	Ch19
資料不離開客戶環境	AI 模型、向量庫、日誌全部在內網	Ch20
模組化	可選模組可獨立啟停，未授權模組不能影響 Core	Ch6
Event-Centric	跨模組通訊以 Event 為核心，不直接互相呼叫	Ch16
Hybrid AI	預設 on-prem LLM，external LLM 可選（客戶決定）	Ch20

2. 五層系統架構

各層職責、元件、跨層互動詳見下文。

3. L1 — Interaction Layer（互動層）

定位：使用者和外部系統進入 Arova Nexus 的所有入口。

3.1 元件

元件	技術	職責
Web App	Next.js 15 + shadcn/ui + Tailwind 4	主要 UI，Dashboard、工單、事件、知識庫、設定等所有模組介面
AI Copilot	`@ai-sdk/react` + `@mastra/ai-sdk`	聊天式主操作介面（右下懸浮）+ 輔助面板雙模式
Email Channel	SMTP Ingress + 解析器	Email → 工單（J09 Email-First AI 服務台）
Webhook Ingress	Hono API endpoint	Graylog / LibreNMS / 第三方告警來源
REST API	Hono（Mastra 內建）	對外 API（SE-019 API Key + JWT 雙認證）
MCP Client	Model Context Protocol	讓 IDE 類客戶端能用 Arova 資料（未來拓展）

3.2 設計原則

AI Copilot 永遠在（Nexus Core 必備），功能解鎖隨授權模組動態展開（PRD Ch6）
所有 UI 路徑都走 REST API，Web App 不直接碰資料庫，便於未來切 React Native / mobile app
Email 入口是無需登入的，透過 Token 連結讓外部使用者填表（J02, J09）

3.3 與其他層的互動

下行 → L2 Gateway：所有請求都先過 Auth + Licensing + Rate Limit Middleware
不直接穿透 L3/L4/L5：UI 看到的永遠是 L2 封裝後的 API

4. L2 — Governance Layer（治理層）

定位：系統的「守門員」。所有請求進來要先通過這一層才能到 L3 Agent 或 L5 資料層。

4.1 元件

元件	技術 / 儲存	職責
API Gateway	Hono middleware 串接	路由、統一入口
Auth Service	JWT + Refresh Token + Redis session	登入、SSO、MFA（Phase 2）
RBAC Engine	PostgreSQL（users / roles / permissions）	6 預定義角色（RBAC1）+ 自訂角色繼承
License Service	RSA-SHA256 驗證 + heartbeat	離線 .lic / 線上授權碼雙模式；模組啟停
Audit Log	PostgreSQL（append-only 表）+ Syslog 轉發	SE-010~017，不可修改或刪除，SHA-256 hash chain（Phase 2）
Rate Limiter	Redis（token bucket）	預設 100 req/min（IG-008），API Key 可提升
Observability	Logs / Metrics / Health checks	Prometheus 相容 metrics endpoint
AI Governance	Agent 自主權等級 + Kill Switch	Level 0~3 設定 + 全域/單一 Agent 停止（AIN-010）

4.2 設計原則

所有未授權模組的 API 回傳 HTTP 403 + module_not_licensed（LI-012）
稽核日誌是唯一不可旁路的寫入路徑：不論操作來自 UI、API、Agent、排程，都寫入同一張表
AI Agent 動作也受 RBAC 檢查：Agent 代表哪個 agent_id 執行，其許可權限依 agent 設定（AIN-014）

4.3 關鍵資料模型

licenses（授權資訊 + 模組列表）
users / roles / role_permissions / user_roles
audit_logs（不可修改，SE-010）
ai_feedback（AIN-021 隱式回饋）

5. L3 — Agentic Framework Layer（Agent 編排層）

定位：整個產品的大腦。AI Agent 在這一層工作，Workflow Engine 編排多步驟自動化。

5.1 元件

元件	技術	職責
Mastra AI	`@mastra/core`	Agent 框架；提供 Agent 生命週期、Tool、Memory
Supervisor Agent	Mastra Agent	意圖辨識 + 路由到專職 Agent
Triage Agent	Mastra Agent	工單自動分類、優先級、路由（即時觸發，SD+)
Correlation Agent	Mastra Agent	警報合併、根因判斷（即時觸發，Incident+)
Preventive Agent	Mastra Agent	反覆事件模式偵測（定時，KB+）
Compliance Agent	Mastra Agent	合規檢查、法規比對（Compliance+)
Anomaly Detection	輕量規則+LLM	每 60 秒掃系統指標，找異常
Workflow Engine	Mastra Workflow	節點式流程執行、Dry-Run、版本控制、排程
Agent Memory	PostgreSQL + Redis	對話歷史、上下文、工作記憶
MCP Tools	Mastra MCP integration	讓 Agent 能呼叫 L5 的資料 / 外部工具
Agent-to-Agent (A2A)	Event Bus 上的 Agent 消息	Agent 協作
Logic Apps / Triggers	Mastra Workflow triggers	由 Event 或排程觸發多 Agent workflow

5.2 Agent 自主權等級（AIN-010）

Level	行為	MVP
L0 觀察	只產生報告，不採取動作	✅
L1 通知	產生建議 + 通知工程師，不執行	✅ 預設
L2 輔助	信心度 ≥ 門檻時自動執行（限預核准操作）	✅ 可升級
L3 自主	全自動執行（限 admin 預核准 Runbook）	Phase 2

5.3 設計原則

Agent 和使用者共享 LLM；AI 配額達 80% 時 Agent 降級讓路給使用者 Copilot（AI Strategy, PRD Ch20）
Level 3 Agent 僅執行 admin 預核准的 Workflow 清單（護欄）
Kill Switch：admin 可一鍵停止全部 Agent 或單一 Agent
Agent 依模組授權解鎖：Triage 需 Service Desk、Correlation 需 Incident，未授權時該 Agent 不啟動

5.4 與其他層的互動

向上 → L2：所有 Agent 動作記稽核日誌、受 RBAC 約束
向下 → L4：透過 RAG / Vector Search 取得語意相關資料
向下 → L5：透過 MCP Tools 讀寫底層資料（e.g. 建立工單、查 CMDB）

6. L4 — Intelligence Layer（語意智能層）

定位：把 L5 的結構化/非結構化資料，轉成 Agent 能用的語意搜尋結果。

6.1 元件

元件	技術	職責
LLM Service	On-prem（Ollama / vLLM）+ External（OpenAI/Anthropic/Azure，optional）	推論；Agent 推理、摘要、分類、RAG 問答
Embedding Service	BGE-M3 / E5-large on CPU	為所有核心實體產生 embedding 向量
Vector Database	pgvector（PostgreSQL 擴充）	儲存和查詢向量
RAG Pipeline	Mastra RAG	Retrieval + Re-rank + LLM 生成
Semantic Graph	pgvector 關聯 + Apache AGE（Phase 2）	跨實體語意圖譜（事件 ↔ 工單 ↔ KB ↔ 資產）
Prompt Template Service	Mastra Prompt + PostgreSQL	Prompt 範本管理 + 版本控制 + A/B 測試
Briefing Engine	排程背景任務 + Cache	預先計算每日簡報（DB-001）
Feedback Collector	Event pipeline	顯式（👍/👎）+ 隱式（Agent 建議被覆寫）+ 結果（事件被關閉）

6.2 Hybrid LLM 策略

預設路徑：                      可選路徑（客戶選擇）：
┌──────────┐  ┌──────────┐     ┌──────────┐  ┌────────────┐
│  Client  │→ │  Local   │     │  Client  │→ │  External  │
│  Request │  │  Ollama  │     │  Request │  │  LLM API   │
└──────────┘  └──────────┘     └──────────┘  └────────────┘
                  ↓                              ↓
            地端推論（預設）              外網 HTTPS（客戶允許時）
            不離開客戶環境                客戶自簽 API Key

6.3 設計原則

Embedding 永遠在地端（輕量，跑 CPU 即可）
LLM 選擇由客戶決定，預設地端；金融業通常選地端，一般企業可能用 external
Semantic Graph 先用 pgvector 關聯模擬，Phase 2 升級到 Apache AGE
所有實體的 embedding 延遲 < 5 秒（背景更新，不卡使用者操作）

7. L5 — Data & Integration Layer（資料與整合層）

定位：資料儲存 + 外部系統整合。Arova 是「接收 + 分析 + 建議 + 編排」的大腦，不是監控 agent 本身——所以 Graylog / LibreNMS 是外部依賴，不是我們的組件。

7.1 內部儲存

儲存	技術	用途
PostgreSQL 16+	單一實例 / primary+replica	主要業務資料（工單、事件、KB、CMDB、使用者、稽核等）
pgvector	PostgreSQL 擴充	向量儲存（由 L4 使用）
Redis 7+	單點 / Sentinel	Session、快取、Rate limit、Agent Memory、排程佇列
Object Storage	MinIO（on-prem）/ S3（optional）	附件、KB 文件、報表 PDF
Eventhouse / Event Bus	Redis Streams / NATS（未定）	跨模組 Event 通訊

7.2 外部整合（Integration 模組）

系統	方向	用途
Graylog	Pull（REST API）+ Push（Webhook）	Log 搜尋、告警接收
LibreNMS	Pull（REST API）+ Push（Webhook）	設備健康、拓撲、告警接收
AD / LDAP	Pull（LDAP bind）	SSO、使用者同步
SSO	SAML 2.0 / OIDC	單一登入
Slack / Teams / Line	Webhook + Bot API	通知推送 + 對話整合
SMTP / Email	SMTP Client + IMAP（Ingress）	通知 + Email 入口
ServiceNow	REST API（optional）	歷史工單參考（僅 Phase 2 考慮）

7.3 設計原則

所有外部整合包在 Integration 模組內，未授權時 L3 Agent 看不到對應 MCP Tool
Graylog / LibreNMS 是事實來源；Arova 不重寫監控邏輯，也不存設備指標歷史資料（只存事件摘要）
所有外部 API 呼叫都 retry + timeout + circuit breaker

8. 跨層互動模式

8.1 典型請求流（UI → Agent → Data）

User: "幫我查 DB-PROD-01 最近的 slow query"
  │
L1: AI Copilot 送出 intent → REST /api/v1/ai/chat
  │
L2: JWT 驗證 → RBAC 檢查（has incident:read）→ Audit log start
  │
L3: Supervisor Agent 解析 intent → 路由到 Triage/Correlation 或 Research Agent
       │
       ├→ L4: RAG 查 KB（VPN 問題 SOP）
       │
       ├→ L5: Graylog API 查 slow query log（via MCP Tool）
       │
       └→ L5: CMDB 查 DB-PROD-01 資產資訊
  │
L3: Agent 整合結果 → LLM 產生回答
  │
L2: Audit log end（含 Agent 推理、信心度）
  │
L1: AI Copilot 渲染回答

8.2 Event-Centric 流（Webhook 告警 → 事件建立）

Graylog → Webhook (POST /api/v1/webhook/graylog)
  │
L1: Webhook Ingress 驗證 signature
  │
L2: Rate limit + audit log
  │
L5: 寫入 Event Bus（alert.received）
  │
L3: Correlation Agent 訂閱 alert.received
     → 查 L4 KB + L5 CMDB 拓撲
     → 判斷是否和現有事件合併
     → 寫入 Event Bus（incident.created 或 incident.merged）
  │
L3: Triage Agent 訂閱 incident.created
     → 分類嚴重度、指派工程師
     → 寫入 Event Bus（incident.assigned）
  │
L2: Notification Service 訂閱 incident.assigned → 發 Email/Slack

8.3 模組授權檢查流

核心邏輯：

Request → License Middleware →
  ├─ 檢查 module 是否在 licenses.active_modules
  ├─ 檢查是否過期（licenses.expires_at）
  ├─ 檢查使用量配額（users / ai_calls / storage）
  └─ pass → 續前進；fail → 403 + module_not_licensed

9. 部署視圖（Deployment View）

9.1 Phase 1 — Docker Compose（單節點）

┌─────────────────────────────────────────────────────────┐
│  客戶地端伺服器（單節點，建議 16 vCPU / 64GB RAM / SSD）│
│                                                         │
│  ┌─────────┐  ┌─────────┐  ┌─────────┐  ┌──────────┐  │
│  │ Next.js │  │ Mastra  │  │Postgres │  │  Redis   │  │
│  │  Web    │  │ Backend │  │+pgvector│  │          │  │
│  └─────────┘  └─────────┘  └─────────┘  └──────────┘  │
│                                                         │
│  ┌─────────┐  ┌─────────┐  ┌─────────┐                 │
│  │  MinIO  │  │  Ollama │  │ Workers │                 │
│  │         │  │  (LLM)  │  │(排程/MQ)│                 │
│  └─────────┘  └─────────┘  └─────────┘                 │
│                                                         │
│  docker-compose.yml 一鍵啟動                            │
└─────────────────────────────────────────────────────────┘
                          ↓ HTTPS only
        ┌────────────────────────────────────────┐
        │  客戶既有基礎設施（Arova 不部署）       │
        │  Graylog  │  LibreNMS  │  AD/LDAP    │
        └────────────────────────────────────────┘

Ollama LLM 部署：獨立 GX10 / A100 主機，透過 REST API 與 Backend 溝通（見 AI_Ops_Agent_Architecture.md 第八章）。

9.2 Phase 2 — Kubernetes（叢集）

同樣元件，拆分為獨立的 Deployment + Service + HPA，PostgreSQL / Redis 改 Operator 管理。Vector DB 可考慮拆到獨立的 Qdrant / Milvus。

10. 非功能性需求（NFR）對照

NFR	目標	實現層
回應時間	UI p95 < 500ms；AI Copilot 首 token < 2s	L1 streaming + L3 stream 回應
吞吐量	單節點 100 req/s；1000 告警/分鐘	L2 rate limit + L5 Event Bus 緩衝
可用性	Phase 1：99% ｜ Phase 2：99.9%	Phase 2 叢集 + Redis Sentinel
資料保護	Audit log 不可修改；授權檔不可竄改	L2 append-only + RSA 簽章
合規	稽核軌跡保留 180 天可調整	L2 SE-014
災備	每日 pg_dump + MinIO 對外儲存	Ops 文件另述

11. 模組與層的責任矩陣

模組	L1	L2	L3	L4	L5
Nexus Core	全部 UI + Copilot	全部	Supervisor + Anomaly	Embedding + Briefing	PG + Redis
Service Desk	工單頁面	RBAC	Triage Agent	RAG 對工單	tickets 表
Incident	事件詳情頁	RBAC	Correlation Agent	RAG 對事件	incidents 表 + Event Bus
Automation	Workflow 編輯器	Runbook 審核	Workflow Engine	Prompt Template	workflows 表
Knowledge	KB 瀏覽器	RBAC	Preventive Agent	RAG Pipeline	documents 表 + pgvector
CMDB	資產 + 拓撲頁	RBAC	-	Semantic Graph	assets 表
Analytics Pro	報表頁	RBAC	-	彙整計算	analytics 表
Integration	連接器設定頁	API Key	MCP Tools 註冊	-	外部系統

12. 技術決策索引（見 `adr/`）

ID	決策	狀態
ADR-001	選 Mastra AI 作為 Agent 框架	已採納
ADR-002	用 pgvector 不另起 Qdrant / Milvus	已採納
ADR-003	Hybrid LLM（on-prem 預設 + external 可選）	已採納

13. 開放問題 / Phase 2+ 待解

Event Bus 實作：目前候選 Redis Streams vs NATS JetStream，待 POC
Semantic Graph：pgvector 關聯 → 何時升級到 Apache AGE
Multi-tenant：Phase 3 SaaS 模式的 tenant 隔離策略
Agent Marketplace：第三方 Agent 插件機制（Phase 2+）
MCP Client 角色：是否要讓客戶 IDE 能直接和 Arova 對接

14. 與參考架構的對照（微軟 Telecom NOA）

NOA 層	Arova Nexus 對應	差異
UI for AI	L1 Interaction Layer	NOA 綁 Microsoft 生態（Copilot/Outlook/Teams）；Arova 是獨立 Web + 開放 API
Agentic Governance	L2 Governance Layer	NOA 用 Azure Foundry Control Plane；Arova 自研（on-prem 限制）
Agentic Framework	L3 Agent 編排層	NOA 用 Microsoft Agent Framework；Arova 用 Mastra AI（TypeScript 一致化）
Telco IQ	L4 Intelligence Layer	NOA 分 Fabric IQ / Foundry IQ 兩層；Arova 合併為單層簡化
Universal Data Access	L5 Data & Integration Layer	概念完全相同

本質差異：NOA 是 Azure 生態綁定的 cloud-first 架構；Arova 是 on-prem first 架構，所有層都必須能在客戶內網運行，這約束了每一層的技術選擇（例如為何選 pgvector 不用 Azure AI Search）。

← 上一篇Arova Nexus 產品發展策略 — 從客戶 MVP 到完整產品下一篇 →Arova Nexus 技術堆疊規格