Plattform · Micro Services
Isoliert. Beobachtbar. Code-generiert.
Jeder MOS4-micro service deklariert einen versionierten typisierten Vertrag, der zum Build-Zeitpunkt generiert wird — bereit zur Nutzung über GraphQL-Mesh, Web-Services oder Push-API aus der Cloud. Die Registry erzwingt Isolierung und Startreihenfolge; Beobachtbarkeit wird ohne per-Service-Konfiguration mitgeliefert.
Integration aus der Cloud
Drei Oberflächen. Eine konsistente API-Schicht.
Der Munic-Store exponiert jedes verbundene Gerät über eine einheitliche Cloud-API. Wählen Sie die Oberfläche, die zu Ihrem Stack passt — alle drei teilen dieselben zugrunde liegenden typisierten Serviceverträge vom Gerät.
GraphQL-Mesh
Geräteseitigen micro service-Zustand über ein einheitliches GraphQL-Schema abfragen und abonnieren. Beziehungen über Flotte und Gerät in einer einzigen Anfrage traversieren.
Web-Services
REST-artige Endpunkte exponieren jeden registrierten micro service-Vorgang — kein SDK, kein geräteseitiger Code erforderlich. Von jeder Backend-Sprache oder Cloud-Funktion integrieren.
Push-API
Echtzeit-Event-Streams von jedem geräteseitigen micro service empfangen. Einmal abonnieren; Daten fließen, wenn Services sie emittieren — kein Polling-Loop erforderlich.
Vollständige Integrationsanleitung und API-Referenz: store.munic.io — Get Started.
Typisierte Verträge
Zum Build-Zeitpunkt generiert. Keine handgeschriebenen Stubs.
Jeder micro service deklariert einen versionierten Interface-String — zum Beispiel mos.services.gnss.GnssService@1.0.0. Dieser Vertrag treibt die Code-Generierung für die vollständige Client- und Server-Oberfläche. Cloud-seitige Konsumenten erhalten ein stabiles, versioniertes Schema; geräteseitige Maintainer schreiben niemals Stubs manuell.
Was jeder Vertrag erzeugt
- · Server-Trait-Gerüst
- · Proxy (client-seitiger Aufrufer)
- · Direkter Client
- · Fake — Test-Double, CI-lauffähig ohne Hardware
- · Metriken-Modul
- · Compliance-Test-Suite
Stabile versionierte Oberflächen
Interface-Versionierung wird zur Registrierungszeit erzwungen. Cloud-Integratoren verwenden einen typisierten Vertrag, der sich nur bei einem expliziten Versions-Bump ändert — keine stillen Breaking Changes über 52 micro services. Bauen Sie Ihre Integration mit dem MOS4-SDK für vollständiges Vertragswerkzeug.
Registry-erzwungene Isolierung
Startreihenfolge über start_level 0–10.
Die Master-Registry löst Anbieter zur Registrierungszeit auf. start_level 0–10 ist die numerische Priorität — verschieden vom L0–L7-Architektur-Stack-Diagramm. Kein micro service kann eine erforderliche Schnittstelle aufrufen, bevor ihr Anbieter sich registriert hat.
Prozessisolierung
Jeder micro service ist ein separater Linux-Prozess. Ein Absturz kann den Speicher eines anderen Service nicht korrumpieren. Capabilities sind minimal per Konstruktion.
Schnittstellenvalidierung
Illegale Lifecycle-Übergänge werden von der Registry abgelehnt. Kein gemeinsamer veränderbarer Zustand überschreitet micro service-Grenzen.
Container-Ressourcenisolierung
CPU-, Speicher- und I/O-Limits zum Containerstartzeit erzwungen. MCM-Container-Budget-Envelope: weniger als 5% CPU/RAM-Overhead und ca. 10 MB RSS.
SDK-Reichweite
Jede Sprache — keine SDK-Übernahme erforderlich.
Vier Container-Mount-Profile ermöglichen 6 SDK-Sprachen — Python, Rust, C, C++, Go, und Lua — neben micro services zu laufen. Jeder Container kann jeden MOS4-micro service über die MQTT-Bridge erreichen — JSON-Topic-Schema ist ausreichend, keine typisierte Schnittstellen-Übernahme erforderlich. Erkunden Sie die No-Code-Werkzeuge für Konfiguration und Flottenmanagement ohne Code.
| Profil | Typische Sprache | Bind-Mount-Umfang | Ressourcenlimits |
|---|---|---|---|
| SHELL | Shell-Skripte | Minimale Host-Pfade | CPU + RAM |
| PYTHON | Python 3 | Python-Laufzeit + Bibliotheken | CPU + RAM |
| NATIVE | C / C++ / Go / Rust | Native Bibliotheken | CPU + I/O |
| STATIC | Statische Binärdatei | Minimal — nur statisch | CPU + RAM |
System-Schicht-Substitution: Ein CPython-3.12-Update propagiert zu allen Python-Containern
über einen einzelnen Digest-Bump in system-layers.toml — null Kunden-Rebuilds.
Out-of-Band-Werkzeuge
mcm-CLI und ROS2-Sidecar-Gateway.
Zwei Werkzeuge erweitern den micro service-Graphen ohne Änderung der Anwendungsschicht: eine vorinstallierte Container-Management-CLI und ein ROS2-Gateway für Robotik-Workloads.
mcm -Standalone-CLI
Die mcm-Container-Management-CLI ist auf Produktions-Images vorinstalliert
— kein separater Installationsschritt erforderlich. Laufende Container inspizieren,
Updates auslösen und System-Schicht-Digests direkt vom Gerät oder einer Remote-Session
verwalten.
ROS2-Sidecar-Gateway
Das ROS2-Gateway verbindet DDS-Graphen mit MOS4 ohne separate Integrationsschicht. ROS2-Sidecar-Container verbinden externe DDS-Graphen und MCM-gehostete ROS2-Container direkt mit dem micro service-Graphen. Siehe den Komponentenkatalog für den mos-ros2-Eintrag.
KI-Plattform-micro services
KI-Kiosk-Komponenten im Katalog.
Fünf Micro Services bilden die MOS4 AI Language Plattform — On-Device-LLM, Retrieval, Tool-Gateway, Sprache und Kiosk-Orchestrierung. Alle folgen demselben Muster aus typisiertem Vertrag und EventBus wie der Rest des Katalogs.
mos-llm
On-Device-Small-Language-Model-Service mit quantisierter Inferenz, EventBus-Token-Stream- Topic, refuse-preferred System-Prompt und opt-in Cloud-Fallback.
mos-rag
Retrieval-Augmented Generation mit Kosinus-Ähnlichkeitsschwellenwerten und Ablehnungsschranke. Kalibrierter 50-Fragen-Benchmark. BGE-small Embedding auf dem Gerät.
mos-mcp
Model Context Protocol Gateway. Exponiert eine typisierte Allowlist von Tools die das LLM aufrufen darf. Standardliste ist minimal; Eskalation erfordert Operator-Konfiguration.
mos-voice
On-Device-STT (Whisper-tiny) und TTS (Piper). Obligatorische Vokabular-Anreicherung für domänenspezifische Begriffe. Akzeptanzkriterium: WER ≤ 15 % bei 70–75 dB.
mos-kiosk
Kiosk-Orchestrierungs-micro service. Koordiniert die LLM-, RAG-, MCP- und Sprach-Pipeline für eine Sprach-first-Q&A-Oberfläche mit antwortbezogenem Audit-Manifest.
Beobachtbarkeit
Automatisch für jeden registrierten micro service.
Antwortzeit-Histogramme, Fehlerzähler, Komponenten-Uptime und Lifecycle-Event-Traces werden automatisch für jeden Serviceaufruf emittiert — OTLP-Export und W3C-Trace-Context-Propagation inklusive, ohne per-Service-Konfiguration. Vollständige Details auf der Operations-Seite.
FAQ
Häufig gestellte Fragen
-
Können Python- und Go-Services MOS4-micro services aufrufen, ohne das Rust-SDK zu übernehmen?
Ja. Der In-Process-MQTT-Broker akzeptiert jeden Standard-MQTT-Client ohne Übernahme des MOS4-SDK oder der .proto-Dateien. JSON-Topic-Schema ist ausreichend. Ein Python-Container in MCM kann jeden micro service über den Broker erreichen — vollständig Ende-zu-Ende validiert.
-
Was ist start_level und wie unterscheidet es sich von den L0–L7-Schichten?
start_level 0–10 ist die numerische Registry-Priorität, die das Framework zur Reihenfolge des micro service-Starts verwendet. Die L0–L7-Labels sind ein Architektur-Mentalmodell für die Schichtgruppierung. Es sind zwei separate Konzepte — nicht verwechseln.
-
Was erzeugt die Code-Generierung für jeden micro service?
Für jede deklarierte Schnittstelle erzeugt der Build-Schritt ein Server-Trait-Gerüst, einen Proxy (client-seitiger Aufrufer), einen direkten Client, ein Test-Double-Fake (CI-lauffähig ohne Hardware), ein Metriken-Modul und eine Compliance-Test-Suite. Keine handgeschriebenen Stubs über 52 micro services.
-
Was ist das MCM-Container-Budget-Envelope?
Weniger als 5% CPU/RAM-Overhead und ca. 10 MB RSS pro Container — erzwungen durch Linux-cgroups v2 zum Containerstartzeit.
-
Wie funktioniert der Cloud-seitige API-Zugriff?
Der Munic-Store exponiert ein GraphQL-Mesh, Web-Services und eine Push-API für Cloud-seitige Integratoren. Referenz: https://store.munic.io/documentations/get_started. Für geräteseitige Automatisierung kann der MessageGate-JSON-Kanal jeden registrierten micro service zur Laufzeit aufrufen.
-
Welche Sprachen können innerhalb von MCM-Containern laufen?
Python, C, C++, Go, Rust und Lua. Vier Mount-Profile (SHELL, PYTHON, NATIVE, STATIC) steuern, welche Host-Pfade bind-gemountet werden. Der System-Schicht-Substitutionsmechanismus propagiert ein CPython-3.12-Laufzeit-Update zu allen Python-Containern über einen einzelnen Digest-Bump — kein Kunden-Image-Rebuild.
Auf typisierten Verträgen aufbauen.
Mit dem Engineering-Team über Ihre Cloud-Integrationsarchitektur sprechen oder die SDK-Dokumentation lesen, um mit dem Aufbau zu beginnen.