Plateforme · Micro services
Isolés. Observables. Générés par code.
Chaque micro service MOS4 déclare un contrat typé versionné généré à la compilation — prêt à consommer via maillage GraphQL, web services ou push API depuis le cloud. Le registre impose l'isolation et l'ordonnancement au démarrage ; l'observabilité est fournie sans configuration par service.
Intégration depuis le cloud
Trois surfaces. Une couche API cohérente.
Le store Munic expose chaque appareil connecté via une API cloud unifiée. Choisissez la surface qui convient à votre stack — les trois partagent les mêmes contrats de service typés issus de l'appareil.
Maillage GraphQL
Interrogez et abonnez-vous à l'état des micro services côté appareil via un schéma GraphQL unifié. Traversez les relations entre flotte et appareil en une seule requête.
Web services
Les endpoints de style REST exposent chaque opération de micro service enregistrée — sans SDK, sans code côté appareil requis. Intégrez depuis n'importe quel langage backend ou fonction cloud.
Push API
Recevez des flux d'événements en temps réel depuis n'importe quel micro service côté appareil. Abonnez-vous une fois ; les données s'écoulent dès que les services les émettent — pas de polling requis.
Guide d'intégration complet et référence API : store.munic.io — Premiers pas.
Contrats typés
Générés à la compilation. Aucun stub écrit à la main.
Chaque micro service déclare une chaîne d'interface versionnée — par exemple, mos.services.gnss.GnssService@1.0.0. Ce contrat pilote la génération de code pour la surface client et serveur complète. Les consommateurs côté cloud reçoivent un schéma stable et versionné ; les mainteneurs côté appareil n'écrivent jamais de stubs manuellement.
Ce que produit chaque contrat
- · Scaffold de trait serveur
- · Proxy (appelant côté client)
- · Client direct
- · Fake — test double, exécutable en CI sans matériel
- · Module de métriques
- · Suite de tests de conformité
Surfaces versionnées stables
Le versionnement des interfaces est imposé à l'enregistrement. Les intégrateurs cloud consomment un contrat typé qui ne change que sur une montée de version explicite — aucun changement cassant silencieux sur les 52 micro services. Construisez votre intégration avec le SDK MOS4 pour les outils de contrat complets.
Isolation imposée par le registre
Ordonnancement au démarrage via start_level 0–10.
Le registre master résout les fournisseurs à l'enregistrement. start_level 0–10 est la priorité numérique — distincte du diagramme de pile d'architecture L0–L7. Aucun micro service ne peut appeler une interface requise avant que son fournisseur ne soit enregistré.
Isolation de processus
Chaque micro service est un processus Linux séparé. Un crash ne peut pas corrompre la mémoire d'un autre service. Les capabilities sont minimales par construction.
Validation des interfaces
Les transitions de cycle de vie illégales sont rejetées par le registre. Aucun état mutable partagé ambiant ne traverse les frontières des micro services.
Isolation des ressources conteneur
Limites CPU, mémoire et I/O imposées au démarrage du conteneur. Enveloppe du budget MCM : moins de 5 % de surcharge CPU/RAM et environ 10 Mo de RSS.
Portée du SDK
N'importe quel langage — sans adoption de SDK requise.
Quatre profils de montage de conteneur permettent aux 6 langages SDK — Python, Rust, C, C++, Go et Lua — de s'exécuter aux côtés des micro services. N'importe quel conteneur peut atteindre n'importe quel micro service MOS4 via le pont MQTT — le schéma JSON de topic est suffisant, sans adoption d'interface typée requise. Explorez les outils no-code pour la configuration et la gestion de flotte sans écrire de code.
| Profil | Langage typique | Portée de bind-mount | Limites de ressources |
|---|---|---|---|
| SHELL | Scripts shell | Chemins hôte minimaux | CPU + RAM |
| PYTHON | Python 3 | Runtime Python + libs | CPU + RAM |
| NATIVE | C / C++ / Go / Rust | Libs natives | CPU + I/O |
| STATIC | Binaire statique | Minimal — statique uniquement | CPU + RAM |
Substitution de couche système : une mise à jour CPython 3.12 se propage à tous les conteneurs
Python via un seul changement de digest dans system-layers.toml — zéro reconstruction
client.
Outillage hors-bande
CLI mcm et passerelle sidecar ROS2.
Deux outils étendent le graphe de micro services sans modifier la couche applicative : un CLI de gestion de conteneurs pré-installé et une passerelle ROS2 pour les charges robotiques.
CLI autonome mcm
Le CLI de gestion de conteneurs mcm est pré-installé sur les images de production
— aucune étape d'installation séparée requise. Inspectez les conteneurs en cours d'exécution,
déclenchez des mises à jour et gérez les digests de couche système directement depuis l'appareil
ou une session distante.
Passerelle sidecar ROS2
La passerelle ROS2 connecte les graphes DDS à MOS4 sans couche d'intégration séparée. Les conteneurs sidecar ROS2 connectent les graphes DDS externes et les conteneurs ROS2 hébergés dans MCM directement au graphe de micro services. Voir le catalogue de composants pour l'entrée mos-ros2.
Micro services de la plateforme IA
Composants IA kiosk dans le catalogue.
Cinq micro services forment la plateforme MOS4 AI Language — LLM sur appareil, récupération, passerelle d'outils, voix et orchestration kiosk. Tous suivent le même pattern de contrat typé et EventBus que le reste du catalogue.
mos-llm
Service de petit modèle de langage sur appareil avec inférence quantifiée, topic EventBus en streaming de tokens, prompt système refuse-preferred et basculement cloud optionnel.
mos-rag
Génération augmentée par récupération avec seuils de similarité cosinus et verrou de refus. Benchmark de 50 questions calibré. Embedding BGE-small sur appareil.
mos-mcp
Passerelle Model Context Protocol. Expose une liste d'autorisation typée des outils que le LLM peut appeler. Liste par défaut minimale ; l'escalade nécessite une configuration opérateur.
mos-voice
STT sur appareil (Whisper-tiny) et TTS (Piper). Enrichissement obligatoire du vocabulaire pour les termes spécifiques au domaine. Critère d'acceptation : WER ≤ 15 % à 70–75 dB.
mos-kiosk
Micro service d'orchestration kiosk. Coordonne le pipeline LLM, RAG, MCP et voix pour une interface Q&R voix-first avec manifeste d'audit par réponse.
Observabilité
Automatique pour chaque micro service enregistré.
Histogrammes de temps de réponse, compteurs d'erreurs, durée de vie des composants et traces d'événements de cycle de vie sont émis automatiquement pour chaque appel de service — export OTLP et propagation W3C Trace Context inclus, sans configuration par service. Détails complets sur la page Opérations.
FAQ
Questions fréquentes
-
Les services Python et Go peuvent-ils appeler des micro services MOS4 sans adopter le SDK Rust ?
Oui. Le broker MQTT in-process accepte n'importe quel client MQTT standard sans adopter le SDK MOS4 ni les fichiers .proto. Le schéma JSON de topic est suffisant. Un conteneur Python dans MCM peut atteindre n'importe quel micro service via le broker — validé de bout en bout.
-
Qu'est-ce que start_level et en quoi diffère-t-il des couches L0–L7 ?
start_level 0–10 est la priorité numérique dans le registre, utilisée par le framework pour ordonner le démarrage des micro services. Les étiquettes L0–L7 sont un modèle mental d'architecture pour le regroupement par couche. Ce sont deux concepts distincts — ne pas les confondre.
-
Que produit la génération de code pour chaque micro service ?
Pour chaque interface déclarée, l'étape de build génère : un scaffold de trait serveur, un proxy (appelant côté client), un client direct, un fake (test double, exécutable en CI sans matériel), un module de métriques et une suite de tests de conformité. Aucun stub écrit à la main sur les 52 micro services.
-
Quelle est l'enveloppe du budget conteneur MCM ?
Moins de 5 % de surcharge CPU/RAM et environ 10 Mo de RSS par conteneur — imposé par Linux cgroups v2 au démarrage du conteneur.
-
Comment fonctionne l'accès à l'API côté cloud ?
Le store Munic expose un maillage GraphQL, des web services et une push API pour les intégrateurs côté cloud. Référence : https://store.munic.io/documentations/get_started. Pour l'automatisation côté appareil, le canal JSON MessageGate peut appeler n'importe quel micro service enregistré à l'exécution.
-
Quels langages peuvent s'exécuter dans les conteneurs MCM ?
Python, C, C++, Go, Rust et Lua. Quatre profils de montage (SHELL, PYTHON, NATIVE, STATIC) contrôlent quels chemins hôte sont bind-montés. Le mécanisme de substitution de couche système propage une mise à jour CPython 3.12 à tous les conteneurs Python via un seul changement de digest — aucune reconstruction d'image client.
Construire sur des contrats typés.
Parlez à l'ingénierie de votre architecture d'intégration cloud, ou lisez la documentation SDK pour commencer à construire.