Guide til Eurekas REST API for ikke-Java apps

I en moderne mikroservice-arkitektur er service discovery en fundamental komponent. Netflix Eureka har længe været en populær løsning i Java-verdenen, især inden for Spring Cloud-økosystemet. Men hvad gør man, når man har services skrevet i andre sprog som C++, Python eller Go? Svaret ligger i Eurekas robuste REST API, som gør det muligt for enhver applikation, uanset sprog, at registrere sig og interagere med Eureka-serveren. Denne artikel er en komplet guide til, hvordan ikke-Java-applikationer kan udnytte disse REST-operationer til fuldt ud at deltage i service discovery-processen.

Kernefunktioner i Eurekas REST API

Eureka-serveren eksponerer et sæt REST-endpoints, der tillader klienter at udføre alle nødvendige handlinger for service discovery. Disse inkluderer registrering, afregistrering, fornyelse af lease (heartbeats) og forespørgsler om andre services. For at kommunikere korrekt skal HTTP-forespørgsler indeholde de korrekte ACCEPT og Content-Type headere, typisk sat til application/json eller application/xml.

Nøglen til at forstå endpointernes struktur er at kende til to centrale identifikatorer: appID, som er navnet på din applikation (f.eks. 'ORDER-SERVICE'), og instanceID, som er en unik identifikator for en specifik instans af den applikation. I cloud-miljøer som AWS er dette typisk instansens ID, mens det i andre datacentre ofte er værtens navn (hostname).

Oversigt over REST-operationer

For at give et hurtigt og klart overblik har vi samlet de mest almindelige operationer i en tabel. Dette er de byggesten, du skal bruge for at integrere din ikke-Java-service.

Registrering af en applikationsinstans i detaljer

For at registrere din service skal du sende en POST-forespørgsel til /eureka/v2/apps/appID med en payload, der beskriver din instans. Denne payload indeholder vigtige oplysninger, som andre services skal bruge for at kunne kommunikere med din service.

De mest essentielle felter i payload'en er:

• instanceId: En unik identifikator for din instans.
• hostName: Værtsnavnet, hvor din service kører.
• app: Applikationens navn (appID).
• ipAddr: IP-adressen for instansen.
• status: Den indledende status, typisk UP. Andre mulige værdier er DOWN, STARTING, OUT_OF_SERVICE, og UNKNOWN.
• port: Portnummeret, som din service lytter på.
• dataCenterInfo: Information om datacenteret, typisk om det er 'MyOwn' eller 'Amazon'.
• healthCheckUrl: En URL, hvor Eurekas dashboard (og andre værktøjer) kan forespørge om instansens helbred.

En succesfuld registrering vil resultere i en HTTP 204 No Content-respons. Hvis du modtager en anden statuskode, er der sandsynligvis et problem med din payload eller konfiguration.

Forståelse af Helbredstjek og Heartbeats

Et centralt koncept i Eureka er, at serveren ikke aktivt overvåger klienterne. I stedet er det klienternes ansvar at informere serveren om deres helbred. Dette kaldes Taught Monitoring. Klienter gør dette ved periodisk at sende heartbeats til Eureka-serveren via en PUT-forespørgsel til deres unikke instans-endpoint. Disse heartbeats fornyer instansens 'lease' i registret.

Hvis Eureka-serveren ikke modtager et heartbeat fra en instans inden for en konfigureret tidsramme (typisk 90 sekunder), antager den, at instansen er nede, og fjerner den fra registret. Dette er en selvhelende mekanisme, der sikrer, at registret kun indeholder sunde, tilgængelige instanser.

En klients helbredsstatus bestemmes af klienten selv. I Spring Boot-applikationer sker dette typisk ved at aggregere status fra forskellige sundhedsindikatorer (f.eks. databaseforbindelse, diskplads). For en ikke-Java-applikation skal du selv implementere logikken til at afgøre, om din service er sund, og derefter rapportere denne status (f.eks. UP eller DOWN) i dine heartbeats.

Statusstyring: Manuel kontrol over trafik

Nogle gange er det nødvendigt midlertidigt at fjerne en instans fra trafikrotationen uden at lukke den ned. Dette kan være nyttigt under deployment-scenarier som blue-green eller ved vedligeholdelse. Her kan du bruge status-endpointet til at sætte en instans til OUT_OF_SERVICE. Klient-side load balancere som Ribbon vil typisk ignorere instanser med denne status. Når instansen er klar til at modtage trafik igen, kan du fjerne denne manuelle override ved at sende en DELETE-forespørgsel til det samme status-endpoint.

Fejlfinding: Almindelige problemer

Selvom processen er ligetil, kan man støde på udfordringer, især når man arbejder uden for det etablerede Java-økosystem.

Problem: 404 Not Found ved afregistrering (DELETE)

Et almindeligt problem er at modtage en 404-fejl, når man forsøger at afregistrere en service med en DELETE-forespørgsel. Dette skyldes ofte en uoverensstemmelse i instanceID. Den instanceID, du bruger i DELETE-kaldet, skal være præcis den samme som den, du brugte under registreringen. Hvis du registrerede med hostname:app:port, skal du også bruge denne fulde streng i dit DELETE-kald. En simpel fejl, som at bruge kun hostname, vil resultere i en 404-fejl.

Problem: Skal jeg bruge /v2/ i URL'en?

Den officielle Eureka REST API-dokumentation specificerer /v2/ i stien. Men i mange Spring Cloud-opsætninger er Eureka-serveren konfigureret til at eksponere API'en direkte under /eureka/apps/. Hvis dine kald til /v2/-stierne fejler, så prøv at fjerne /v2/ fra URL'en. En god måde at verificere den korrekte sti på er at tilgå Eureka-dashboardet i en browser og observere de API-kald, som brugergrænsefladen foretager.

Ofte Stillede Spørgsmål (FAQ)