Skip to content
已上线

系统架构 — 集群 · GitOps · 监控

各服务共用的基础设施,一张图讲清

Lurus 采用混合云架构,基于 Kubernetes + GitOps 构建统一的服务部署和治理体系。12 个产品共享同一套账号、计费、记忆、LLM 网关与可观测性底座 —— 不是一堆独立服务的拼装,而是一张可以一次讲清的图。

12产品线共享同一底座
50+LLM 渠道per-channel 熔断
GitOps部署GHA → GHCR → ArgoCD

架构全景 ​

分层视图 从 C 端产品到运维底座,五层自上而下;下层为上层提供能力,上层不感知下层实现。

Lurus 平台分层五层自上而下:C 端产品层、B 端产品层、核心引擎层、基础设施层、运维底座。上层依赖下层,下层不感知上层。基础设施层是全平台共用的账号、计费、身份与通知底座,图中以强调色标出。每个产品方块标注了本站发布的成熟度:实线为已上线,虚线为开发中或内测。PLATFORM LAYERS依赖方向 ↓L1C 端产品层面向个人用户的成品应用LucrumLIVESwitchDEVCreatorDEVLutuBETAL2B 端产品层面向企业与开发者的服务Lurus HubLIVEForgeBETALumenDEVTallyBETAL3核心引擎层可脱离上层单独使用KovaDEV · 持久执行MemXDEV · 智能记忆L4基础设施层上面每一个产品都共用这一层账号与计费LIVE统一身份LIVE · OIDC通知platform 内置L5运维底座产品不感知的能力,非对外承诺项容器编排入口网关持续交付可观测LEGEND已上线开发中 / 内测全平台共用底座成熟度取自各产品页顶部的状态标
每个产品方块上的成熟度标(已上线 / 开发中 / 内测)取自本站产品数据的同一个字段,也就是各产品页顶部那枚状态标 —— 两处不会各说各话。第四层用强调色标出:它是上面每一个产品共用的账号、计费、身份与通知底座,「12 个产品共享同一套底座」这句话的实体就是它。最下面一层只画能力类别不点名工具,因为本站没有为具体运维工具承诺过可用性。成熟度真源 · docs/.vitepress/data/products.ts
文本版分层图(无障碍 / 复制用)
依赖方向 ↓ —— 上层依赖下层,下层不感知上层

┌──────────────────────────────────────────────────────────────────────┐
│ L1  C 端产品层     面向个人用户的成品应用                             │
│     Lucrum[已上线] · Switch[开发中] · Creator[开发中] · Lutu[内测]    │
├──────────────────────────────────────────────────────────────────────┤
│ L2  B 端产品层     面向企业与开发者的服务                             │
│     Lurus Hub[已上线] · Forge[内测] · Lumen[开发中] · Tally[内测]     │
├──────────────────────────────────────────────────────────────────────┤
│ L3  核心引擎层     可脱离上层单独使用                                 │
│     Kova[开发中, 持久执行] · MemX[开发中, 智能记忆]                   │
├══════════════════════════════════════════════════════════════════════┤
│ L4  基础设施层     上面每一个产品都共用这一层  ← 全平台共用底座        │
│     账号与计费[已上线] · 统一身份[已上线, OIDC] · 通知[platform 内置] │
├──────────────────────────────────────────────────────────────────────┤
│ L5  运维底座       产品不感知的能力,非对外承诺项                     │
│     容器编排 · 入口网关 · 持续交付 · 可观测                           │
└──────────────────────────────────────────────────────────────────────┘

方括号里的成熟度与各产品页顶部的状态标同源(docs/.vitepress/data/products.ts)。 L5 只列能力类别、不点名具体工具——本站没有为运维工具承诺过可用性。

设计原则 ​

五条原则 入口统一、模型统一、部署自动化、可观测一体化、故障可自愈。

核心设计

统一网关

Traefik 入口,TLS 终止,通配符证书自动管理

多模型 AI 网关

50+ LLM 渠道统一接入,跨三种上游 API 形态自动互转,per-channel 熔断保护

GitOps 部署

GitHub Actions → GHCR 容器镜像 → ArgoCD 自动同步

全栈可观测性

Prometheus 指标 + Grafana 仪表盘 + Loki 日志 + Jaeger 分布式追踪

高可用设计

渠道故障自动转移,优先级 + 权重路由,PodDisruptionBudget 保护

请求处理流程 ​

数据流 一次模型调用在打到上游之前,要按固定顺序穿过十道中间件;其中四处的**先后关系是有硬性理由的**,排错位就会静默出错。

Lurus Hub relay 请求链路一次 OpenAI 兼容的模型调用进入 Lurus Hub 后,按注册顺序依次经过十道中间件:标记响应格式、令牌鉴权、租户额度池闸、费用尖峰保护、权限校验、按模型限流、业务限流、并发占用上限(默认关闭)、选渠道分发,以及分发后才能生效的按模型维度限流;随后打到上游厂商适配器,响应原路返回调用方。RELAY REQUEST PATHCALLERAPI 调用方OpenAI-compatible SDKMIDDLEWARE CHAIN · 按注册顺序01标记响应格式StampRelayFormat102令牌鉴权TokenAuth03租户额度池闸PoolBalanceCheck204费用尖峰保护CostSpikeLimit05权限与套餐校验EntitlementCheck06请求速率限制ModelRequestRateLimit07业务维度限流BusinessRateLimit08并发占用上限RelayConcurrencyLimit · off309选渠道分发Distribute410按模型维度限流BusinessModelRateLimitUPSTM上游厂商适配器20+ vendors · 格式互转RESPONSELEGEND焦点 · 分发点默认关闭 · 需显式配置顺序有硬性约束 · 见下方说明
十道门按注册顺序执行,顺序不是随手排的 —— 圈出来的四处各有硬性约束,见下方说明。2b-svc-newhub · internal/adapter/handler/router/relay-router.go

图上圈出的四处顺序约束:

  1. 标记响应格式必须是第一个。 路由框架在挂载中间件时就把整条链快照下来了;晚于此处标记,后面任何一道门的拒绝响应都会用默认格式返回,调用方按自己的格式解析就会失败。
  2. 租户额度池闸必须夹在鉴权之后、费用尖峰保护之前。 它要读鉴权阶段才写入的租户上下文;而放在费用保护之前,是为了让额度耗尽能直接短路整条链,不再做后面那些检查。
  3. 并发占用上限默认是关的。 不显式配置每令牌 / 每租户的并发上限,这道门就不生效——它在图上是虚线,不要读成「平台默认给你兜住了并发」。
  4. 按模型维度限流只能挂在分发之后。 请求里的模型名要到选渠道那一步才进入上下文,挂在前面拿不到模型名,限流规则会静默失配。

选渠道阶段按模型名匹配可用渠道,支持优先级排序与权重随机分配;高优先级渠道故障时,per-channel 熔断器隔离故障渠道,流量切到备选。

技术栈总览 ​

技术选型 多语言混合栈,按业务匹配最合适的运行时。本表只列真正在跑的东西——写进来的每一项都能在集群里查到实例。

层级技术选型
后端服务Go (Gin)、Rust、Python (FastAPI)
前端React / Next.js / Vue 3 / Flutter
桌面应用Wails (Go + Web),单 exe 零依赖
数据库PostgreSQL (CNPG),按服务 schema 隔离
缓存Redis,按服务 DB 隔离
消息NATS JetStream (事件广播)
身份认证标准 OIDC —— vendor-neutral,产品侧只依赖 .well-known/openid-configuration 发现,换 IdP 不改业务代码
容器scratch/alpine 最小镜像,多阶段构建
安全Kyverno 策略引擎 + NetworkPolicy + Trivy 容器扫描

混合云部署 ​

部署形态 双公网入口 + 混部编排 —— 兼顾国内可达性与运维成本。

混合云集群

三丰云 + 阿里云双公网入口,K3s + Docker-Compose 混部,按业务隔离基础设施。

GitOps 部署

GitHub Actions → GHCR → ArgoCD 全流程自动化,镜像 tag 锁定 main-<sha7>。

全栈可观测

Grafana + Prometheus + Jaeger + Loki 统一面板,指标 / 日志 / 链路一体。

安全设计 ​

纵深防御 从传输到容器运行时,七层纵深防御。

层级措施
传输全站 HTTPS (TLS 1.3),通配符证书自动续期
网络VPN 组网,NetworkPolicy 命名空间隔离
认证统一身份认证:OIDC JWT + API Key 双模式,WebAuthn Passkey,企业 SSO 联邦
授权RBAC 角色权限控制,多租户 GORM 自动隔离
加密ChaCha20-Poly1305 + 国密 SM4-GCM(信创合规)
审计结构化 JSON 日志 + OpenTelemetry 分布式追踪
容器readOnlyRootFilesystem, drop ALL capabilities, runAsUser:65534

数据主权

国密 SM4-GCM 全程加密、私有化部署、数据不出企业边界。一套 SSO / Passkey / MFA 即可接入企业已有 IdP,兼容 OpenAI SDK,导出零退出成本。

详细架构文档 ​

单一真源

详细架构图位于 governance repo:lurus.yaml + doc/architecture.md。本站不再内嵌全图,避免维护双源真源。


下一步

Powered by Lurus Technologies