A lecke végére meg tudod mondani, hogyan adódik össze a késleltetés soros és párhuzamos hívásoknál, mi a fan-out és a tail latency, és hogyan hat a kötelező függőségek száma a rendelkezésre állásra.
Miért kell?
A szolgáltatások közötti kommunikáció teljesítményét nem egyetlen végpont átlagos válaszideje írja le, hanem az egész kérési útvonal: a hívások száma, sorrendje, párhuzamossága és az átvitt adat mennyisége. Sok kis szolgáltatásból álló rendszer több időt tölthet kommunikációval, mint üzleti számítással.
Soros és párhuzamos hívások
Ha egy kérés n egymástól függő hívást hajt végre sorban, a késleltetések összeadódnak. Ha a hívások függetlenek és egyszerre indulnak, az összidő a leglassabbhoz közelít, de több egyidejű erőforrás kell. A párhuzamosítás nem old fel adatfüggőséget: ha a második hívás paramétere az első eredménye, nem indítható egyszerre.
sequenceDiagram
participant G as Összeállító
participant A as Szolgáltatás A
participant B as Szolgáltatás B
participant C as Szolgáltatás C
par Független adatok
G->>A: kérés
A-->>G: adat
and
G->>B: kérés
B-->>G: adat
and
G->>C: kérés
C-->>G: adat
end
G->>G: Eredmény összeállítása
Fan-out és tail latency
Fan-out: egy bejövő kérés több belső hívást indít. Ha minden eredményt meg kell várni, a leglassabb függőség szabja meg a befejezést; minél több a hívás, annál valószínűbb, hogy valamelyik lassú. Az átlag elrejti ezt: a lassú kérések tartományát a magas percentilisek (például p95, p99) mutatják. Ezt a jelenséget tail latencynek (farok-késleltetésnek) nevezzük. A percentilisek nem adhatók össze egyszerűen; a teljes útvonalat kell mérni, amit egy elosztott trace (a hívási lánc nyomkövetése) tesz láthatóvá.
Rendelkezésre állás kötelező függőségekkel
Ha egy művelet sikeréhez n független szolgáltatás mindegyike kell, és mindegyik 99%-ban elérhető, az együttes elérhetőség 0,99ⁿ. Három függőségre ez 0,99³ ≈ 97,03%. A valós függések gyakran korrelálnak, ezért ez nem SLA-számítás, hanem annak illusztrációja, hogy a kötelező függőségek halmozása rontja a teljes művelet sikerét.
Chatty API és batching
Egy kapcsolat chatty (fecsegő), ha egy üzleti művelet sok apró oda-vissza hívást igényel. Összefoglaló végpont, batching vagy célzott read model (4.3) csökkentheti a költséget. A túl nagy válasz viszont felesleges adatot visz és szoros szerződést hoz létre. A cél az adott fogyasztási igényhez igazított határ, nem minden hívás összeolvasztása.
Kötelező és opcionális függőség
Nem minden adat egyformán kritikus. Ha az opcionális adat hiányzik, az oldal még megjelenhet; ha egy fizetés eredménye nem ismert, a vásárlást nem szabad sikeresnek állítani. A degradált működést az üzleti jelentés alapján kell eldönteni, nem általános „hiba esetén üres lista” szabállyal (6.6).
Gyakori tévhitek
Állítás
Pontosítás
„Ha minden végpont gyors, a rendszer is gyors.”
Az útvonal összideje, a sorosság és a leglassabb függőség számít.
„Az átlagos válaszidő mutatja a felhasználói élményt.”
A lassú kérések tartományát percentilisek mutatják.
„A párhuzamosítás mindig segít.”
Adatfüggőségnél nem lehetséges, és több erőforrást igényel.
„A kisebb szolgáltatások gyorsabbak.”
Több hálózati hívás jelenhet meg.
Röviden
Soros hívásoknál a késleltetések összeadódnak, párhuzamosnál a leglassabb számít.
A fan-out növeli a tail latency valószínűségét; a percentilisek mutatják.
A kötelező függőségek szorzódó elérhetőséget jelentenek.
Chatty kapcsolatot batchinggel, összefoglaló végponttal vagy read modellel lehet mérsékelni.
Ellenőrző kérdések
Miért nem bizonyít gyors rendszert három külön gyors végpont?
Mikor csökkenthető a fan-out egy read modellel?
Milyen adatok hiánya mellett működhet tovább egy oldal, és mit kell jeleznie?
Késleltetés, fan-out és kommunikációs csatolás
Célok
A lecke végére meg tudod mondani, hogyan adódik össze a késleltetés soros és párhuzamos hívásoknál, mi a fan-out és a tail latency, és hogyan hat a kötelező függőségek száma a rendelkezésre állásra.
Miért kell?
A szolgáltatások közötti kommunikáció teljesítményét nem egyetlen végpont átlagos válaszideje írja le, hanem az egész kérési útvonal: a hívások száma, sorrendje, párhuzamossága és az átvitt adat mennyisége. Sok kis szolgáltatásból álló rendszer több időt tölthet kommunikációval, mint üzleti számítással.
Soros és párhuzamos hívások
Ha egy kérés n egymástól függő hívást hajt végre sorban, a késleltetések összeadódnak. Ha a hívások függetlenek és egyszerre indulnak, az összidő a leglassabbhoz közelít, de több egyidejű erőforrás kell. A párhuzamosítás nem old fel adatfüggőséget: ha a második hívás paramétere az első eredménye, nem indítható egyszerre.
sequenceDiagram participant G as Összeállító participant A as Szolgáltatás A participant B as Szolgáltatás B participant C as Szolgáltatás C par Független adatok G->>A: kérés A-->>G: adat and G->>B: kérés B-->>G: adat and G->>C: kérés C-->>G: adat end G->>G: Eredmény összeállításaFan-out és tail latency
Fan-out: egy bejövő kérés több belső hívást indít. Ha minden eredményt meg kell várni, a leglassabb függőség szabja meg a befejezést; minél több a hívás, annál valószínűbb, hogy valamelyik lassú. Az átlag elrejti ezt: a lassú kérések tartományát a magas percentilisek (például p95, p99) mutatják. Ezt a jelenséget tail latencynek (farok-késleltetésnek) nevezzük. A percentilisek nem adhatók össze egyszerűen; a teljes útvonalat kell mérni, amit egy elosztott trace (a hívási lánc nyomkövetése) tesz láthatóvá.
Rendelkezésre állás kötelező függőségekkel
Ha egy művelet sikeréhez n független szolgáltatás mindegyike kell, és mindegyik 99%-ban elérhető, az együttes elérhetőség 0,99ⁿ. Három függőségre ez 0,99³ ≈ 97,03%. A valós függések gyakran korrelálnak, ezért ez nem SLA-számítás, hanem annak illusztrációja, hogy a kötelező függőségek halmozása rontja a teljes művelet sikerét.
Chatty API és batching
Egy kapcsolat chatty (fecsegő), ha egy üzleti művelet sok apró oda-vissza hívást igényel. Összefoglaló végpont, batching vagy célzott read model (4.3) csökkentheti a költséget. A túl nagy válasz viszont felesleges adatot visz és szoros szerződést hoz létre. A cél az adott fogyasztási igényhez igazított határ, nem minden hívás összeolvasztása.
Kötelező és opcionális függőség
Nem minden adat egyformán kritikus. Ha az opcionális adat hiányzik, az oldal még megjelenhet; ha egy fizetés eredménye nem ismert, a vásárlást nem szabad sikeresnek állítani. A degradált működést az üzleti jelentés alapján kell eldönteni, nem általános „hiba esetén üres lista” szabállyal (6.6).
Gyakori tévhitek
Röviden
Ellenőrző kérdések
Források