En el disseny d'aplicacions modernes, és habitual que un sol serveix exposi múltiples ports: un per al trànsit HTTP d'usuari, un altre per a mètriques, un per a administració i potser un endpoint gRPC. Fins fa poc, aquesta realitat xocava amb la manera com les eines de descobriment de serveis representaven aquestes aplicacions. Consul, el conegut sistema de descobriment i configuració distribuïda, ha fet un pas endavant amb el seu suport nadiu per a serveis multi-port, una funcionalitat que simplifica dràsticament la gestió del catàleg i la malla de serveis.
Abans d'aquesta novetat, els equips d'operacions havien de registrar cada port com un servei independent: order-http, order-admin, order-metrics, etc. Aquesta pràctica funcionava, pero generava un catàleg inflat i fragmentava l'observabilitat. Les polítiques de seguretat (intencions) s'havien de replicar per a cada nom, els panells de control mostraven l'aplicació com a múltiples entitats i la correlació amb els serveis de Kubernetes mai no era natural. Consul 1.22 i versions posteriors resolen aquesta fricció permetent que un serveix registri una llista de ports amb nom, mantenint una única identitat.
Des de Q2BSTUDIO, empresa especialitzada en programari a mida, veiem aquest canvi com un reflex de com la infraestructura s'ha d'adaptar a la lògica de negoci, i no al revés. Un serveix de comandes, per exemple, no hauria de ser tres entrades a Consul només perquè ofereix API, panell d'administració i mètriques. Amb el model de ports amb nom, el serveix continua sent un de sol, pero cada port té un identificador semàntic: http, admin, metrics.
El registre és senzill. En un fitxer HCL es defineix el serveix amb una llista ports, on cada entrada té nom, número de port i un indicador booleà default. El port marcat com a predeterminat garanteix compatibilitat amb clients antics que esperen un sol port. Per defecte, Consul retorna aquell port a les respostes tradicionals, pero els clients moderns poden preguntar explícitament per admin o metrics. Aquesta doble cara és clau per a una migració gradual sense trencar res.
El descobriment mitjançant DNS també se'n beneficia. Ara es pot consultar _order-service._tcp.service.metrics.port.consul per obtenir el port de mètriques, o _order-service._tcp.service.consul per al predeterminat. Si el nom del port no existeix, Consul respon amb NXDOMAIN, eliminant ambigütats. L'API HTTP manté retrocompatibilitat: el camp ServicePort continua present, pero s'afegeix ServicePorts amb la llista completa. Els consumidors antics no noten la diferència; els nous poden ser conscients dels ports.
En entorns Kubernetes, la integració resulta natural perquè els serveis de Kubernetes ja tenen ports amb nom. En sincronitzar un servei de tipus ClusterIP o NodePort, Consul preserva aquests noms al catàleg. Fins i tot és possible triar el port predeterminat amb l'anotació consul.hashicorp.com/connect-service-default-port. Q2BSTUDIO recomana aprofitar aquesta sincronització per alinear el model d'infraestructura amb el d'aplicació, especialment quan s'utilitzen arquitectures de microserveis en cloud AWS/Azure.
Els checks de salut es mantenen a nivell d'instància, no per port. És possible definir health checks que apuntin a diferents endpoints (per exemple, un HTTP al port 8080 i un altre al 9100), pero el resultat és únic per a tota la instància. Això és un equilibri pragmàtic: permet monitoritzar diferents aspectes sense complicar el model de salut. Les adreces etiquetades (tagged addresses) utilitzen el port predeterminat, preservant el comportament de LAN/WAN existent.
El suport multi-port també s'estén a la malla de serveis (service mesh), tot i que en fase beta. En lloc d'aixecar un sidecar per cada port, un únic sidecar pot enrutar el trànsit al port correcte utilitzant ALPN en l'handshake TLS. El sidecar destí rep el senyal i dirigeix el trànsit al port local corresponent. Això simplifica la topologia de la malla i redueix el soroll operatiu. Es pot utilitzar tant amb upstreams explícits (definint destination_port = 'metrics') com amb proxy transparent (mitjançant noms DNS virtuals com metrics.order-service.virtual.consul).
Per a Q2BSTUDIO, la incorporació de capacitats com aquesta és fonamental quan desenvolupem solucions que integren IA, ciberseguretat i BI en entorns cloud. Per exemple, un sistema d'anàlisi avançat pot exposar un port per a l'API de consultes, un altre per a la ingesta de dades i un tercer per a mètriques de rendiment, tot sota un mateix servei. Els agents d'IA que monitoritzen aquests sistemes poden consumir la informació de manera precisa sense necessitat de múltiples registres.
Les regles per utilitzar aquesta funcionalitat són simples: utilitzar port o ports però no tots dos, donar un nom únic a cada port, marcar-ne un com a predeterminat i mantenir la salut a nivell d'instància. Futures versions ampliaran el model a cluster peering, API Gateway, terminating gateway, intencions i health checks per port. La direcció és clara: una identitat de servei, precisió a nivell de port allà on calgui.
En resum, els serveis multi-port de Consul eliminen una fricció històrica entre com s'executen les aplicacions i com es representaven al catàleg. Per a empreses com Q2BSTUDIO, que ajuden els seus clients a construir programari a mida, implantar solucions cloud i desplegar intel·ligència artificial amb garanties, aquesta evolució és una eina més per alinear la infraestructura amb la realitat del negoci. Menys duplicats, menys convencions de noms i un catàleg que reflecteix fidelment l'aplicació real.
