Moleculer propone descubrir servicios y balancear carga sin Consul ni Kubernetes
El framework de microservicios para Node.js mantiene el catálogo de servicios duplicado en cada proceso y reparte las llamadas en local, sin registro externo ni sidecar
Montar un servicio en más de una máquina obliga a responder dos preguntas que un monolito nunca se hizo: dónde está cada copia y a cuál llamo. La respuesta habitual pasa por añadir infraestructura: un registro tipo Consul o etcd con su librería cliente en cada servicio, objetos Service de Kubernetes con kube-proxy, un sidecar de service mesh junto a cada pod o un nginx delante de cada pool. La alternativa que defiende Moleculer, el framework de microservicios para Node.js, es meter el registro dentro del propio framework.
Cada proceso ejecuta un broker con su identificador de nodo. Al arrancar publica un paquete INFO en el transporter —NATS, Redis, MQTT, AMQP, Kafka o TCP— donde describe los servicios, acciones y eventos que aloja, más metadatos libres como la zona. El resto de brokers lo recibe y actualiza su registro local. Cada pocos segundos envían un heartbeat; el nodo que deja de responder se marca como no disponible y el que se apaga limpiamente se despide con un paquete DISCONNECT para que nadie espere al timeout. Cuando el código invoca una acción, el registro del llamante elige un endpoint vivo y manda la petición directa a ese nodo. Moleculer funciona así desde 2017.
Es descubrimiento y balanceo del lado del cliente, con el catálogo mantenido de forma eventualmente consistente por gossip sobre el bus de mensajes. Las estrategias de reparto son RoundRobin por defecto, Shard —que usa una clave de los parámetros— o una propia; el texto implementa una por zona. Los tiempos son configurables: el heartbeat viene a 10 segundos y el timeout a 30, aunque la demo los baja a 2 y 6 para que la caída quepa en una terminal.
Qué pasa cuando algo se cae
La parte que suele faltar en los ejemplos de arranque es la demostración con tráfico real. Tres workers lanzados con el CLI moleculer-runner y un cliente sin servicios propios que reparte seis llamadas entre los tres procesos en round-robin. Cualquier nodo puede listar lo que conoce con el servicio integrado $node.list, que devuelve disponibilidad, zona y servicios alojados. Después, con el cliente llamando cada 500 ms durante 16 segundos, se para un worker con SIGTERM, se mata otro con SIGKILL —sin despedida— y se levanta uno nuevo. El código de los ejemplos está en GitHub, junto con implementaciones del mismo modelo en Go y Java.
El atractivo es que elimina piezas que hay que desplegar, monitorizar y actualizar, y que solo ven direcciones IP y puertos, no conceptos de la aplicación. El precio es que el catálogo vive duplicado en cada proceso y depende de un bus de mensajes que también hay que operar. El texto no publica cifras de latencia, ni qué versión del framework usa, ni cuánto pesa el gossip con muchos nodos, y la demo son tres procesos en una misma máquina: el comportamiento con decenas de nodos y redes con pérdida es otra historia.
