Architecture du système — Cluster · GitOps · Supervision
L'infrastructure partagée par les services, expliquée en un seul schéma
Lurus adopte une architecture cloud hybride et construit un système unifié de déploiement et de gouvernance des services basé sur Kubernetes + GitOps. Les 12 produits partagent un même socle de compte, facturation, mémoire, passerelle LLM et observabilité — non pas un assemblage de services indépendants, mais un schéma unique que l’on peut expliquer d’un seul tenant.
Panorama de l’architecture
Vue en couches Des produits grand public au socle d’exploitation, cinq couches de haut en bas ; chaque couche inférieure fournit des capacités à la couche supérieure, qui n’a pas connaissance de l’implémentation sous-jacente.
graph TB
subgraph C[Couche produits grand public]
Lucrum[Lucrum quantitatif]
Switch[Switch desktop]
Creator[Creator contenu]
Lutu[Lutu mobile]
end
subgraph B[Couche produits entreprise]
API[Lurus API passerelle LLM]
Forge[Forge atelier]
Lumen[Lumen outils développeur]
end
subgraph E[Couche moteurs cœur]
Kova[Kova exécution durable Rust]
MemX[MemX mémoire intelligente Python]
end
subgraph I[Couche infrastructure]
Platform[Platform compte facturation]
Auth[Auth OIDC]
Notify[Notification notifications multicanal]
end
subgraph O[Couche exploitation]
Ops[K8s Traefik ArgoCD Prometheus Grafana Jaeger Loki]
end
C --> B
B --> E
E --> I
I --> OVersion texte du schéma en couches (accessibilité / copie)
┌─────────────────────────────────────────────────────────────────┐
│ C 端产品层 │
│ Lucrum (量化) · Switch (桌面) · Creator (内容) · Lutu (移动) │
├─────────────────────────────────────────────────────────────────┤
│ B 端产品层 │
│ Lurus API (LLM 网关) · Forge (工作台) · Lumen (开发者工具) │
├─────────────────────────────────────────────────────────────────┤
│ 核心引擎层 │
│ Kova (持久执行, Rust) · MemX (智能记忆, Python) │
├─────────────────────────────────────────────────────────────────┤
│ 基础设施层 │
│ Platform (账号/计费) · Auth (OIDC) · Notification (多渠道通知) │
├─────────────────────────────────────────────────────────────────┤
│ 运维层 │
│ K8s · Traefik · ArgoCD · Prometheus · Grafana · Jaeger · Loki │
└─────────────────────────────────────────────────────────────────┘Principes de conception
Cinq principes Point d’entrée unifié, modèles unifiés, déploiement automatisé, observabilité intégrée, auto-réparation en cas de panne.
Conception cœur
Passerelle unifiée
Point d’entrée Traefik, terminaison TLS, gestion automatique des certificats wildcard
Passerelle IA multi-modèles
Accès unifié à 50+ canaux LLM (OpenAI / Claude / Gemini / Deepseek / Qwen / Moonshot, etc.), protection par coupe-circuit par canal
Déploiement GitOps
GitHub Actions → images conteneur GHCR → synchronisation automatique ArgoCD
Observabilité full-stack
Métriques Prometheus + tableaux de bord Grafana + journaux Loki + traçage distribué Jaeger
Conception haute disponibilité
Bascule automatique en cas de panne de canal, routage par priorité + pondération, protection PodDisruptionBudget
Flux de traitement des requêtes
Flux de données Une requête LLM, de l’entrée jusqu’à l’amont, traverse cinq points de contrôle : authentification, limitation de débit, coupe-circuit, facturation, journalisation.
graph LR
Client[Client] --> Traefik[Traefik TLS]
Traefik --> GW[API Gateway]
GW --> Route[Routage intelligent]
Route --> Up[IA amont 50+ fournisseurs]
Up --> Resp[Réponse]
GW -.-> Mid[Authentification / Limitation / Coupe-circuit / Facturation / Journalisation]L’API Gateway associe automatiquement un canal disponible selon le nom du modèle, avec prise en charge du tri par priorité et de la répartition aléatoire pondérée. Lorsqu’un canal de haute priorité tombe en panne, le coupe-circuit par canal isole automatiquement le canal défaillant et bascule le trafic vers un canal de secours.
Vue d’ensemble de la pile technique
Choix techniques Pile hybride multilingue, qui associe à chaque métier le runtime le plus adapté.
| Couche | Choix techniques |
|---|---|
| Services backend | Go (Gin), Rust, Python (FastAPI) |
| Frontend | React / Next.js / Vue 3 / Flutter |
| Applications desktop | Wails (Go + Web), un seul exe sans dépendance |
| Base de données | PostgreSQL (CNPG), isolation par schéma de service |
| Cache | Redis, isolation par DB de service |
| Messagerie | NATS JetStream (diffusion d’événements) |
| Workflow | Temporal (renouvellements d’abonnement / tâches planifiées) |
| Authentification d’identité | Casdoor (OIDC) |
| Conteneurs | images minimales scratch/alpine, build multi-étapes |
| Sécurité | moteur de politiques Kyverno + NetworkPolicy + scan de conteneurs Trivy |
Déploiement cloud hybride
Forme de déploiement Double point d’entrée public + orchestration en déploiement mixte — concilie accessibilité en Chine et coût d’exploitation.
Double point d’entrée public Sanfeng Cloud + Alibaba Cloud, déploiement mixte K3s + Docker-Compose, infrastructure isolée par métier.
GitHub Actions → GHCR → ArgoCD, automatisation de bout en bout, tag d’image verrouillé sur main-<sha7>.
Tableau de bord unifié Grafana + Prometheus + Jaeger + Loki, métriques / journaux / traces intégrés.
Conception de la sécurité
Défense en profondeur Du transport au runtime des conteneurs, sept couches de défense en profondeur.
| Couche | Mesures |
|---|---|
| Transport | HTTPS sur tout le site (TLS 1.3), renouvellement automatique des certificats wildcard |
| Réseau | Réseau VPN, isolation des namespaces par NetworkPolicy |
| Authentification | Authentification d’identité unifiée : double mode OIDC JWT + API Key, WebAuthn Passkey, fédération SSO entreprise |
| Autorisation | Contrôle d’accès par rôles RBAC, isolation multitenant automatique via GORM |
| Chiffrement | ChaCha20-Poly1305 + SM4-GCM (conformité Xinchuang) |
| Audit | Journaux JSON structurés + traçage distribué OpenTelemetry |
| Conteneurs | readOnlyRootFilesystem, drop ALL capabilities, runAsUser:65534 |
Souveraineté des données
Chiffrement de bout en bout SM4-GCM, déploiement on-premise, données ne quittant jamais le périmètre de l’entreprise. Un même socle SSO / Passkey / MFA suffit à se raccorder à l’IdP existant de l’entreprise, compatible avec le SDK OpenAI, export sans coût de sortie.
Documentation d’architecture détaillée
Source unique de vérité
Les schémas d’architecture détaillés se trouvent dans le repo de gouvernance : lurus.yaml + doc/architecture.md. Ce site n’intègre plus le schéma complet, afin d’éviter la maintenance d’une double source de vérité.