Zum Inhalt springen
TypFreigeschaltetPhaseProduktionSchwierigkeitMittelAufgabeStream teilenFürBackend-DevsFürDev TeamsServicesPipeServicesContainersWarum HoodyHTTP-nativWarum HoodyContainer-Ökonomie
TypFreigeschaltetPhaseProduktionSchwierigkeitMittelAufgabeStream teilenFürBackend-DevsFürDev TeamsServicesPipeServicesContainersWarum HoodyHTTP-nativWarum HoodyContainer-Ökonomie
TypFreigeschaltetPhaseProduktionSchwierigkeitMittelAufgabeStream teilenFürBackend-DevsFürDev TeamsServicesPipeServicesContainersWarum HoodyHTTP-nativWarum HoodyContainer-Ökonomie
TypFreigeschaltetPhaseProduktionSchwierigkeitMittelAufgabeStream teilenFürBackend-DevsFürDev TeamsServicesPipeServicesContainersWarum HoodyHTTP-nativWarum HoodyContainer-Ökonomie
Zurück zu Use Cases
use-cases / inter-container-ipc-without-the-broker / hero
PIPE · CONTAINER-ZU-CONTAINER

Inter-Container-IPC ohne Broker

Service A pipet seinen Output an einen Pfad. Service B zieht vom selben Pfad. Die Pipe routet Bytes zwischen den beiden Containern in Echtzeit. Kein Redis, keine Consumer Group, kein Broker-Daemon zum Babysitten.

Pipe-Docs lesen
use-cases / inter-container-ipc-without-the-broker / mechanism

Wie die Pipe den Broker ersetzt

Zwei HTTP-Verben und ein Pfad. Beide Seiten können sich zuerst verbinden; die Pipe wartet bis zu fünf Minuten auf das Gegenstück und streamt dann die Bytes durch. Keine Queue, kein Offset, keine Group.

01 · HANDSHAKE

Beide Seiten können sich zuerst verbinden

Producer offline? Consumer macht GET und wartet. Consumer offline? Producer macht PUT und wartet. Die Pipe hält die Verbindung bis zu fünf Minuten, bis das Gegenstück da ist.

02 · BACKPRESSURE

Die TCP-Verbindung ist die Queue

Wenn der Consumer langsam ist, bremst der Kernel den Stream des Producers. Keine Queue-Tiefe zu monitoren, kein Hochwassermarker zum Tunen. Der Socket ist der Buffer.

03 · STATELESS

Vergisst Nachrichten nach der Zustellung

Der ehrliche Trade-off: nichts wird persistiert. Für dauerhafte Queues ist das nichts. Für schnelles Container-zu-Container-Fan-out ist der Broker einfach verschwunden.

producer.sh · consumer.sh
# Container A — producer streamt Jobs an die Pipe
service-a | curl -T - https://api.hoody.com/api/v1/pipe/jobs

# Container B — consumer liest vom selben Pfad
curl https://api.hoody.com/api/v1/pipe/jobs | service-b

# Beide Seiten können sich zuerst verbinden.
# Die Pipe hält die Verbindung bis zu 5 Minuten
# bis das Gegenstück da ist, dann streamt sie durch.

PUT (oder POST) sendet. GET empfängt. Bytes landen nirgendwo auf einer Festplatte — sie überqueren die Leitung von Producer zu Consumer, während die Pipe im Flug weiterleitet.

use-cases / inter-container-ipc-without-the-broker / fanout

Füge einen dritten Leser hinzu. Dann einen vierten.

Wenn ein Logger oder ein Metriken-Sammler dieselben Events braucht, erhöhe ?n und füge einen curl hinzu. Keine Broker-Config, keine Consumer Group, kein Auth-Secret zum Rotieren. Der neue Leser existiert einfach.

pipe/jobs · Leser?n=4 · ALLES FAN-OUT
  • + HINZUGEFÜGT
    consumer-aloggermetricsaudit
    curl ?n=4 — schließt sich dem Fan-out an
  • = STABIL
    producer
    service-a | curl -T - ?n=4
  • − ENTFERNT
    redisconsumer-group.ymlbroker.conf
    kein Broker, keine Config

Ein langsamer Leser legt Backpressure auf den Producer; er blockiert die anderen nicht. Bis zu 256 Leser pro Pfad.

use-cases / inter-container-ipc-without-the-broker / advantages

Was die URL dir gibt, was der Broker dir genommen hat

Den Broker gab es, weil zwei Container nicht direkt miteinander reden konnten. Mit der Pipe können sie es. Alles, was der Broker dazugepackt hat — Auth, Clients, Ops — fällt weg.

  • Kein Daemon zum Betreiben

    Nichts zum Deployen, Monitoren oder Upgraden. Die Pipe ist die Plattform; die URL ist die einzige API.

  • Bearer-Auth, keine Broker-Credentials

    Ein Hoody-Token, pro Projekt scoped. Kein Pro-Broker-Username, kein Passwort, keine ACL-Datei.

  • Gleiche Leitung, jede Sprache

    Alles, was HTTP spricht, kann produzieren oder konsumieren — bash, Python, Go, ein Handy, ein Browser. Keine Client-Library.

  • Kein persistierter State

    Nachrichten leben im Flug, nicht auf der Festplatte. Keine Disk zum Vollschreiben, keine Aufbewahrungs-Policy, keine DSGVO-Frage zu Daten in der Queue.

  • Backpressure ist das Protokoll

    TCP bremst den Producer, wenn der langsamste Consumer hinterherhängt. Keine Lag-Dashboards, weil es keinen Lag gibt — nur Stream-Rate.

  • Container bleiben entkoppelt

    Producer und Consumer sehen nie die IPs des anderen. Sie teilen sich eine URL. Verschieb einen davon auf einen anderen Host, ohne neu zu verkabeln.

use-cases / inter-container-ipc-without-the-broker / punchline

Der Broker ist die URL. Die URL ist der Broker.

Die mittlere Schicht kollabiert. Was vorher ein stateful Daemon mit Credentials, Clients und Runbook war, ist jetzt ein Pfad. Das Architekturdiagramm hat eine Box weniger.

WAR DA
  • redis-ClusterAuth, Replicas, Failover
  • consumer-group.ymlOffsets, Partitions
  • Broker-SDK in jedem ServiceClient-Lib pro Sprache
IST DA
/api/v1/pipe/jobs

eine URL, ein curl, ein HTTP-Verb

Pipe-Docs lesen
use-cases / inter-container-ipc-without-the-broker / replaces

Was das ersetzt

Die Infrastruktur, zu der Teams greifen, wenn ein Container Bytes an einen anderen weiterreichen muss. Jede davon kommt mit einem Daemon, einer Config und einer On-Call-Rotation. Die Pipe verlangt nichts davon.

  • Redis Pub/SubDaemon, Auth, Clients pro Sprache
  • RabbitMQCluster zu betreiben für Bytes im Flug
  • NATSNoch ein Protokoll, noch ein Sidecar
  • ZeroMQLibrary in jedem Service, keine URL
  • Eigene Routing-DaemonsMaßgeschneiderter Service, der am Leben gehalten werden muss
  • gRPC-Streaming-ServicesSchema, Codegen, Mutual-TLS-Overhead
  • Apache Kafka BrokerStorage-Schicht für Nachrichten, die du nicht behältst
use-cases / inter-container-ipc-without-the-broker / cta

Redis aufsetzen, damit zwei Container miteinander reden? Oder eine URL teilen.

Pipe-API ansehen
use-cases / inter-container-ipc-without-the-broker / related

Lies die anderen