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

un

Gast
1 / ?

Knoten, Kanten, Richtungen

Eine Anfrage als Wandel auf einem Graphen

Jedes komponente, auf die eine Anfrage trifft, ist ein Knoten: Client, DNS-Resolver, CDN-Kante, Reverse-Proxy, Backend-Replica, Datenbank, Cache.

Jede Verbindung zwischen zwei Knoten ist eine gerichtete Kante: Anfragen fließen vorwärts, Antworten fließen zurück. Die vorwärtseitige Kante repräsentiert eine offene TCP-Verbindung plus das darauf liegende Protokoll.

Eine einzelne Anfrage ist ein Pfad durch diesen Graphen. Die gesamte Arbeit, die das System für die Beantwortung der Anfrage leistet, entspricht der Summe der Arbeit an jedem Knoten, plus der Latenz jeder Kante.

Warum interessiert es? Sobald Sie den Graphen gezeichnet haben, werden Eigenschaften sichtbar, die in der Code-Implementierung unsichtbar bleiben:

- Hop-Count: die Anzahl der Kanten im Pfad. Jeder Hop fügt Latenz hinzu (Netzwerkrunde trip + Knotenverarbeitung). Weniger Hops = niedrigere Latenzuntergrenze.

- In-Degree: die Anzahl der Kanten, die auf einen Knoten zeigen. Hoher In-Degree bedeutet, dass der Knoten Anfragen von vielen Quellen empfängt und skalieren oder sich schützen muss.

- Out-Degree: die Anzahl der Kanten, die von einem Knoten weg zeigen. Hoher Out-Degree bedeutet, dass der Knoten auf viele downstream-Abhängigkeiten angewiesen ist und viele Möglichkeiten zum Scheitern hat.

- Schnittknoten: ein einzelner Knoten, dessen Entfernung den Graphen trennt. Ein Reverse-Proxy ohne Peer ist ein Schnittpunkt; seine Entfernung trennt alle Zugriffe auf seine Ursprünge ab.

Anfrage als Pfad durch gerichteten Graphen: Client, Proxy, Backend, Datenbank

Zeichnen Sie (oder beschreiben Sie in Text) den Anforderungsgraphen für: Client-Browser -> CDN-Kante -> Reverse-Proxy -> Backend-Replica -> Datenbank. Zählen Sie die Hops. Identifizieren Sie die Schnittpunkte. Prognostizieren Sie eine betriebsbedingte Folge von so vielen Schnittpunkten in Reihe.

Wo sich der Datenverkehr konzentriert

Fan-In = Konzentration

Grad des Eingangs eines Knotens = Anzahl der Kanten, die auf es zeigen. In einem Anforderungsgraphen ist der Grad des Eingangs die Anzahl der upstream-Quellen, die Anfragen senden.

Fan-in-Muster: viele Clients -> ein CDN; viele CDN-Ränder -> wenige Ursprung-Proxys; viele Proxy -> weniger Backend-Replikate; viele Backends -> einzelne Datenbank.

Konzentration ist wichtig, weil das Knoten mit dem höchsten Grad des Eingangs die meisten aggregierten Lasten sieht. Die DB am Ende der Kette kann Anfragen von jedem aktiven Anforderung im gesamten System sehen, selbst wenn keine einzelne Benutzer viel erzeugt.

Fan-Out = Abhängigkeit

Grad des Ausgangs eines Knotens = Anzahl der Kanten, die von ihm weg zeigen. Hoher Grad des Ausgangs bedeutet viele downstream-Abhängigkeiten.

Ein Backend, das eine Datenbank, zwei Caches, drei externe APIs und eine Warteschlange aufruft, hat einen Grad des Ausgangs von 7. Seine Erfolgswahrscheinlichkeit ist ungefähr das Produkt der Erfolgswahrscheinlichkeit jedes downstreams (wenn alle für einen erfolgreichen Antwort erforderlich sind).

0,999 ^ 7 ≈ 0,993: Ein Backend mit 7 downstreams, die jeweils eine Zuverlässigkeit von 99,9% haben, kann nur eine etwaige Zuverlässigkeit von 99,3% erreichen, selbst wenn es keine eigenen Fehler hat.

Reduzieren Sie den Grad des Ausgangs, indem Sie downstream-Ergebnisse cachen, nicht-kritische downstreams optional machen (sanfte Degradation), was parallelisiert werden kann.

Die Asymmetrie

Fan-in konzentriert die Last; fan-out multipliziert das Risiko. Ein gut geformter Graph minimiert beide am höchstwichtigen Knoten.

Die Datenbank (höchster Fan-in): Cache aggressiv, um die Last zu reduzieren. Lesereplikate, um den Fan-in über mehrere Knoten hinweg zu verteilen.

Der Orchestrator-Dienst (höchster Fan-out): Schaltungsbrecher pro Abhängigkeit, sanfte Degradation, Bulkheads.

Ein Backend-Replikat ruft 4 downstream-Dienste auf, jeweils unabhängig mit einer Verfügbarkeit von 99,95%. (1) Welk ist die obere Schranke für die Verfügbarkeit des Backends, wenn alle 4 Aufrufe für einen erfolgreichen Antwort erforderlich sind? (2) Wenn 2 der 4 downstreams optional mittels sanfter Degradation (ersetzt durch gecachete Stornierungen, wenn sie nicht verfügbar sind) gemacht werden, was wird der Wert sein?

Ein eingefügtes Knoten bringt Flexibilität

Indirektheit = Hinzufügen eines Zwischenknotens

Ohne Proxy ist das Diagramm: Kunde -> Backend. Der Kunde muss über die Adresse des Backends informiert sein. Eine Verlegung des Backends erfordert eine Aktualisierung des Clients (über DNS oder Konfiguration). Dies ist eine enge Bindung.

Mit einem Proxy wird das Diagramm zu: Kunde -> Proxy -> Backend. Der Kunde weiß nur über den Proxy. Eine Verlegung des Backends erfordert eine Aktualisierung der Proxy-Upper-Stream-Konfiguration, nicht die des Clients.

Die Diagramm-Operation: Einfügen eines Knotens entlang einer bestehenden Kante. Die neue Kante Kunde -> Proxy ist stabil; die neue Kante Proxy -> Backend ist jetzt das Team, das sie verwalten muss.

Geometrische Lesart: Indirektheit fügt eine Schicht hinzu, die eine Trennung von oberflächlichen Änderungen von unteren Änderungen ermöglicht. Jede Schicht kann unabhängig voneinander neu verdrahtet werden.

Kosten der Indirektheit

Jede Schicht fügt hinzu:

- Eine Latenz (der Kante von Client zu Proxy)

- Eine weitere Schnittknotenpunkt auf dem Weg (den Proxy selbst)

- Eine weitere Stelle, an der eine Fehlkonfiguration auftreten kann

Die Vorteile (neu verdrahten, skalieren, schützen, TLS beenden, Last verteilen) überwiegen in der Regel die Kosten für jedes nicht-wenig System. Aber es gibt ein Limit: jede Indirektheitsschicht fügt einen weiteren Hüpfer und einen weiteren Kandidaten für einen SPOF hinzu.

Das Volksweisheitssprichwort: Jedes Problem kann durch das Hinzufügen einer Schicht indirekter Abstraktion gelöst werden (außer dem Problem zu viele Schichten von Indirektheit).

Ein Team fügt einen CDN vor einer bestehenden Reverse-Proxy-Anwendung hinzu. Der Weg verläuft von `Kunde -> Proxy -> Backend` (2 Sprünge) zu `Kunde -> CDN -> Proxy -> Backend` (3 Sprünge). Nenne zwei Vorteile der Indirektheit (graph-theoretische Begriffe willkommen) & zwei Kosten.

Lesen Sie eine Architektur als Diagramm

Synthese

Sie können jetzt eine Systemarchitektur als Diagramm lesen: Zähle Hüpfer, identifiziere Schnittknoten, misse Fan-in-Konzentration, berechne Verfügbarkeitsdächer aus Fan-out und bewerte Indirektheit-Handelsabschlüsse.

Anwenden Sie alle vier.

Ein neues Service hat diese Architektur: Kunden -> CDN -> Reverse-Proxy (2 Replikate) -> Backend-Schicht (8 Replikate) -> { DB-Primär, Cache-Cluster (3 Knoten), externer API }.

Analysieren Sie: (1) was ist die maximale Anzahl von Hüpfern auf einem einzelnen Anforderungsverbindungsweg, (2) welche Schicht hat die höchste Fan-in-Konzentration (und was bedeutet dies für die Skalierung), (3) was ist die Deckelhöhe für die Verfügbarkeit des Backends, wenn die DB 99,95%, der Cache 99,95% und der externe API 99,9% sind, alle erforderlich, und (4) welcher einzelne Knoten trennt, wenn er entfernt wird, die meisten Benutzer?

Kommilitonennotizen

Kommilitonennotizen

Diese Geometrie-Übung stellt das Hauptthema Proxies & Origins als eine direkte Graphanalyse dar.

Die nächste Begleitübung in diesem Kurs, geometry_of_stateless_horizontal_scaling, nimmt die Replikatemathematik aus dem Hauptskalierungsunterricht und ableitet die Warteschlangenkurve, Little's Gesetz und den 80%-Auslastungsknie geometrisch.

Sehr gut gemacht.