En el diseño de aplicaciones modernas, es habitual que un solo servicio exponga múltiples puertos: uno para tráfico HTTP de usuario, otro para métricas, uno para administración y quizás un endpoint gRPC. Hasta hace poco, esta realidad chocaba con la forma en que las herramientas de descubrimiento de servicios representaban esas aplicaciones. Consul, el conocido sistema de descubrimiento y configuración distribuida, ha dado un paso adelante con su soporte nativo para servicios multi-puerto, una funcionalidad que simplifica drásticamente la gestión del catálogo y la malla de servicios.
Antes de esta novedad, los equipos de operaciones tenían que registrar cada puerto como un servicio independiente: order-http, order-admin, order-metrics, etc. Esta práctica funcionaba, pero generaba un catálogo inflado y fragmentaba la observabilidad. Las políticas de seguridad (intenciones) debían replicarse para cada nombre, los paneles de control mostraban la aplicación como múltiples entidades y la correlación con los servicios de Kubernetes nunca era natural. Consul 1.22 y versiones posteriores resuelven esta fricción permitiendo que un servicio registre una lista de puertos con nombre, manteniendo una única identidad.
Desde Q2BSTUDIO, empresa especializada en aplicaciones a medida, vemos este cambio como un reflejo de cómo la infraestructura debe adaptarse a la lógica de negocio, y no al revés. Un servicio de pedidos, por ejemplo, no debería ser tres entradas en Consul solo porque ofrece API, panel de administración y métricas. Con el modelo de puertos nombrados, el servicio sigue siendo uno solo, pero cada puerto tiene un identificador semántico: http, admin, metrics.
El registro es sencillo. En un archivo HCL se define el servicio con una lista ports, donde cada entrada tiene nombre, número de puerto y un indicador booleano default. El puerto marcado como predeterminado garantiza compatibilidad con clientes antiguos que esperan un solo puerto. Por defecto, Consul devuelve ese puerto en las respuestas tradicionales, pero los clientes modernos pueden preguntar explícitamente por admin o metrics. Esta doble cara es clave para una migración gradual sin romper nada.
El descubrimiento mediante DNS también se beneficia. Ahora se puede consultar _order-service._tcp.service.metrics.port.consul para obtener el puerto de métricas, o _order-service._tcp.service.consul para el predeterminado. Si el nombre del puerto no existe, Consul responde con NXDOMAIN, eliminando ambigüedades. La API HTTP mantiene retrocompatibilidad: el campo ServicePort sigue presente, pero se añade ServicePorts con la lista completa. Los consumidores antiguos no notan la diferencia; los nuevos pueden ser conscientes de los puertos.
En entornos Kubernetes, la integración resulta natural porque los servicios de Kubernetes ya tienen puertos con nombre. Al sincronizar un servicio de tipo ClusterIP o NodePort, Consul preserva esos nombres en el catálogo. Incluso es posible elegir el puerto predeterminado con la anotación consul.hashicorp.com/connect-service-default-port. Q2BSTUDIO recomienda aprovechar esta sincronización para alinear el modelo de infraestructura con el de aplicación, especialmente cuando se utilizan arquitecturas de microservicios en cloud AWS/Azure.
Los checks de salud se mantienen a nivel de instancia, no por puerto. Es posible definir health checks que apunten a diferentes endpoints (por ejemplo, uno HTTP en el puerto 8080 y otro en 9100), pero el resultado es único para toda la instancia. Esto es un equilibrio pragmático: permite monitorear distintos aspectos sin complicar el modelo de salud. Las direcciones etiquetadas (tagged addresses) usan el puerto predeterminado, preservando el comportamiento de LAN/WAN existente.
El soporte multi-puerto también se extiende a la malla de servicios (service mesh), aunque en fase beta. En lugar de levantar un sidecar por cada puerto, un único sidecar puede enrutar el tráfico al puerto correcto utilizando ALPN en el handshake TLS. El sidecar destino recibe la señal y dirige el tráfico al puerto local correspondiente. Esto simplifica la topología de la malla y reduce el ruido operativo. Se puede usar tanto con upstreams explícitos (definiendo destination_port = 'metrics') como con proxy transparente (mediante nombres DNS virtuales como metrics.order-service.virtual.consul).
Para Q2BSTUDIO, la incorporación de capacidades como esta es fundamental cuando desarrollamos soluciones que integran IA, ciberseguridad y BI en entornos cloud. Por ejemplo, un sistema de análisis avanzado puede exponer un puerto para la API de consultas, otro para la ingesta de datos y un tercero para métricas de rendimiento, todo bajo un mismo servicio. Los agentes IA que monitorizan estos sistemas pueden consumir la información de manera precisa sin necesidad de múltiples registros.
Las reglas para usar esta funcionalidad son simples: usar port o ports pero no ambos, dar un nombre único a cada puerto, marcar uno como predeterminado y mantener la salud a nivel de instancia. Futuras versiones ampliarán el modelo a cluster peering, API Gateway, terminating gateway, intenciones y health checks por puerto. La dirección es clara: una identidad de servicio, precisión a nivel de puerto donde haga falta.
En resumen, los servicios multi-puerto de Consul eliminan una fricción histórica entre cómo se ejecutan las aplicaciones y cómo se representaban en el catálogo. Para empresas como Q2BSTUDIO, que ayudan a sus clientes a construir aplicaciones a medida, implantar soluciones cloud y desplegar inteligencia artificial con garantías, esta evolución supone una herramienta más para alinear la infraestructura con la realidad del negocio. Menos duplicados, menos convenciones de nombres y un catálogo que refleja fielmente la aplicación real.
