English· Español· Deutsch· Nederlands· Français· 日本語· ქართული· 繁體中文· 简体中文· Português· Русский· العربية· हिन्दी· Italiano· 한국어· Polski· Svenska· Türkçe· Українська· Tiếng Việt· Bahasa Indonesia

un

gäst
1 / ?

Noder, Kanter, Riktningar

En Begäran som En Promenad på en Graff

Varje komponent som begäran berör är en nod: kund, DNS upplösare, CDN kant, reversproxy, bakre replik, databas, cache.

Varje förbindelse mellan två noder är en riktad kant: begärande flödar framåt, svar flödar tillbaka. Framåt kanten representerar en öppen TCP-anslutning plus protokollet ovanpå.

En enda begäran är en väg genom denna graff. Det totala arbetet systemet gör för att svara på begäran är lika med summan av arbete vid varje nod, plus fördröjningen för varje kant.

Varför bry dig? När du ritat graffet dyker egenskaper som är osynliga i kod:

- Hoppavstånd: antalet kanter i vägen. Varje hopp lägger till fördröjning (nätverksomgång + nodbearbetning). Färre hopp = lägre grundläggande latens.

- In-grader: hur många kanter som pekar INTE mot en nod. Hög in-gradie är noden får begäranden från många källor och måste skalas eller skydda sig.

- Utg-grader: hur många kanter som pekar UTANIFRAN en nod. Hög ut-gradie innebär att noden beroende av många nedströms och har många sätt att misslyckas.

- Skärmnod: en enskild nod vars borttagande avkopplar graffet. En reversproxy utan par är en skärmnod; borttagandet tar bort alla tillgång till dess ursprung.

En begäran som väg genom riktad graff: kund, proxy, backend, databas

Rita (eller beskriv i text) begäran graff för: klientsida -> CDN kant -> reversproxy -> bakre replik -> databas. Räkna antalet hopp. Identifiera skärmnoder. Predikta en operativ konsekvens av att ha så många skärmnoder i rad.

Där Traffiken Koncentreras

Koncentration

In-kommande av ett knopp = antalet kanter som pekar inåt det. I en begäran graf, in-kommande = antal uppströms källor som skickar begäranden.

Koncentrationmönster: många kunder -> en CDN; många CDN kanter -> få ursprungskopior; många kopior -> färre bakre repliker; många backends -> en enda databas.

Koncentrationen är viktig eftersom det högsta in-kommande knippet ser den mest samlade lasten. Databasen på slutet av kedjan kan se frågor från varje aktiv begäran i hela systemet, även om ingen enskild användare genererar mycket.

Beroendefan

Uttänkande av ett knopp = antalet kanter som pekar utåt det. Högt uttänkande innebär många nedströms beroenden.

En backend som anropar en databas, två cacher, tre externa API:er & en kö har uttänkande 7. Dess lyckosannolikhet är ungefär produkten av varje nedströms lyckosannolikhet (om alla krävs för en lyckad svar).

0,999 ^ 7 ≈ 0,993: en backend med 7 nedströms varje på 99,9% tillförlitlighet kan bara uppnå ca 99,3% tillförlitlighet själv, även utan egna fel.

Minimera uttänkande genom: cacha nedströmsresultat, göra icke-kritiska nedströms-tjänster valfria (försuttring), parallellisera vad som kan parallelliseras.

Asymmetri

Koncentrationen koncentrerar last; fan-out multiplies risk. En välformad graff minimizes både på de högsta-impact knopparna.

Databasen (högsta koncentrationen): Cacha aggressivt för att minska lasten. Läs repliker för att sprida koncentrationen över flera knoppar.

Orkestrerande tjänst (högsta uttänkande): Kretsbräckare per beroende, försuttring, bulkheads.

En bakre kopia anropar 4 nedströms-tjänster, var och en oberoende 99,95% tillgänglighet. (1) Vilket är det övre gränsen för bakre tillgänglighet om alla 4 anrop krävs för en lyckad svar? (2) Om 2 av de 4 nedströms-tjänsterna görs valfria via försuttring (ersätta med cachelagrad återgång när otillgängliga), vilken blir gränsen?

En Inlagd Knopp Köper Flexibilitet

Indirekt väg = Att Lägga Till en Mellanmänen

Utan en proxy är grafen: klient -> backend. Klienten måste veta om backend-adressen. Att flytta backend kräver att uppdatera klienten (via DNS eller konfiguration). Detta innebär en stark bindning.

Med en proxy blir grafen: klient -> proxy -> backend. Klienten vet bara om proxy. Att flytta backend kräver att uppdatera proxyns uppströmskonfiguration, inte klienten.

Grafoperation: Infoga ett knappt längs en befintlig kant. Den nya kanten klient -> proxy är stabil; den nya kanten proxy -> backend är nu teamets att hantera.

Geometrisk läsning: Indirekt väg lägger till en skiktning som skiljer på upstream-förändringar och downstream-förändringar. Varje skikt kan dra åt olika.

Kostnad för Indirekt Väg

Varje skikt lägger till:

- En hop av fördröjning (kanten från klient till proxy)

- En ytterligare skärverk (proxy själv)

- En ytterligare plats för felkonfiguration

Fördelarna (omprogrammera, skala, skydda, avsluta TLS, fördela belastning) väger ofta över kostnaderna för något icke-trivialt system. Men det finns en gräns: varje indirekt skiktläggning lägger till en hop och en annan SPOF-kandidat.

Folklore-regeln: Varje problem kan lösas genom att lägga till en skiktning av indirekt väg (undantag: problemet med för många skikt av indirekt väg).

En team lägger till en CDN framför en existerande reverser proxy. Vägen går från `klient -> proxy -> backend` (2 hopp) till `klient -> CDN -> proxy -> backend` (3 hopp). Namnge två fördelar med indirekt väg (graf-teoretiska termer är välkomna) & två kostnader.

Läs en Arkitektur som en Graf

Sammanfattning

Du kan nu läsa en systemarkitektur som en graf: räkna hopp, identifiera skärverk, mäta fan-in-koncentration, beräkna tillgänglighetstak från fan-out och utvärdera indirekta handelsavtal.

Använd alla fyra.

En ny service har denna arkitektur: klienter -> CDN -> reversproxy (2 replikater) -> bakåtplan (8 replikater) -> { primärdatabas, cachekluster (3 noder), extern API }.

Analys: (1) vilken är den maximala hopp-kanten på en enskild begäran, (2) vilken nivå som har högst fan-in (& vad det innebär för skalering), (3) vilket är back-end-tillgänglighets tak om DB är 99,95 %, cacheminne är 99,95 % och extern API är 99,9 %, alla krävs, och (4) vilket enskilda knappt, om det tas bort, skulle skilja mest användare?

Kompletterande anteckningar

Kompletterande anteckningar

Denna geometri-lektion omformulerar huvudlektionen Proxies & Origins som en direktgrafanalys.

Nästa kompanjon i detta kurs, geometry_of_stateless_horizontal_scaling, tar replik-matematiken från huvudskalningelektionen och drar körcykeln, Little's lag och 80%-nyttoläget geometriskt.

Bra gjort.