Zwei Verkehrsrichtungen, eine Box
Willkommen
Die meisten Architekturdarstellungen zeigen den Verkehr in einer Richtung: Klienten oben, Server unten, Pfeil zeigt nach unten. Die Realität hat Verkehr in beiden Richtungen.
Eingang: Außenklienten erreichen Ihre Dienste über diese Strecke. Ein umgekehrter Proxy am Rand Ihres Netzwerks beendet TLS, leitet Anfragen und erzwingt Zugriffspolitik.
Ausgang: Ihre Dienste erreichen externe Dienste über diese Strecke. Aufruf eines Zahlungsverarbeiters API, Abruf einer Webhook-Ziel, Senden einer Anfrage an einen Partner. Oft durch einen vorwärtigen Proxy oder NAT-Gateway mit einer Zulassungsliste.
Viele Architekturen beginnen mit einer Box, die beide Aufgaben erledigt. Es funktioniert, bis an dem Tag, an dem es nicht mehr funktioniert. Das Versagenschema ist subtil, tritt nur nachdem genügend interne Dienste existieren, und lehrt eine wichtige Lektion über die Trennung von Sorgen.
Nach Abschluss dieses Kurses werden Sie verstehen:
- Warum Eingang und Ausgang grundlegend verschiedene Verkehrsmodelle mit unterschiedlichen Skalierungsachsen und unterschiedlichen Versagungsmodi sind
- Hairpin NAT und warum eine Proxy-Schicht, die versucht, sich selbst zu verbinden, versagt
- Die architektonische Gabel: Eine Box wird zu zwei, und was jede dann allein besitzt
- Sicherheitsisolierungsgewinne: Jede Seite kann sich auf ihre echten erlaubten Peers einstellen
- Wie man erkennt, wann Ihr Einzelbox-Design den Schwellenwert überschritten hat, an dem der Split notwendig ist
Warum die Richtungen unterschiedliche Werkzeuge verlangen
Zwei verschiedene Lasten an einer Netzwerkgrenze
Eingang Verkehrsmerkmale:
- Initiiert von außen (das Internet im Allgemeinen)
- Volumen skaliert mit Ihrer Benutzerbasis
- TLS-Beendigung, Anforderungsrouting, Begrenzung pro Quelle
- Verteidigung-in-Tiefe-Betrachtungen: DDoS, Missbrauch, Scraping
- Öffentliche IP-Adresse muss Verbindungen von jedem akzeptieren
Ausgang Verkehrsmerkmale:
- Initiiert von Ihren eigenen Diensten (eine bekannte, kleine Menge von Klienten)
- Volumen skaliert mit Ihrem Service-to-Service- und extern-API-Aufrufmuster
- Quell-IP-Zulassung bei entfernten Endpunkten (Sie haben eine feste Ausgangs-IP, auf die Partner vertrauen)
- Verteidigung in der Tiefe: Datenverlust, intern kompromittierte Dienste, die aussteigen
- Soll Verbindungen von anderen als Ihren eigenen Diensten ablehnen
Die Schlüsselasymmetrie: Eingang akzeptiert Verkehr von der Welt; Ausgang akzeptiert Verkehr nur von Ihren eigenen Diensten. Legt sie auf demselben Gerät ab, muss dieses Gerät gleichzeitig von der Welt erreichbar (für Eingang) & nur von Ihren Diensten erreichbar (für Ausgang) sein. Die Feuerwall-Regeln, die einer zufriedenstellen, arbeiten gegen die andere.
Der Wachstumszug: Ein kleines Projekt kann beide hinter einer IP und einem Tool verstecken, weil der Volumen gering ist und die Partner-IP-Zulassung kurz ist. Wenn das Projekt wächst, erhöht sich die Reibung zwischen den beiden Rollen und eines Tages zwingt eine spezifische Fehlermodus (Hairpin NAT) die Trennung.
Die Fehlfunktion, die den Split forzt
Eine Desinfektionsausfallgeschichte
Bilde dir vor, eine architektonische Gabelung, die in Produktionsflotten auftritt. Die Namen wurden geändert; die Form ist identisch zu dem, was Teams in der Wildnis treffen.
Eine Organisation betreibt einen Proxy-Server unter 203.0.113.5. Es handhabt Eingang (Port 443 für Benutzer) und Ausgang (Port 1080 SOCKS5 für interne Dienste, die aussteigen). Interne Dienste befinden sich in privaten Subnetzen und leiten alle aussteigenden Verkehr über diesen SOCKS5-Proxy auf 203.0.113.5:1080.
Ein von demselben 203.0.113.5 gehostete Dienst ist api.example.com. Die öffentliche DNS löst api.example.com auf 203.0.113.5 auf.
Jetzt benötigt eine andere interne Dienst api.example.com zum Aufruf.
1. Interne Dienst löst api.example.com auf 203.0.113.5
2. Interne Dienst sendet die Anfrage über den SOCKS5-Ausgangsproxy auf 203.0.113.5:1080
3. Der Proxy versucht, eine Verbindung von sich selbst zu 203.0.113.5:443 herzustellen
4. Verbindung abgewiesen. Das Paket müsste aus- und wieder einsteigen in den gleichen NAT, was die meisten Netzwerkknoten ab lehnen. Der Proxy kann sich nicht zu sich selbst über seine eigene öffentliche IP verbinden.
Dieses ist Haarschleifen-NAT: Eine Paket, die ein NAT verlässt & zum Erreichen ihrer Zieladresse wieder in das gleiche NAT eintreten muss. Ohne besondere Haarschleifenunterstützung in der Routingebene fällt das Paket.
Warum Es Spät Surft
Frühzeitig im Leben des Projekts, kommunizierten alle internen Dienste entweder mit anderen internen Diensten über den privaten Hostnamen (internal-api.local) oder riefen nicht in ihre eigenen Organisationen öffentliche Dienste zurück. Der Haarschleifenpfad existierte einfach nicht.
Dann benötigte eine neue Funktion, dass Dienst A api.example.com (eine öffentliche Hostname) aufruft. Der Haarschleifenpfad wurde aktiviert. Verweigerte Verbindung. Ausfall.
Das Patch löschte das Symptom (zwang die Resolver, api.example.com's private IP statt öffentliche zu geben). Die Ursache: Eine einzelne Box machte zu viele Jobs.
Der Architektonische Gabel
Eine Box Wird Zwei
Die saubere Lösung: Trennen Sie den Proxy in zwei Maschinen.
Einzugsserver (öffentliche IP 203.0.113.5):
- Caddy / Reverse Proxy auf Ports 80, 443
- Öffentliche DNS-Einträge zeigen hier
- Hostet api.example.com, app.example.com, usw.
Ausgangsserver (ein anderes öffentliches IP 203.0.113.99):
- SOCKS5 / Forward Proxy auf Port 1080
- Feuerwall beschränkt Eingänge auf interne Subnetz-IPs nur
- Interne Dienste leiten alle Ausgänge über diese Adresse
Was das kauft:
1. Haarschleifen gelöst. Ein interner Dienst, der api.example.com ruft, leitet auswärts via 203.0.113.99 (Ausgang), der dann normal zu 203.0.113.5 (Einzug, eine andere IP) anruft. Der NAT-Schleifen verschwindet, weil die beiden IPs auf verschiedenen Maschinen leben.
2. Sicherheitsisolierung. Der Firewall des Ausgangsservers kann auf eine kleine Gruppe von internen IPs eingeschränkt werden. Der Firewall des Einzugservers bleibt offen für die Welt. Zwei getrennte Regelsätze, jeder ausdrückt einen sauberen Rollen.
3. Unabhängiges Skalieren. Einzugsbandbreite skaliert mit Benutzern; Ausgangsbandbreite skaliert mit intern-Dienst-Aktivität. Erweitern Sie eines ohne das andere zu berühren.
4. Isolierung des Fehlers. Ein falsch konfiguriertes Ausgangs-System bricht nicht mehr die öffentliche Site. Eine DDoS-Angriff gegen die öffentliche Site hungert nicht mehr das Ausgangsbandbreite.
5. Klärere Denkmodell. Jede Maschine hat eine Aufgabe. Ingenieure denken über Eingangsbeträge ohne Eingabe von Eingaben und umgekehrt.
Zwei Achsen, zwei Größeneinstellungen
Unabhängiges Skalieren
Bevor die Trennung, wuchs sowohl in der einen als auch in der anderen Richtung die gleiche Maschine belastet. Nach der Trennung hat jede Richtung ihre eigene Bereitstellung.
Ingress-Größen: Skaliert mit den Benutzern. Kapazitätsentscheidungen befinden sich in der öffentlichen sichtbaren Ebene (mehr umgekehrte Proxy-Instanzen, größere VMs, CDN vorne). Bandbreitenbudget berechnet gegenüber Benutzerverkehr im Spitzenzeitpunkt.
Egress-Größen: Skaliert mit dem internen Service-externen API-Anrufvolumen. Oft dominiert von Webhook-Übertragung, Zahlungsverarbeitungsanrufe oder Abfragen von Drittanbietern. Bandbreitenbudget berechnet gegenüber internen Anrufmustern.
Isolierung von Fehlern: Eine DDoS-Angriff gegen die öffentliche Ingress belastet die Egress-Bandbreite (jene Zahlungsverarbeitungsanrufe gehen durch). Eine Egress-Proxy-Störung führt nicht zum Stillstand der öffentlichen Site (Benutzer erreichen die Site weiter; nur interne ausgehende Anrufe schlagen fehl).
Verschiedene SLOs: Ingress-Verfügbarkeit ist für die Benutzer wichtig (sichtbare Site-Störung); Egress-Verfügbarkeit ist für die Betreuer wichtig (Hintergrundfehler, die möglicherweise länger zum Erkennen benötigen). Jede Seite kann ihren eigenen SLO tragen.
Mehrere Egress-Server
Sobald die Egress-Rolle eine eigene Maschine hat, ist der nächste logische Schritt, mehrere Egress-Maschinen hinter einem Lastausgleicher zu betreiben, um Hochverfügbarkeit. Jedes neue internes Service zeigt auf den Egress-Hostname (der auf die Lastausgleich-pool abgebildet ist) anstatt auf eine einzelne IP.
Das Gleiche gilt wie für den Rest des verteilten Systems: Sobald eine Ebene stateless ist und ihre eigene Rolle hat, multipliziert sie sich günstig.
Eine neue Partnerintegration
Ihre Organisation führt die Ingress / Egress-Trennung wie geplant durch. Der Egress-Server hat einen festen öffentlichen IP-Adresse (203.0.113.99), der Sie mit drei bestehenden Partner-APIs (einem Zahlungsverarbeitungsanbieter, einem SMS-Gateway und einem E-Mail-Anbieter) erlaubt haben.
Ein Produktteam möchte eine vierte Integration hinzufügen: ein Webhook-Übertragungssystem, das weltweit in Kundeneintrittspunkte zurückruft. Vorhersage des Volumens: 10.000 Anrufe pro Minute, mit Spitzen bis zu 30.000.
Entwerfen eines Netzwerkgrenzbereichs für ein wachsendes Service
Synthesis
Sie haben gelernt, warum Ingress und Egress unterschiedliche Werkzeuge benötigen, die Haarschleifen-NAT-Fehler, der die Trennung in echten Flotten erzwingt, und wie unabhängige Skalierung, Sicherheitsisolation und Fehlerschaltung zulasten der Trennung anfallen.
Anwenden Sie alle vier.
Ein mittelgroßes SaaS-Unternehmen betreibt drei Produkt-Subdomänen (app, api, admin) für ihre Benutzer, plus vier ausgehende Integrationsanwendungen (Stripe, Twilio, SendGrid, ein Kunden-Webhook-System). Heute leben alles hinter einer einzigen Proxy-Maschine unter einer öffentlichen IP. Sie haben begonnen, gelegentliche Haarschleifen-Fehler bei internen Diensten zu erhalten, wenn sie versuchen, api.example.com aufzurufen. Sie möchten eine dauerhafte Lösung entwerfen.
Where This Course Goes Next
Where This Course Goes Next
Sie haben jetzt eine der saubersten Trennungsrefaktorisierungen in verteilten Systemen gesehen: Eine Box wird zu zwei, jeder mit einer klaren Rolle, und das System erbt Skalierung, Sicherheit und Fehlerschaltungseigenschaften.
Der nächste Leserichtung (cs_distsys_failure_modes_and_blast_radius) erweitert das Fehlerschaltung-Denken. Sie werden eine gesäuberte DNS-SERVFAIL-Postmortem lesen, das Fehlerschaltungsmuster identifizieren und schriftliche Schuldlos-Aktionspunkte erstellen, die auf Systeme abzielen, anstatt auf Menschen.
Kurzlehrstoff: geometry_of_ingress_egress_separation stellt die Trennung als bipartites Graph dar & untersucht Schnittknoten, Netzwerkpartitionen & was die Graphentheorie über eine Netzwerkgrenze aussagt.
Gut gemacht. Weiter.