Skip to Content
核心概念平台架构

平台架构

本页从使用者视角讲清 Argus 的数据怎么流动、由哪些部分组成。你不需要理解每个进程的内部实现， 但了解”数据从哪来、到哪去、从哪查”能帮你更快定位问题。工程级详设见仓库 docs/07-design/。

一条数据的旅程

端上 / 后端 SDK  →  Ingestion 上报网关  →  ClickHouse 统一存储  →  Console / MCP 查询
   （采集）          （HMAC 校验+配额）       （按事件类型分区）        （人 / AI 看数据）
  1. 采集：一个 SDK 同时采日志 / 崩溃 / APM / 埋点 / 反馈，共享同一份签名、批量、降级队列。见 统一 SDK 框架。
  2. 摄取：所有数据走同一个 Ingestion 网关，差异只在 channel / event_type 字段。网关做 HMAC 签名校验 与配额拦截。
  3. 存储：统一进 ClickHouse，按事件类型分区。查询接口共享。
  4. 查询：Console（人）与 MCP Server（AI）复用同一套底层查询能力。

这套”多能力统一接入框架”是 Argus 的核心设计：新增一种能力只需写各自的 Collector 与 Schema，不必 重造网络 / 存储 / 认证。

服务组成：11 个真实服务 + 4 项折叠能力

Argus 后端由 11 个独立服务进程组成。另有 4 项能力（计费 / 行为分析 / 实验 / 发布）没有独立 进程，而是折叠进既有服务——功能都是真实可用的，只是在架构上按”读 / 写归位、复用进程”的原则落点。

独立服务职责
API Gateway边缘路由 + 鉴权，所有 /v1/* 统一入口
Ingestion高性能上报网关（日志 / 崩溃 / APM / 埋点 / trace / 反馈写入 + 配额拦截）
Identity多租户、认证、RBAC、2FA、组织 / 项目 / 成员（并承接计费写侧）
Observability Core日志 / 崩溃 / APM / Trace 查询层（并承接行为分析读侧、实验结果统计、发布健康分）
Config远程配置 / Feature Flag / 能力可见性（并承接实验定义分流、发布版本灰度回滚）
Feedback用户反馈与工单
Recall日志回捞
MCP ServerMCP 协议外部接入（AI 只读查询）
CopilotConsole 内嵌 AI 助手（含 AI Verify 子模块）
Notification告警与通知
Symbolicator崩溃堆栈符号化

4 项折叠能力的落点：

能力折叠进
计费 / 配额Identity（订阅 / 用量 / 配额）+ Ingestion（热路径拦截）
行为分析Observability Core（聚合查询）+ Ingestion（/v1/track 采集）
A/B 实验Config（定义 + 分流）+ Observability Core（显著性统计）
版本与发布Config（版本 / 灰度 / 回滚规则）+ Observability Core（健康分）

排障时若需定位”某能力归哪个服务的日志 / API”，以仓库 docs/07-design/README.md §0 折叠总表 为权威依据。

双区部署

Argus 支持海外区与中国区双轨部署，数据驻留在用户首次创建组织时锁定的区域，跨区数据不自动同步。 合规覆盖 PIPL（中国）/ GDPR / CCPA / SOC2（海外）。自托管方式见 自托管部署。

延伸阅读

DSN 与 HMAC 签名术语表