Iggy.rs – Message Streaming mit Rust aufbauen

 (blog.iggy.rs)
3 Punkte von GN⁺ 2024-01-06 | 1 Kommentare | Auf WhatsApp teilen

Ursprung

  • Im April 2023 fiel die Entscheidung, Rust zu lernen.
  • Auf Basis von Erfahrungen mit verteilten Systemen und Messaging fiel die Entscheidung, eine Message-Streaming-Plattform zu entwickeln.
  • Ziel war es, die interne Funktionsweise von Messaging-Systemen und die Trade-offs von Entwicklern zu verstehen.
  • Daraus entstand Iggy.rs, mit dem Ziel einer Message-Streaming-Plattform, die Geschwindigkeit und Leichtgewichtigkeit betont.

Projekt

  • Das frühe Iggy bot grundlegende Funktionen für den Nachrichtenaustausch auf Basis des QUIC-Protokolls.
  • Durch kontinuierliches Prototyping und Verbesserungen wurde ein Server mit parallelem Schreiben/Lesen und Unterstützung unabhängiger Streams umgesetzt.
  • Durch die zusätzliche Unterstützung für TCP- und HTTP-Protokolle sowie die Optimierung des Datensynchronisierungsmechanismus wurde die Performance verbessert.
  • Benchmarking bestätigte hohen Durchsatz und geringe Latenz, woraufhin das Projekt zu einem langfristigen Vorhaben wurde.

Team

  • Iggy wird von einem Team mit rund 10 Mitgliedern getragen, das zu verschiedenen Bereichen beiträgt.
  • Beteiligt sind Projekte wie Core-Server, SDK, Web-UI und CLI.
  • Entwickler mit unterschiedlichen Hintergründen und gemeinsamer Leidenschaft fürs Programmieren beteiligen sich freiwillig.
  • Die Mitarbeit externer Contributor aus aller Welt stärkte das Vertrauen in das Projekt.

Funktionen

  • Hochperformanter, langlebiger, logbasierter Message-Streaming-Server.
  • Hoher Durchsatz, geringe Latenz und vorhersehbare Ressourcennutzung dank der kompilierten Sprache Rust.
  • Unterstützung für mehrere Streams, Topics und Partitionen sowie verschiedene Transportprotokolle.
  • RESTful API, Client-SDKs für verschiedene Sprachen und direkte Arbeit mit Binärdaten.
  • Konfigurierbare Serverfunktionen, serverseitige Speicherung von Consumer-Offsets und Unterstützung verschiedener Methoden zum Polling von Nachrichten.
  • Consumer-Gruppen für Nachrichtenreihenfolge und horizontale Skalierung sowie Funktionen für Nachrichtenablauf und Deduplizierung.
  • TLS-Unterstützung für alle Transportprotokolle, optionale Datenverschlüsselung und Unterstützung für Message-Header.
  • Integrierte CLI und Benchmarking-App zur Verwaltung des Streaming-Servers, Bereitstellung als einzelne Binärdatei.

Roadmap

  • Nach dem Erscheinen auf der GitHub-Trending-Seite wurden mit Nutzern Diskussionen über zusätzliche Funktionen geführt.
  • Ziel ist es, Performance und Zuverlässigkeit durch Clustering, Low-Level-I/O und eine Thread-pro-Core-Architektur zu verbessern.
  • Geplant sind Experimente mit dem Raft-Konsensmechanismus, Verbesserungen bei I/O-Operationen mit io_uring und der Einsatz der monoio-Runtime.

Zukunft

  • Ziel ist eine Message-Streaming-Plattform für allgemeine Einsatzzwecke, die die Grenzen von Betriebssystemen und Hardware herausfordert.
  • Geplant ist eine einfach zu nutzende integrierte Plattform mit Unterstützung für verschiedene Programmiersprachen, CLI und Web-UI.
  • Die Weiterentwicklung soll durch Feedback und Ideen aus der Community vorangetrieben werden.

GN⁺-Meinung

  • Iggy.rs ist eine Rust-basierte Message-Streaming-Plattform, die auf hohe Performance und geringe Latenz abzielt.
  • Als Open-Source-Projekt wächst sie kontinuierlich durch freiwillige Beteiligung und Beiträge von Entwicklern aus aller Welt.
  • Das ambitionierte Ziel, mit innovativen Technologien wie Clustering, Low-Level-I/O-Optimierung und einer Thread-pro-Core-Architektur die Performance-Grenzen verteilter Systeme zu überwinden, ist besonders spannend und macht das Projekt für Interessierte in diesem Bereich sehr lohnend.

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-01-06
Meinungen auf Hacker News
  • Geschichten wie diese waren der Grund, warum ich überhaupt zur Software gekommen bin
    Gemeinsam auf dasselbe Ziel hinzuarbeiten, auch wenn man unterschiedliche Beweggründe hat, und zu zeigen, dass finanzielle Vergütung nicht der einzige Zweck ist, wirkt idealistisch
    Ich wünsche dem Projekt Erfolg; ein Vergleich mit anderen Alternativen würde helfen, besser zu verstehen, wo dieses Projekt einzuordnen ist
    • Genau so hat es angefangen, und irgendwann wollen wir auch Benchmarks und Vergleiche mit anderen Tools aufnehmen
  • Gute Idee und guter Blogbeitrag
    Der Autor wirkt bescheiden, ehrlich und wie ein konstruktiver Projektleiter
    • Das Team ist wirklich großartig
      Alle haben sich dieser Anstrengung angeschlossen, auch mit dem Gedanken, dabei Spaß zu haben
  • Mit QUIC anzufangen, wirkt wie eine wirklich scharfsinnige und kluge Entscheidung
    Es bietet ähnlich wie SCTP nützliches Multistreaming und ist damit ein guter Ausgangspunkt; außerdem gibt es bereits viele gute Bibliotheken, die man nutzen kann, und es dürfte künftig noch besser und optimierter werden: https://github.com/xileteam/awesome-quic?tab=readme-ov-file#...
    Das ist ein Bereich, in dem schon ein etwas besseres Transportprotokoll als bisher große Vorteile bringen kann; ich bin gespannt auf QUIC in den nächsten zehn Jahren
    • Wir haben mit QUIC angefangen, weil wir etwas Neues ausprobieren wollten
      Allerdings ist das derzeit implementierte TCP-Protokoll etwas schneller als QUIC, was auch an fehlendem zusätzlichen Tuning liegen könnte
      Außerdem ist QUIC unter MacOS im Vergleich zu Linux langsam
  • Sieht das wie ein direkter Konkurrent zu JetStream aus? Beeindruckend, so viel Fortschritt in weniger als einem Jahr
    https://docs.nats.io/nats-concepts/jetstream
    • Es gibt ziemlich viele Message-Streaming-Lösungen wie JetStream, Kafka, Redpanda, RabbitMQ Streams und Fluvio
  • Mir ist nicht ganz klar, wie es im Vergleich zu Kafka und Fluvio, einem in Rust geschriebenen Kafka-Konkurrenten, dasteht
    Ist es eher näher an einer Message Queue wie RabbitMQ?
    https://www.fluvio.io/
    • Da es um Message Streams geht, ist es eher näher an Kafka, Redpanda und dem RabbitMQ-Streams-Plugin
      Fluvio ist ein echtes Produkt und hat ein Unternehmen dahinter, ist also reifer, aber wir haben eigene Ideen, um Iggy zu einer wettbewerbsfähigen Message-Streaming-Lösung zu machen
    • Zielt Fluvio nicht darauf ab, sowohl Flink als auch Kafka zu ersetzen? Ich habe gerade erst davon erfahren und versuche, es zu verstehen
  • Vor ein paar Jahren habe ich mit einem Freund etwas Ähnliches in Go gebaut
    https://github.com/thibauts/styx
    • Sieht ziemlich ähnlich aus
      Ich frage mich, warum ihr nicht weiter daran gearbeitet habt
  • Ich würde es irgendwann gern ausprobieren. Allerdings muss ich wohl zuerst Rust lernen
    Außerdem gefällt mir die Ästhetik der Website
    • Es gibt mehrere SDKs, und der Blog nutzt die Rust-Zola-Engine
    • Im Blogbeitrag werden SDKs für andere Programmiersprachen erwähnt, daher sollte man es wohl auch nutzen können, ohne Rust zu lernen
  • Dieser Beitrag hat mich dazu gebracht, mir den Ausgangspunkt von Fluvio noch einmal anzusehen
    Es ist ein kleines Team, das über die vergangenen Jahrzehnte lange Beziehungen zu datenorientierten Anwendungen in verschiedenen Domänen aufgebaut hat und seine Hoffnung für Data Streaming auf Rust und WebAssembly statt auf Java und die JVM setzt
    Hier ist ein Beitrag, in dem der CTO im Juni 2021 die Vision von Fluvio zusammengefasst hat: https://news.ycombinator.com/item?id=38880743
    Da die Vergleichsfrage immer wieder aufkommt, kann ich auch Materialien von Fluvio teilen. Es ist eine lange Dokumentationsarbeit, aber was wir derzeit haben, können wir teilen. Iggy ist ebenfalls wirklich gute Arbeit
  • Eine wirklich tolle Idee und ein tolles Projekt
    Bevor ich es ausprobiere, müsste ich aber zwei Dinge verstehen: wie man mehr als eine Serverinstanz ausführen kann, und wie bei mehreren Instanzen die Dateisystem-Interaktion zwischen den Servern aussieht
    • Im Blogbeitrag steht, dass es als Single Node läuft. Cluster-Support gibt es noch nicht
      Wenn Cluster unterstützt werden, könnte es mit Kafka konkurrieren
  • Die Wahl von monoio überrascht mich
    Soweit ich weiß, benötigt es den nightly-Compiler, und das halte ich bei der Wartung eines Projekts nicht für eine gute Wahl
    • Nightly ist zwar nötig, aber es werden nur fünf Features genutzt, und eines davon könnte man entfernen, wenn man eine externe Crate hinzufügt
      Die übrigen sind größtenteils auch nicht besonders radikal. Ich habe mir den Code nicht tief angesehen, aber alles wirkt nachvollziehbar. Eines davon ist zum Beispiel eine Standardbibliotheks-API zum Erstellen nicht initialisierter Container, wodurch Kopien vermieden werden können
      Ich habe glommio, das auf stable läuft, noch nicht mit monoio verglichen, aber das wäre interessant
    • Monoio wirkt wie die Runtime mit der besten Performance und ist in der Praxis auch einfach zu verwenden
      Deshalb haben wir uns für den Bleeding-Edge-Ansatz entschieden. Die Implementierung von io_uring und anderen Optimierungen wird ohnehin noch einige Monate dauern, und wahrscheinlich werden wir Teile des Kerns neu schreiben und zu einer Thread-pro-Core-Struktur wechseln