Szolgáltatásfelderítés, terheléselosztás és service mesh
Célok
A lecke végére el tudod magyarázni, hogyan találja meg a hívó a szolgáltatás egy példányát, hogyan osztják el a terhelést, és mit ad, illetve mit nem ad a service mesh.
Miért kell?
Egy szolgáltatás logikai neve stabil lehet, miközben a példányai indulnak, leállnak és más címre kerülnek. A hívó ne kézzel beírt, örökké érvényesnek tekintett címekre építsen.
Service discovery
A service discovery a példányok aktuális címének megtalálása. A microservices.io két változatot ír le:
Kliensoldali: a kliens lekérdezi a service registryt (a példányok nyilvántartását), maga választ példányt, és közvetlenül hívja. Előny: kevesebb mozgó rész és hálózati ugrás; hátrány: a kliens kötődik a registryhez, és a felderítési logikát minden nyelven/keretrendszerben meg kell valósítani.
Szerveroldali: a kliens egy ismert címen lévő útválasztót (terheléselosztót) hív, az kérdezi a registryt, és továbbít. Előny: egyszerűbb kliens; hátrány: újabb komponens, amely rendelkezésre állást és kapacitást igényel, plusz egy ugrás.
A Kubernetes Service objektuma tipikus platformmegoldás: stabil virtuális IP-címet és nevet ad a podok csoportjának, az endpointok pedig a podok indulásával és leállásával automatikusan frissülnek, így a kliensnek nem kell az egyes podokat követnie.
flowchart TB
subgraph CS["Kliensoldali"]
A["Hívó"] -->|"példánylista"| R["Registry"]
A -->|"közvetlen hívás"| B["Választott példány"]
end
subgraph SS["Szerveroldali"]
C["Hívó"] --> D["Stabil cím: útválasztó"]
D --> E["Példány 1"]
D --> F["Példány 2"]
end
A felderítési adat sosem tökéletesen friss: a registry, a DNS-gyorsítótár és az állapotellenőrzés késhet, egy példány a lekérdezés után is kieshet. A discovery ezért nem helyettesíti a hívásonkénti időkeretet és hibakezelést (6.5). A hosszú ideig nyitott kapcsolat akkor is a régi példányhoz tarthat, ha a névfeloldás már frissült.
Terheléselosztás
A terheléselosztás (load balancing) a példányok közti elosztás. Az NGINX dokumentációja szerint az alapértelmezett módszer a körforgó (round-robin), továbbá van legkevesebb kapcsolat (least_conn) és IP-hash alapú mód; a weight paraméter súlyozást ad. Az IP-hash a kliens további kéréseit azonos kiszolgálóhoz tereli (sticky session); ez egyszerűsítheti a helyi állapotot, de torzíthatja az elosztást, és nem oldja meg a kiesést.
A „legkevesebb kapcsolat” mérce számít: egy nyitott WebSocket és egy rövid HTTP-kérés nem azonos erőforrásigény (10.4).
Health, readiness és kiesés
A Kubernetes dokumentációja szerint a readiness próba azt jelzi, hogy a konténer fogadhat-e forgalmat; ha sikertelen, a podot kiveszik a Service végpontjai közül. A liveness próba azt dönti el, mikor kell újraindítani a konténert (például holtpont esetén). A helytelenül beállított liveness-próba kaszkádolt hibákhoz vezethet; a külső függőségek ellenőrzése a readiness-próbába való, nem a livenessbe. A sikeres egészségellenőrzés nem garantálja a következő kérés sikerét: az útvonal hibázhat, és az állapot változhat.
Kivezetéskor a példány először ne kapjon új kérést, majd fejezze be a folyamatban levőket korlátozott időn belül. Hosszú kapcsolatoknál külön bontási és újracsatlakozási rend kell.
Service mesh
A service mesh a szolgáltatások közötti forgalmi infrastruktúra: az Istio leírása szerint olyan réteg, amely az alkalmazásoknak biztonságot (mTLS, munkaterhelés-identitás, hozzáférési szabályok), forgalomirányítást (például százalékos forgalommegosztás, terheléselosztás) és megfigyelhetőséget ad kódváltoztatás nélkül. Az Envoy leírása szerint a proxy a kérés mellett külön folyamatként fut, ezért az alkalmazások nyelvétől független; az ilyen proxyk hálózata alkot meshet.
A mesh két részre bontható: az adatsík (data plane) a forgalmat továbbító proxyk, a vezérlősík (control plane) pedig a konfigurációt és a szabályokat adja nekik. (Ez a megkülönböztetés az Istio fent idézett oldalán nem szerepel; általános szakmai szóhasználat.)
A mesh nem ismeri a művelet üzleti jelentését: nem tudja, hogy egy időtúllépés után megismételt fizetési kérés biztonságos-e. Több réteg független ismétlése összeszorzódik (6.5): ha a kliens, a gateway és a mesh is háromszor próbál, egyetlen műveletből akár 3³ = 27 hálózati próbálkozás is lehet (szemléltető maximum; a pontos viselkedés a konfigurációtól függ). Egy helyen kell eldönteni, ki ismételhet, milyen feltétellel és mennyi időből.
Mikor indokolt?
A közös forgalmi szabályok száma, a szolgáltatások és csapatok mérete és a működtetési képesség együtt indokolhat meshet. Kis rendszerben a gateway és a platform szolgáltatásnevei elegendők lehetnek. Minden köztes réteg új konfigurációt és diagnosztikai felületet hoz; a hibának lehet az oka a szolgáltatás, a proxy, az útválasztás vagy a tanúsítvány.
Gyakori tévhitek
Állítás
Pontosítás
„Új DNS-cím közzététele azonnal áthelyezi a forgalmat.”
A gyorsítótár és a hosszú kapcsolatok késleltetik.
„A sticky session megoldja a kiesést.”
Nem; csak a kapcsolat célját rögzíti.
„A health check sikere garantálja a kérés sikerét.”
A routing bemenete, nem végrehajtási garancia.
„Mikroszervizekhez kötelező a service mesh.”
Kis rendszerben a platformszolgáltatások elég lehetnek.
Röviden
A discovery a példány aktuális címét találja meg; kliens- és szerveroldali változata van.
A terheléselosztás algoritmusa és mércéje (kapcsolat, súly, hash) a terheléshez igazodik.
A readiness a forgalomfogadásra, a liveness az újraindításra utal.
A service mesh forgalmi infrastruktúra, nem üzleti architektúra; az ismétlés rétegeit összehangolni kell.
Ellenőrző kérdések
Mikor jobb a kliensoldali, és mikor a szerveroldali felderítés?
Szolgáltatásfelderítés, terheléselosztás és service mesh
Célok
A lecke végére el tudod magyarázni, hogyan találja meg a hívó a szolgáltatás egy példányát, hogyan osztják el a terhelést, és mit ad, illetve mit nem ad a service mesh.
Miért kell?
Egy szolgáltatás logikai neve stabil lehet, miközben a példányai indulnak, leállnak és más címre kerülnek. A hívó ne kézzel beírt, örökké érvényesnek tekintett címekre építsen.
Service discovery
A service discovery a példányok aktuális címének megtalálása. A microservices.io két változatot ír le:
A Kubernetes Service objektuma tipikus platformmegoldás: stabil virtuális IP-címet és nevet ad a podok csoportjának, az endpointok pedig a podok indulásával és leállásával automatikusan frissülnek, így a kliensnek nem kell az egyes podokat követnie.
flowchart TB subgraph CS["Kliensoldali"] A["Hívó"] -->|"példánylista"| R["Registry"] A -->|"közvetlen hívás"| B["Választott példány"] end subgraph SS["Szerveroldali"] C["Hívó"] --> D["Stabil cím: útválasztó"] D --> E["Példány 1"] D --> F["Példány 2"] endA felderítési adat sosem tökéletesen friss: a registry, a DNS-gyorsítótár és az állapotellenőrzés késhet, egy példány a lekérdezés után is kieshet. A discovery ezért nem helyettesíti a hívásonkénti időkeretet és hibakezelést (6.5). A hosszú ideig nyitott kapcsolat akkor is a régi példányhoz tarthat, ha a névfeloldás már frissült.
Terheléselosztás
A terheléselosztás (load balancing) a példányok közti elosztás. Az NGINX dokumentációja szerint az alapértelmezett módszer a körforgó (round-robin), továbbá van legkevesebb kapcsolat (least_conn) és IP-hash alapú mód; a
weightparaméter súlyozást ad. Az IP-hash a kliens további kéréseit azonos kiszolgálóhoz tereli (sticky session); ez egyszerűsítheti a helyi állapotot, de torzíthatja az elosztást, és nem oldja meg a kiesést.A „legkevesebb kapcsolat” mérce számít: egy nyitott WebSocket és egy rövid HTTP-kérés nem azonos erőforrásigény (10.4).
Health, readiness és kiesés
A Kubernetes dokumentációja szerint a readiness próba azt jelzi, hogy a konténer fogadhat-e forgalmat; ha sikertelen, a podot kiveszik a Service végpontjai közül. A liveness próba azt dönti el, mikor kell újraindítani a konténert (például holtpont esetén). A helytelenül beállított liveness-próba kaszkádolt hibákhoz vezethet; a külső függőségek ellenőrzése a readiness-próbába való, nem a livenessbe. A sikeres egészségellenőrzés nem garantálja a következő kérés sikerét: az útvonal hibázhat, és az állapot változhat.
Kivezetéskor a példány először ne kapjon új kérést, majd fejezze be a folyamatban levőket korlátozott időn belül. Hosszú kapcsolatoknál külön bontási és újracsatlakozási rend kell.
Service mesh
A service mesh a szolgáltatások közötti forgalmi infrastruktúra: az Istio leírása szerint olyan réteg, amely az alkalmazásoknak biztonságot (mTLS, munkaterhelés-identitás, hozzáférési szabályok), forgalomirányítást (például százalékos forgalommegosztás, terheléselosztás) és megfigyelhetőséget ad kódváltoztatás nélkül. Az Envoy leírása szerint a proxy a kérés mellett külön folyamatként fut, ezért az alkalmazások nyelvétől független; az ilyen proxyk hálózata alkot meshet.
A mesh két részre bontható: az adatsík (data plane) a forgalmat továbbító proxyk, a vezérlősík (control plane) pedig a konfigurációt és a szabályokat adja nekik. (Ez a megkülönböztetés az Istio fent idézett oldalán nem szerepel; általános szakmai szóhasználat.)
flowchart TB CP["Vezérlősík: szabályok, konfiguráció"] -.-> P1 CP -.-> P2 subgraph SA["A szolgáltatás környezete"] S1["Üzleti kód"] --> P1["Forgalmi proxy"] end subgraph SB["B szolgáltatás környezete"] P2["Forgalmi proxy"] --> S2["Üzleti kód"] end P1 -->|"szolgáltatásközi forgalom"| P2A mesh nem ismeri a művelet üzleti jelentését: nem tudja, hogy egy időtúllépés után megismételt fizetési kérés biztonságos-e. Több réteg független ismétlése összeszorzódik (6.5): ha a kliens, a gateway és a mesh is háromszor próbál, egyetlen műveletből akár 3³ = 27 hálózati próbálkozás is lehet (szemléltető maximum; a pontos viselkedés a konfigurációtól függ). Egy helyen kell eldönteni, ki ismételhet, milyen feltétellel és mennyi időből.
Mikor indokolt?
A közös forgalmi szabályok száma, a szolgáltatások és csapatok mérete és a működtetési képesség együtt indokolhat meshet. Kis rendszerben a gateway és a platform szolgáltatásnevei elegendők lehetnek. Minden köztes réteg új konfigurációt és diagnosztikai felületet hoz; a hibának lehet az oka a szolgáltatás, a proxy, az útválasztás vagy a tanúsítvány.
Gyakori tévhitek
Röviden
Ellenőrző kérdések
Források