Service Discovery to mechanizm, dzięki któremu usługi w systemie rozproszonym automatycznie odnajdują swoje aktualne adresy sieciowe (IP i port), zamiast mieć je wpisane na sztywno w konfiguracji. W praktyce jest to „książka telefoniczna” dla mikroserwisów: usługa rejestruje się w centralnym rejestrze przy starcie, a inne usługi pytają ten rejestr „gdzie znajdę payment-service?” i dostają listę żywych instancji.
Po co to całe zamieszanie? W nowoczesnej architekturze kontenery i instancje pojawiają się i znikają bez przerwy. Autoscaling dokłada pody, awaria zabija inne, a orchestrator (np. Kubernetes) przenosi je na inny węzeł z nowym adresem IP. Gdybyś trzymał adresy w pliku konfiguracyjnym, aktualizowałbyś go w nieskończoność. Service Discovery rozwiązuje to dynamicznie.
Wyróżnia się dwa modele. W client-side discovery klient sam odpytuje rejestr i wybiera instancję (tak działa Netflix Eureka z Ribbonem). W server-side discovery klient uderza w jeden stały adres load balancera albo proxy, a ten odpytuje rejestr za niego — tak działa Kubernetes ze swoim Service i wbudowanym DNS-em.
Przykład z praktyki
Popularne narzędzie to HashiCorp Consul. Każda usługa rejestruje się wraz z health checkiem, a Consul wystawia rejestr przez API oraz interfejs DNS. Zapytanie wygląda banalnie:
dig @127.0.0.1 -p 8600 payment-service.service.consul SRV
Dostajesz w odpowiedzi adresy i porty tylko tych instancji, które przeszły health check. W świecie Kubernetes nie musisz nawet sięgać po zewnętrzne narzędzie — wywołanie http://payment-service.default.svc.cluster.local automatycznie trafia do właściwych podów dzięki CoreDNS. Inne klasyki to etcd (rejestr klucz-wartość, fundament samego Kubernetes) oraz ZooKeeper.
Na co uważać
- Mit „to magia, więc samo działa”. Bez sensownych health checks rejestr będzie z uporem podawał adresy martwych instancji, a Ty zaliczysz timeouty.
- Caching i TTL. Klienci buforują odpowiedzi DNS. Jeśli TTL jest za długi, ruch jeszcze przez chwilę leci na nieistniejące adresy — to częste źródło „duchów” w logach.
- Rejestr to single point of failure. Dlatego Consul czy etcd uruchamia się w klastrze (zwykle 3 lub 5 węzłów), żeby przetrwał awarię pojedynczego serwera.
Pojęcia powiązane: load balancing, mikroserwisy, service mesh (np. Istio, Linkerd), service registry, DNS, health check, API gateway, orkiestracja kontenerów.