Plataforma · Micro Services
Aislados. Observables. Generados por código.
Cada micro service MOS4 declara un contrato tipado versionado generado en tiempo de compilación — listo para consumir a través de GraphQL mesh, servicios web o Push API desde la nube. El registro garantiza el aislamiento y el orden de arranque; la observabilidad se entrega con cero configuración por servicio.
Integrar desde la nube
Tres superficies. Una capa de API consistente.
La tienda de Munic expone cada dispositivo conectado a través de una API de nube unificada. Elija la superficie que se adapte a su stack — las tres comparten los mismos contratos de servicio tipados subyacentes del dispositivo.
GraphQL mesh
Consulte y suscriba al estado del micro service del lado del dispositivo a través de un esquema GraphQL unificado. Recorra relaciones a través de flota y dispositivo en una única solicitud.
Servicios web
Los endpoints de estilo REST exponen cada operación de micro service registrada — sin SDK, sin código del lado del dispositivo requerido. Integre desde cualquier lenguaje de backend o función en la nube.
Push API
Reciba flujos de eventos en tiempo real desde cualquier micro service del lado del dispositivo. Suscríbase una vez; los datos fluyen a medida que los servicios los emiten — sin bucle de sondeo requerido.
Guía de integración completa y referencia de API: store.munic.io — Primeros pasos.
Contratos tipados
Generados en tiempo de compilación. Sin stubs escritos a mano.
Cada micro service declara una cadena de interfaz versionada — por ejemplo, mos.services.gnss.GnssService@1.0.0. Ese contrato dirige la generación de código para la superficie completa de cliente y servidor. Los consumidores del lado de la nube reciben un esquema versionado estable; los mantenedores del lado del dispositivo nunca escriben stubs manualmente.
Qué produce cada contrato
- · Scaffold de trait de servidor
- · Proxy (llamador del lado del cliente)
- · Cliente directo
- · Fake — doble de prueba, ejecutable en CI sin hardware
- · Módulo de métricas
- · Suite de pruebas de conformidad
Superficies versionadas estables
El versionado de interfaces se aplica en el momento del registro. Los integradores de la nube consumen un contrato tipado que cambia solo con un cambio explícito de versión — sin cambios rotura silenciosos en los 52 micro services. Construya su integración con el SDK de MOS4 para el conjunto completo de herramientas de contrato.
Aislamiento garantizado por el registro
Orden de arranque mediante start_level 0–10.
El registro maestro resuelve los proveedores en el momento del registro. start_level 0–10 es la prioridad numérica — distinta del diagrama de stack de arquitectura L0–L7. Ningún micro service puede llamar a una interfaz requerida antes de que su proveedor se haya registrado.
Aislamiento de procesos
Cada micro service es un proceso Linux separado. Un fallo no puede corromper la memoria de otro servicio. Las capacidades son mínimas por construcción.
Validación de interfaces
Las transiciones de ciclo de vida ilegales son rechazadas por el registro. Ningún estado mutable compartido de entorno cruza los límites del micro service.
Aislamiento de recursos del contenedor
Límites de CPU, memoria y E/S garantizados al arranque del contenedor. Sobre de presupuesto del contenedor MCM: menos del 5% de overhead de CPU/RAM y aproximadamente 10 MB de RSS.
Alcance del SDK
Cualquier lenguaje — sin adopción de SDK requerida.
Cuatro perfiles de montaje de contenedor permiten que 6 lenguajes SDK — Python, Rust, C, C++, Go y Lua — se ejecuten junto a los micro services. Cualquier contenedor puede acceder a cualquier micro service MOS4 a través del MQTT bridge — el esquema de temas JSON es suficiente, sin necesidad de adoptar la interfaz tipada. Explore las herramientas no-code para la configuración y gestión de flota sin escribir código.
| Perfil | Lenguaje típico | Alcance de bind-mount | Límites de recursos |
|---|---|---|---|
| SHELL | Scripts de shell | Rutas mínimas del host | CPU + RAM |
| PYTHON | Python 3 | Runtime Python + libs | CPU + RAM |
| NATIVE | C / C++ / Go / Rust | Libs nativas | CPU + E/S |
| STATIC | Binario estático | Mínimo — solo estático | CPU + RAM |
Sustitución de capa de sistema: una actualización de CPython 3.12 se propaga a todos los
contenedores Python con un solo cambio de digest en system-layers.toml — cero
reconstrucciones del cliente.
Herramientas fuera de banda
CLI mcm y pasarela sidecar ROS2.
Dos herramientas extienden el grafo de micro services sin modificar la capa de aplicación: una CLI de gestión de contenedores preinstalada y una pasarela ROS2 para cargas de trabajo de robótica.
CLI standalone mcm
La CLI de gestión de contenedores mcm viene preinstalada en las imágenes de producción
— sin paso de instalación separado requerido. Inspeccione los contenedores en ejecución, active
actualizaciones y gestione los digests de capa de sistema directamente desde el dispositivo
o una sesión remota.
Pasarela sidecar ROS2
La pasarela ROS2 conecta grafos DDS en MOS4 sin una capa de integración separada. Los contenedores sidecar ROS2 conectan grafos DDS externos y contenedores ROS2 alojados en MCM directamente al grafo de micro services. Consulte el catálogo de componentes para la entrada mos-ros2.
Micro servicios de la plataforma IA
Componentes IA kiosk en el catálogo.
Cinco micro services forman la plataforma MOS4 AI Language — LLM en dispositivo, recuperación, gateway de herramientas, voz y orquestación de kiosk. Todos siguen el mismo patrón de contrato tipado y EventBus que el resto del catálogo.
mos-llm
Servicio de modelo de lenguaje pequeño en dispositivo con inferencia cuantizada, topic EventBus de streaming de tokens, prompt del sistema refuse-preferred y fallback a la nube opt-in.
mos-rag
Generación aumentada por recuperación con umbrales de similitud de coseno y puerta de rechazo. Benchmark de 50 preguntas calibrado. Embedding BGE-small en el dispositivo.
mos-mcp
Gateway Model Context Protocol. Expone una lista de herramientas permitidas tipada que el LLM puede llamar. Lista predeterminada mínima; la escalada requiere configuración del operador.
mos-voice
STT en dispositivo (Whisper-tiny) y TTS (Piper). Impulso de vocabulario obligatorio para términos específicos del dominio. Criterio de aceptación: WER ≤ 15 % a 70–75 dB.
mos-kiosk
Micro servicio de orquestación kiosk. Coordina el pipeline de LLM, RAG, MCP y voz para una superficie de Q&A voz-first con manifiesto de auditoría por respuesta.
Observabilidad
Automática para cada micro service registrado.
Los histogramas de tiempo de respuesta, contadores de error, tiempo de actividad de componente y trazas de eventos de ciclo de vida se emiten automáticamente para cada llamada de servicio — exportación OTLP y propagación W3C Trace Context incluidas con cero configuración por servicio. Detalles completos en la página de Operaciones.
FAQ
Preguntas frecuentes
-
¿Pueden los servicios Python y Go llamar a micro services MOS4 sin adoptar el SDK de Rust?
Sí. El broker MQTT en proceso acepta cualquier cliente MQTT estándar sin adoptar el SDK de MOS4 ni los archivos .proto. El esquema de temas JSON es suficiente. Un contenedor Python en MCM puede acceder a cualquier micro service a través del broker — validado de extremo a extremo.
-
¿Qué es start_level y en qué se diferencia de las capas L0–L7?
start_level 0–10 es la prioridad numérica del registro utilizada por el framework para ordenar el arranque de los micro services. Las etiquetas L0–L7 son un modelo mental de arquitectura para la agrupación de capas. Son dos conceptos separados — no deben confundirse.
-
¿Qué produce la generación de código para cada micro service?
Para cada interfaz declarada, el paso de compilación genera: un scaffold de trait de servidor, un proxy (llamador del lado del cliente), un cliente directo, un fake doble de prueba (ejecutable en CI sin hardware), un módulo de métricas y una suite de pruebas de conformidad. Sin stubs escritos a mano en los 52 micro services.
-
¿Cuál es el sobre de presupuesto del contenedor MCM?
Menos del 5% de overhead de CPU/RAM y aproximadamente 10 MB de RSS por contenedor — garantizado por cgroups v2 de Linux al arranque del contenedor.
-
¿Cómo funciona el acceso a la API del lado de la nube?
La tienda de Munic expone un GraphQL mesh, servicios web y una Push API para integradores del lado de la nube. Referencia: https://store.munic.io/documentations/get_started. Para la automatización del lado del dispositivo, el canal JSON MessageGate puede llamar a cualquier micro service registrado en tiempo de ejecución.
-
¿Qué lenguajes pueden ejecutarse dentro de contenedores MCM?
Python, C, C++, Go, Rust y Lua. Cuatro perfiles de montaje (SHELL, PYTHON, NATIVE, STATIC) controlan qué rutas del host se enlazan con bind-mount. El mecanismo de sustitución de capa de sistema propaga una actualización de CPython 3.12 a todos los contenedores Python con un solo cambio de digest — sin reconstrucción de imágenes del cliente.
Construir sobre contratos tipados.
Hable con ingeniería sobre su arquitectura de integración en la nube, o lea la documentación del SDK para empezar a construir.