Warum verlieren Architekturen auf Basis von Message Queues derzeit an Popularität?

xguru · 2024-06-21T11:03:01+09:00

Bis Anfang der 2010er Jahre wurde viel über den Aufbau verteilter Systeme auf MQ-Basis gesprochen, heute gibt es dazu deutlich weniger Beiträge Ich habe dazu ein paar Theorien im Kopf und würde gern wissen, ob eine davon zutrifft oder was andere dazu denken Redis deckt die meisten Anwendungsfälle ab, einschließlich Caching, sodass sich der Betrieb eines separaten Message Brokers nicht mehr lohnt. Kafka ist dann wirklich nur noch für sehr große Größenordnungen relevant. DBs (im weit gefassten Sinn) sind bei der Verarbeitung großer Mengen viel leistungsfähiger geworden, sodass „temporäre“ Verarbeitungen im Hauptspeicher umgesetzt werden Man hat erkannt, dass MQ-basierte Architekturen nicht so gut funktionieren wie erwartet, und nutzt jetzt andere Ansätze Tatsächlich ist MQ-Technologie inzwischen in die Reifephase eingetreten, deshalb ist sie für Beiträge nicht mehr spannend genug. Sie wird aber weiterhin breit eingesetzt hnthrowaway_99 Viele der „populären“ Architekturen aus den späten 2000ern bis frühen 2010ern sind verschwunden, nachdem man am Ende erkannt hatte: „Du bist nicht Google. Deine Firma wird niemals Google sein“ In dieser Zeit war der Wunsch groß, „so zu bauen, wie erfolgreiche Großunternehmen es gebaut haben“ Später wurde vielen klar, dass 99 % der Unternehmen diese Komplexität gar nicht brauchen Da Hardware und Standarddatenbanken viel besser geworden sind, brauchen immer weniger Unternehmen solche „Scalability Tricks“ Meine Schwelle für „Gibt es einen Grund, das nicht einfach mit Postgres zu machen?“ liegt heute viel höher als noch vor 10 Jahren Kommentare zu diesem Kommentar Es gibt jetzt viel größere Single-Machine-Systeme zu vertretbaren Kosten. Früher brauchte man kleine Cluster, heute kann ein einzelnes System schon sehr viele unterschiedliche Workloads tragen Ehrlich gesagt war ich bei Google an mehreren Projekten beteiligt, die Queues entfernt haben. Also ist es vielleicht sogar mehr als nur ein Popularitätsverlust biglain Etwas zynisch gesagt glaube ich, dass MQ-Architektur und das Bloggen darüber oft „Resume Driven Development“ waren. In Wirklichkeit handelte es sich um Dinge, die man auf einem einzelnen Laptop ausführen konnte, ohne über einen Monolithen hinaus skalieren zu müssen. Das sind vermutlich die Leute, die eine albtraumhafte Microservice-Katastrophe bauen und dafür monatlich AWS-Rechnungen in Höhe von zigtausend Euro zahlen „Menschen, die Karrierevorteile durch technische Prestigeleistungen höher priorisieren als die pragmatische Lösung echter Geschäftsprobleme“, hypen heute eher AI und schreiben darüber Blogposts tuckerconnelly Ich bin vor Kurzem von Microservices zurück zu einem Monolithen gewechselt, weil Microservices zu komplex wurden und zu viel doppelten Code hatten. Ohne Microservices sinkt auch der Bedarf an Message Queues Für asynchrone Aufgaben habe ich in einem Projekt RabbitMQ verwendet, und es wirkte zu alt und überengineert Auch viele Werkzeuge in diesem Umfeld (Celery) waren nicht so gut wie modernere Tools, die auf Redis (bullmq) aufbauen Bei mehrstufigen Prozessen im DAG-Stil bevorzuge ich, wenn möglich, alles in einem großen Job oder in einer kleinen Zahl von Jobs abzuwickeln Wenn man wirklich einen DAG braucht, gibt es dafür spezialisierte Tools (Airflow). Aber da ich gehört habe, dass sie schwer zu debuggen sind, sollte man sie möglichst vermeiden Ich bleibe bei Redis bei einem Single-Node-Setup, weil ich die Multi-Node-Architektur absurd überkomplex finde und sie beim Skalieren Probleme macht. Manuelles Sharding ist für mich dagegen in Ordnung und funktioniert gut Kommentar von kypro dazu Meiner Erfahrung nach reduzieren Monolithen Komplexität nicht, sie verschieben sie nur Das größte Problem von Monolithen ist, dass Belange zwischen Domänen nicht klar und explizit getrennt sind. Deshalb wird eine monolithische Codebasis mit der Zeit leicht zu einem stark verflochtenen Spaghetti-Code-Chaos Das gilt besonders, wenn man mit vielen Entwicklern ein großes Projekt baut und viele davon die Domänenkomplexität des Codes, an dem sie arbeiten, nicht vollständig verstehen Monolithen eignen sich für kleine Projekte mit wenigen Entwicklern, aber sonst werden die meisten es in ein paar Jahren bereuen, einen Monolithen gebaut zu haben Ich stimme auch beim Punkt mit dem doppelten Code nicht zu. Wenn man dieselbe Sprache nutzt und Pakete zwischen Projekten teilt, verstehe ich nicht, warum das ein großes Problem sein soll Jedenfalls habe ich bei der Arbeit mit Microservices solche Probleme nie erlebt Ich möchte auch infrage stellen, ob Microservices im Durchschnitt wirklich komplexer sind als Monolithen Was ich an Microservice-Architekturen am meisten mag, ist, wie einfach einzelne Microservices zu verstehen sind und wie leicht man dazu beitragen kann Die Architektur und das Provisioning von Microservices können komplexer sein, aber aus Sicht eines Entwicklers, der an einem einzelnen Microservice arbeitet, ist es im Vergleich zu einem Monolithen oft deutlich einfacher democracy Ich glaube, diese Einschätzung trifft zu: „MQ-Technologie ist inzwischen ausgereift, daher nicht mehr spannend genug, um darüber zu schreiben, wird aber weiterhin breit eingesetzt“ Messaging-basierte Architekturen sind sehr populär Kommentare dazu casper14: Stimme zu. Es ist einfach zu einem Werkzeug geworden. Genauso wie heute niemand mehr darüber schreibt, wie man Virtual Machines in der Cloud verwendet bwhaley: Genau das ist die richtige Antwort. Fast jedes verteilte System, das in großem Maßstab läuft, nutzt mit hoher Wahrscheinlichkeit in irgendeiner Form Message Queues ipsum2: Klingt plausibel. Früher waren Posts beliebt, in denen man Angular auf React umschrieb, heute nutzen einfach alle React oder schreiben darüber, wie sie React auf Vue umstellen busterarm Ich gebe mal eine unpopuläre Antwort Queues, Streams und Pub/Sub sind Konzepte, die die meisten Engineers nicht wirklich verstehen Sie wissen nicht, wann man sie braucht, nicht, wie man sie richtig nutzt, und setzen sie für die falschen Zwecke ein Ich arbeite immer noch mit all dem oben Genannten (SQS/SNS/RabbitMQ/Kafka/Google Pub/Sub) Ich arbeite in einem Unternehmen, das nur die angeblich „besten“ Engineers von den Top-3- oder Top-4-Unis Nordamerikas einstellt, und für fast alle ist es der erste Job Unsere Engineers haben unter anderem folgende verrückte Dinge getan: In RabbitMQ Zehntausende von 100-MB-Nachrichten in Sekunden in die Queue schieben und sich dann wundern, warum alles explodiert Trotz aller Warnungen allgemein ziemlich große Nachrichten über RabbitMQ schicken 2024 mit der neuesten RabbitMQ-Version ein neues Projekt starten und klassische Queues verwenden wollen Quorum Queues ohne Replikationsrichtlinien anlegen oder buchstäblich nichts für HA tun Einen Cluster mit guest/guest als Admin-Zugang dem Internet aussetzen Der ranghöchste Architekt der Organisation verkündet ein neues Architektur-Pattern, veranstaltet ein All-Hands-Meeting und macht eine Demo Er preist ein neues Muster an, bei dem man Nachrichten in eine Queue legt und dann einen Backchannel baut, damit ein zweiter Consumer Nachrichten bei Bedarf aus der Queue verarbeitet (und es damit keine Queue mehr ist) Und außer mir hat niemand gefragt: „Warum legt ihr Nachrichten, die in Reihenfolge verarbeitet werden müssen, überhaupt in eine Queue?“ — und dieses „Pattern“ hat sich durchgesetzt! Kafka als Standard-Message-Queue benutzen Daten aus einem zentralen Rechenzentrum in weltweit verteilte Rechenzentren übertragen und dabei ein globales Lock auf dem Objekt halten und alle Arbeiten blockieren, bis jedes Ziel-Rechenzentrum bestätigt hat, das aktualisierte Objekt empfangen zu haben. Und weil die Daten zusammen mit einem AJAX-Request gesendet wurden, zu behaupten, dieser Prozess sei asynchron Das Ergebnis ist, dass Leute immer noch einigermaßen klarkommen, obwohl sie gar nicht so großartige Dinge tun müssen. Deshalb werden die Werkzeuge falsch genutzt, missbraucht oder auch zu wenig genutzt Dort, wo sie gut genutzt werden, hört man vermutlich nichts davon Wichtige Tatsache: In unserer Organisation gibt es mehr als 30 Microservices pro Engineer. Bitte erlöst mich. Ich würde buchstäblich lieber Kurt Cobain werden, als in einer anderen Organisation mit einem riesigen Monorepo und Tausenden Microservices zu arbeiten Kommentare dazu zug_zug: Um diese Theorie mit echten Daten zu untermauern Ich habe in New York bei einem Startup gearbeitet, das Akka (Scalas eventbasiertes Queueing) verwendet hat Warum? Vielleicht weil ein Manager aus einem früheren Job in seinem neuen Job vorgeschrieben hat, das zu tun, nachdem er behauptete, es habe seine alte Firma „gerettet“, als „alles langsam war“? Welche Aufgaben brauchten dort tatsächlich Queueing? Mitarbeitern über eine Website ihr 401k zu zeigen, ihre Asset Allocation anpassen zu lassen und ein paar hundert E-Mails pro Tag zu versenden — das war alles Erwartungsgemäß loggten sich die Leute kaum auf der 401k-Website ein Etwa ein Jahr nach meinem Einstieg stellte ich fest, dass die Server die ganze Zeit falsch konfiguriert waren und die effektive Parallelität für Web-Requests im Grunde 0 war (Niemand hatte das bemerkt, weil zwei Produktionsserver ständig den gesamten nötigen Traffic abfangen konnten) Schließlich wurde Akka entfernt, weil es unnötige und unnötig komplexe Zusatzkomplexität verursachte Letzten Monat hat die Firma eine weitere Finanzierungsrunde mit Cash-out-Option abgeschlossen; die Bewertung ist offenbar gestiegen und es scheint ihr weiterhin gut zu gehen scary-size: Das klingt ehrlich gesagt nicht danach, als würdet ihr wirklich nur „brillante“ Engineers einstellen, oder? roncesvalles: Klingt, als gäbe es keinen Design-Review-Prozess. Und ich würde lieber Entwickler mit 2–5 Jahren Erfahrung von unbekannteren Hochschulen einstellen als frische Absolventen berühmter Unis. Was Software Engineers in den ersten fünf Jahren ihrer Karriere lernen und an Wachstum mitnehmen, ist enorm — wahrscheinlich mehr als im gesamten Rest ihrer Laufbahn zusammen. burutthrow Ich denke, MQ ist ziemlich stark zur Commodity geworden Wenn man Confluent, RedPanda oder MSK als Service einkauft, muss man Kafka nicht selbst betreiben Change Data Capture (CDC) ist ebenfalls sehr gut geworden und Mainstream. Daten in ein RDBMS schreiben und dann Änderungen erfassen und in andere Systeme propagieren, ist relativ einfach In solchen Mustern ist die Message Queue nur noch das Backbone, über das das CDC-System die Nachrichten überträgt — deshalb schreiben die Leute weniger über Kafka Diese Architekturen existieren eindeutig weiter und erfüllen für die meisten Organisationen die Randbedingungen Wenn man Queues wie Kafka hat, in die einmal geschrieben und mehrfach gelesen wird, kann man damit anderen Teilen der Organisation APIs bereitstellen. Viele Unternehmen nutzen dieses Muster, um Daten zwischen mehreren Teams zu verteilen Kleine Teams mit vielen Microservices wirken wie resume-getriebene Entwickler, aber in Unternehmen mit mehr als 100 Engineers ist dieses Muster sinnvoll angarg12 MQ ist ein Werkzeug im Werkzeugkasten verteilter Systeme. Wenn es passt, funktioniert es hervorragend Wenn deine Theorie zutrifft, dann wohl diese: „Leute schreiben Blogposts normalerweise über neue und glänzende Dinge“ Ich persönlich verwende in Designs immer wieder Queues, besonders wenn Daten zwischen verschiedenen Systemen mit hoher Entkopplung übertragen werden sollen Den einzigen Schmerz hatte ich, als ein Upstream-System sieben Tage an Daten nachträglich auffüllte und die Queue dadurch mit alten Requests verstopft wurde Bei normaler Abarbeitung hätte die Verarbeitung aller Daten mehr als 100 Stunden gedauert, und die Latenz für neue Daten wäre massiv angestiegen Die Lösung war, die Queue manuell zu leeren und die fehlenden aktuellen Daten manuell erneut einzuspielen Man muss auf ungebundene Queue-Größen achten, aber ich halte es weiterhin für ein großartiges Werkzeug rossdavidh MQ befindet sich im Gartner Hype Cycle an einem Punkt, an dem es den 'Peak of inflated expectations' hinter sich hat durch das 'trough of disillusionment' gegangen ist und sich auf den 'Slope of Enlightenment' oder sogar auf das 'plateau of productivity' zubewegt robertclaus Sehr interessant ist, dass der Kommentar „Offenbar verwenden wir alle weiterhin Message Queues und Worker, wir schreiben nur nicht mehr darüber“ in den Hintergrund gerät, weil die Debatte über Microservices und echte Skalierbarkeit alles überlagert Ein Junior Engineer, der das hier liest, könnte fälschlich den Eindruck bekommen, man solle rechenintensive Arbeit auf Webservern nicht mehr an Worker auslagern pm90 Die Zahl der Blogposts darüber ist gesunken, weil die Technologie langweilig geworden ist Das ist etwas Gutes. Zum Beispiel ist die offizielle RabbitMQ-Dokumentation heute viel besser und sehr nützlich Die Leute setzen es als Standardwerkzeug ein, so wie Postgres/MySQL Man braucht auch keine erstaunliche Technik, um Architektur und Ähnliches damit zu entwerfen Ich liebe langweilige Software: „I love boring software“ slowmovintarget Viele dieser Architekturen liefen früher in Unternehmensrechenzentren Mit dem Wechsel in die Cloud und dem Aufbau kleiner zustandsloser Services (plus dem Aufkommen von SPAs) wurde der Bedarf an komplexen, schrittweisen, eventgetriebenen Systemen geringer Auf AWS reicht zum Beispiel oft SQS mit etwas SNS oder in manchen Fällen Kinesis. MQ steht dann nicht mehr im Zentrum des Designs MQ-basierte Architekturen sind gut für Datenverarbeitung, aber nicht ideal für interaktive Websites. Wenn die meisten Leute interaktive Websites bauen, scheint die Wahl damit naheliegend Ich entwerfe weiterhin Event-Systeme für Datenverarbeitung (insbesondere für unveränderliche Geschäftsdaten, bei denen neue Fakten auftauchen können oder sich später herausstellt, dass man zu einem früheren Zeitpunkt andere Informationen hätte kennen müssen) Aber für die meisten Apps gilt: ... man braucht es nicht mannyv Unser gesamtes Backend basiert auf Queues Wenn etwas asynchron ist und keine schnelle Antwortzeit braucht, sollte man eine Queue verwenden. Das ist einfach und zuverlässig, und Queues können Lambdas antreiben Mit Queues lassen sich außerdem Metriken und Performance-Daten leichter erfassen. Unter hoher Last kann sich die Queue auf Hunderttausende bis Millionen Nachrichten aufblähen und später wieder abbauen Oder man startet einfach Hunderte Lambdas, um alle Nachrichten zu verarbeiten vishnugupta Nach meiner Erfahrung sind MQs eher abstrahiert worden, nicht verschwunden Zum Beispiel ist eine Queue wie SQS + Polling zu einem Prozess geworden, der Server seltener aufruft. Irgendwo gibt es also noch eine Message Queue, sie ist nur nicht mehr direkt sichtbar AWS SNS, also eine Abstraktionsebene über SQS, ist inzwischen so funktionsreich geworden, dass es SQS faktisch ersetzen kann Außerdem ist Streaming zu einer sehr stabilen Technologie geworden, sodass Anwendungsfälle, in denen Queues als Streaming-Pipeline verwendet wurden, zu reinem Streaming migriert sind memset Vielleicht liegt es daran, dass Lambdas (Cloud Functions) populärer geworden sind und auf vielen Plattformen unterstützt werden Wenn man etwas in eine Queue legt, muss es am Ende wieder herausgenommen und verarbeitet werden. Eine Lambda kann das in einem Aufruf erledigen. Außerdem muss man keine Worker betreiben oder skalieren Ich denke, Kafka bleibt beliebt, weil es als temporärer Datenspeicher genutzt wird und es ein großes Ökosystem für die Verarbeitung von Streams darum gibt Ich persönlich nutze Queues viel und baue eine Open-Source-Alternative zu SQS. Ich frage mich, ob auch eine Open-Source-Alternative zu Lambda nützlich wäre liampulles „MQ-Technologie ist inzwischen ausgereift, daher nicht mehr spannend genug, um darüber zu schreiben, wird aber weiterhin breit eingesetzt“ Das stimmt. Einfache Anwendungsfälle für asynchrone Kommunikation mit einfachem Pub/Sub-Messaging sind sehr nützlich und nicht allzu schwer zu verwenden Wir (als Entwickler-Community) haben Event Sourcing, komplexe Netzwerke und unnötige Größenordnungen hinter uns gelassen. Das heißt: Wir haben den Hype-Zyklus überwunden Unser Team nutzt NATS für asynchrones Pub/Sub und synchrones Request/Response Es ist ein befehlsbasiertes Modell, und wir haben eine große Log-Tabelle mit allen Nachrichten, die wir gesendet haben Das Schema und die Verwendung dieser Nachrichten sind intern auf unser Team beschränkt, und sie werden nach Gebrauch aus NATS gelöscht Wir arbeiten mit at-least-once delivery, und von den Message-Handlern wird Idempotenz erwartet Durch Fehlkonfigurationen von NATS gab es ein oder zwei Probleme mit erneut abgespielten oder verlorenen Nachrichten, aber insgesamt war es sehr erfolgreich, und wir waren ein Entwicklerteam aus nur drei Personen Für mich ist es wie Kubernetes: Wenn man sich an die Grundlagen hält und nicht versucht, übermäßig clever zu sein, funktioniert es gut

(news.ycombinator.com)

49 Punkte von xguru 2024-06-21 | 11 Kommentare | Auf WhatsApp teilen

Bis Anfang der 2010er Jahre wurde viel über den Aufbau verteilter Systeme auf MQ-Basis gesprochen, heute gibt es dazu deutlich weniger Beiträge
Ich habe dazu ein paar Theorien im Kopf und würde gern wissen, ob eine davon zutrifft oder was andere dazu denken
- Redis deckt die meisten Anwendungsfälle ab, einschließlich Caching, sodass sich der Betrieb eines separaten Message Brokers nicht mehr lohnt. Kafka ist dann wirklich nur noch für sehr große Größenordnungen relevant.
- DBs (im weit gefassten Sinn) sind bei der Verarbeitung großer Mengen viel leistungsfähiger geworden, sodass „temporäre“ Verarbeitungen im Hauptspeicher umgesetzt werden
- Man hat erkannt, dass MQ-basierte Architekturen nicht so gut funktionieren wie erwartet, und nutzt jetzt andere Ansätze
- Tatsächlich ist MQ-Technologie inzwischen in die Reifephase eingetreten, deshalb ist sie für Beiträge nicht mehr spannend genug. Sie wird aber weiterhin breit eingesetzt

hnthrowaway_99

Viele der „populären“ Architekturen aus den späten 2000ern bis frühen 2010ern sind verschwunden, nachdem man am Ende erkannt hatte: „Du bist nicht Google. Deine Firma wird niemals Google sein“
In dieser Zeit war der Wunsch groß, „so zu bauen, wie erfolgreiche Großunternehmen es gebaut haben“
Später wurde vielen klar, dass 99 % der Unternehmen diese Komplexität gar nicht brauchen
Da Hardware und Standarddatenbanken viel besser geworden sind, brauchen immer weniger Unternehmen solche „Scalability Tricks“
Meine Schwelle für „Gibt es einen Grund, das nicht einfach mit Postgres zu machen?“ liegt heute viel höher als noch vor 10 Jahren
Kommentare zu diesem Kommentar
- Es gibt jetzt viel größere Single-Machine-Systeme zu vertretbaren Kosten. Früher brauchte man kleine Cluster, heute kann ein einzelnes System schon sehr viele unterschiedliche Workloads tragen
- Ehrlich gesagt war ich bei Google an mehreren Projekten beteiligt, die Queues entfernt haben. Also ist es vielleicht sogar mehr als nur ein Popularitätsverlust

biglain

Etwas zynisch gesagt glaube ich, dass MQ-Architektur und das Bloggen darüber oft „Resume Driven Development“ waren. In Wirklichkeit handelte es sich um Dinge, die man auf einem einzelnen Laptop ausführen konnte, ohne über einen Monolithen hinaus skalieren zu müssen.
Das sind vermutlich die Leute, die eine albtraumhafte Microservice-Katastrophe bauen und dafür monatlich AWS-Rechnungen in Höhe von zigtausend Euro zahlen
„Menschen, die Karrierevorteile durch technische Prestigeleistungen höher priorisieren als die pragmatische Lösung echter Geschäftsprobleme“, hypen heute eher AI und schreiben darüber Blogposts

tuckerconnelly

Ich bin vor Kurzem von Microservices zurück zu einem Monolithen gewechselt, weil Microservices zu komplex wurden und zu viel doppelten Code hatten. Ohne Microservices sinkt auch der Bedarf an Message Queues
Für asynchrone Aufgaben habe ich in einem Projekt RabbitMQ verwendet, und es wirkte zu alt und überengineert
Auch viele Werkzeuge in diesem Umfeld (Celery) waren nicht so gut wie modernere Tools, die auf Redis (bullmq) aufbauen
Bei mehrstufigen Prozessen im DAG-Stil bevorzuge ich, wenn möglich, alles in einem großen Job oder in einer kleinen Zahl von Jobs abzuwickeln
Wenn man wirklich einen DAG braucht, gibt es dafür spezialisierte Tools (Airflow). Aber da ich gehört habe, dass sie schwer zu debuggen sind, sollte man sie möglichst vermeiden
Ich bleibe bei Redis bei einem Single-Node-Setup, weil ich die Multi-Node-Architektur absurd überkomplex finde und sie beim Skalieren Probleme macht. Manuelles Sharding ist für mich dagegen in Ordnung und funktioniert gut
Kommentar von kypro dazu
- Meiner Erfahrung nach reduzieren Monolithen Komplexität nicht, sie verschieben sie nur
- Das größte Problem von Monolithen ist, dass Belange zwischen Domänen nicht klar und explizit getrennt sind. Deshalb wird eine monolithische Codebasis mit der Zeit leicht zu einem stark verflochtenen Spaghetti-Code-Chaos
- Das gilt besonders, wenn man mit vielen Entwicklern ein großes Projekt baut und viele davon die Domänenkomplexität des Codes, an dem sie arbeiten, nicht vollständig verstehen
- Monolithen eignen sich für kleine Projekte mit wenigen Entwicklern, aber sonst werden die meisten es in ein paar Jahren bereuen, einen Monolithen gebaut zu haben
- Ich stimme auch beim Punkt mit dem doppelten Code nicht zu. Wenn man dieselbe Sprache nutzt und Pakete zwischen Projekten teilt, verstehe ich nicht, warum das ein großes Problem sein soll
- Jedenfalls habe ich bei der Arbeit mit Microservices solche Probleme nie erlebt
- Ich möchte auch infrage stellen, ob Microservices im Durchschnitt wirklich komplexer sind als Monolithen
- Was ich an Microservice-Architekturen am meisten mag, ist, wie einfach einzelne Microservices zu verstehen sind und wie leicht man dazu beitragen kann
- Die Architektur und das Provisioning von Microservices können komplexer sein, aber aus Sicht eines Entwicklers, der an einem einzelnen Microservice arbeitet, ist es im Vergleich zu einem Monolithen oft deutlich einfacher

democracy

Ich glaube, diese Einschätzung trifft zu: „MQ-Technologie ist inzwischen ausgereift, daher nicht mehr spannend genug, um darüber zu schreiben, wird aber weiterhin breit eingesetzt“
Messaging-basierte Architekturen sind sehr populär
Kommentare dazu
- casper14: Stimme zu. Es ist einfach zu einem Werkzeug geworden. Genauso wie heute niemand mehr darüber schreibt, wie man Virtual Machines in der Cloud verwendet
- bwhaley: Genau das ist die richtige Antwort. Fast jedes verteilte System, das in großem Maßstab läuft, nutzt mit hoher Wahrscheinlichkeit in irgendeiner Form Message Queues
- ipsum2: Klingt plausibel. Früher waren Posts beliebt, in denen man Angular auf React umschrieb, heute nutzen einfach alle React oder schreiben darüber, wie sie React auf Vue umstellen

busterarm

Ich gebe mal eine unpopuläre Antwort
Queues, Streams und Pub/Sub sind Konzepte, die die meisten Engineers nicht wirklich verstehen
- Sie wissen nicht, wann man sie braucht, nicht, wie man sie richtig nutzt, und setzen sie für die falschen Zwecke ein
- Ich arbeite immer noch mit all dem oben Genannten (SQS/SNS/RabbitMQ/Kafka/Google Pub/Sub)
Ich arbeite in einem Unternehmen, das nur die angeblich „besten“ Engineers von den Top-3- oder Top-4-Unis Nordamerikas einstellt, und für fast alle ist es der erste Job
Unsere Engineers haben unter anderem folgende verrückte Dinge getan:
- In RabbitMQ Zehntausende von 100-MB-Nachrichten in Sekunden in die Queue schieben und sich dann wundern, warum alles explodiert
- Trotz aller Warnungen allgemein ziemlich große Nachrichten über RabbitMQ schicken
- 2024 mit der neuesten RabbitMQ-Version ein neues Projekt starten und klassische Queues verwenden wollen
- Quorum Queues ohne Replikationsrichtlinien anlegen oder buchstäblich nichts für HA tun
- Einen Cluster mit guest/guest als Admin-Zugang dem Internet aussetzen
- Der ranghöchste Architekt der Organisation verkündet ein neues Architektur-Pattern, veranstaltet ein All-Hands-Meeting und macht eine Demo
  - Er preist ein neues Muster an, bei dem man Nachrichten in eine Queue legt und dann einen Backchannel baut, damit ein zweiter Consumer Nachrichten bei Bedarf aus der Queue verarbeitet (und es damit keine Queue mehr ist)
  - Und außer mir hat niemand gefragt: „Warum legt ihr Nachrichten, die in Reihenfolge verarbeitet werden müssen, überhaupt in eine Queue?“ — und dieses „Pattern“ hat sich durchgesetzt!
- Kafka als Standard-Message-Queue benutzen
- Daten aus einem zentralen Rechenzentrum in weltweit verteilte Rechenzentren übertragen und dabei ein globales Lock auf dem Objekt halten und alle Arbeiten blockieren, bis jedes Ziel-Rechenzentrum bestätigt hat, das aktualisierte Objekt empfangen zu haben. Und weil die Daten zusammen mit einem AJAX-Request gesendet wurden, zu behaupten, dieser Prozess sei asynchron
Das Ergebnis ist, dass Leute immer noch einigermaßen klarkommen, obwohl sie gar nicht so großartige Dinge tun müssen. Deshalb werden die Werkzeuge falsch genutzt, missbraucht oder auch zu wenig genutzt
Dort, wo sie gut genutzt werden, hört man vermutlich nichts davon
Wichtige Tatsache: In unserer Organisation gibt es mehr als 30 Microservices pro Engineer. Bitte erlöst mich. Ich würde buchstäblich lieber Kurt Cobain werden, als in einer anderen Organisation mit einem riesigen Monorepo und Tausenden Microservices zu arbeiten
Kommentare dazu
- zug_zug: Um diese Theorie mit echten Daten zu untermauern
  - Ich habe in New York bei einem Startup gearbeitet, das Akka (Scalas eventbasiertes Queueing) verwendet hat
  - Warum? Vielleicht weil ein Manager aus einem früheren Job in seinem neuen Job vorgeschrieben hat, das zu tun, nachdem er behauptete, es habe seine alte Firma „gerettet“, als „alles langsam war“?
  - Welche Aufgaben brauchten dort tatsächlich Queueing? Mitarbeitern über eine Website ihr 401k zu zeigen, ihre Asset Allocation anpassen zu lassen und ein paar hundert E-Mails pro Tag zu versenden — das war alles
  - Erwartungsgemäß loggten sich die Leute kaum auf der 401k-Website ein
  - Etwa ein Jahr nach meinem Einstieg stellte ich fest, dass die Server die ganze Zeit falsch konfiguriert waren und die effektive Parallelität für Web-Requests im Grunde 0 war
  - (Niemand hatte das bemerkt, weil zwei Produktionsserver ständig den gesamten nötigen Traffic abfangen konnten)
  - Schließlich wurde Akka entfernt, weil es unnötige und unnötig komplexe Zusatzkomplexität verursachte
  - Letzten Monat hat die Firma eine weitere Finanzierungsrunde mit Cash-out-Option abgeschlossen; die Bewertung ist offenbar gestiegen und es scheint ihr weiterhin gut zu gehen
- scary-size: Das klingt ehrlich gesagt nicht danach, als würdet ihr wirklich nur „brillante“ Engineers einstellen, oder?
- roncesvalles: Klingt, als gäbe es keinen Design-Review-Prozess. Und ich würde lieber Entwickler mit 2–5 Jahren Erfahrung von unbekannteren Hochschulen einstellen als frische Absolventen berühmter Unis. Was Software Engineers in den ersten fünf Jahren ihrer Karriere lernen und an Wachstum mitnehmen, ist enorm — wahrscheinlich mehr als im gesamten Rest ihrer Laufbahn zusammen.

burutthrow

Ich denke, MQ ist ziemlich stark zur Commodity geworden
Wenn man Confluent, RedPanda oder MSK als Service einkauft, muss man Kafka nicht selbst betreiben
Change Data Capture (CDC) ist ebenfalls sehr gut geworden und Mainstream. Daten in ein RDBMS schreiben und dann Änderungen erfassen und in andere Systeme propagieren, ist relativ einfach
In solchen Mustern ist die Message Queue nur noch das Backbone, über das das CDC-System die Nachrichten überträgt — deshalb schreiben die Leute weniger über Kafka
Diese Architekturen existieren eindeutig weiter und erfüllen für die meisten Organisationen die Randbedingungen
Wenn man Queues wie Kafka hat, in die einmal geschrieben und mehrfach gelesen wird, kann man damit anderen Teilen der Organisation APIs bereitstellen. Viele Unternehmen nutzen dieses Muster, um Daten zwischen mehreren Teams zu verteilen
Kleine Teams mit vielen Microservices wirken wie resume-getriebene Entwickler, aber in Unternehmen mit mehr als 100 Engineers ist dieses Muster sinnvoll

angarg12

MQ ist ein Werkzeug im Werkzeugkasten verteilter Systeme. Wenn es passt, funktioniert es hervorragend
Wenn deine Theorie zutrifft, dann wohl diese: „Leute schreiben Blogposts normalerweise über neue und glänzende Dinge“
Ich persönlich verwende in Designs immer wieder Queues, besonders wenn Daten zwischen verschiedenen Systemen mit hoher Entkopplung übertragen werden sollen
Den einzigen Schmerz hatte ich, als ein Upstream-System sieben Tage an Daten nachträglich auffüllte und die Queue dadurch mit alten Requests verstopft wurde
- Bei normaler Abarbeitung hätte die Verarbeitung aller Daten mehr als 100 Stunden gedauert, und die Latenz für neue Daten wäre massiv angestiegen
- Die Lösung war, die Queue manuell zu leeren und die fehlenden aktuellen Daten manuell erneut einzuspielen
Man muss auf ungebundene Queue-Größen achten, aber ich halte es weiterhin für ein großartiges Werkzeug

rossdavidh

MQ befindet sich im Gartner Hype Cycle an einem Punkt, an dem es
- den 'Peak of inflated expectations' hinter sich hat
- durch das 'trough of disillusionment' gegangen ist
- und sich auf den 'Slope of Enlightenment' oder sogar auf das 'plateau of productivity' zubewegt

robertclaus

Sehr interessant ist, dass der Kommentar „Offenbar verwenden wir alle weiterhin Message Queues und Worker, wir schreiben nur nicht mehr darüber“ in den Hintergrund gerät, weil die Debatte über Microservices und echte Skalierbarkeit alles überlagert
Ein Junior Engineer, der das hier liest, könnte fälschlich den Eindruck bekommen, man solle rechenintensive Arbeit auf Webservern nicht mehr an Worker auslagern

pm90

Die Zahl der Blogposts darüber ist gesunken, weil die Technologie langweilig geworden ist
Das ist etwas Gutes. Zum Beispiel ist die offizielle RabbitMQ-Dokumentation heute viel besser und sehr nützlich
Die Leute setzen es als Standardwerkzeug ein, so wie Postgres/MySQL
Man braucht auch keine erstaunliche Technik, um Architektur und Ähnliches damit zu entwerfen
Ich liebe langweilige Software: „I love boring software“

slowmovintarget

Viele dieser Architekturen liefen früher in Unternehmensrechenzentren
Mit dem Wechsel in die Cloud und dem Aufbau kleiner zustandsloser Services (plus dem Aufkommen von SPAs) wurde der Bedarf an komplexen, schrittweisen, eventgetriebenen Systemen geringer
Auf AWS reicht zum Beispiel oft SQS mit etwas SNS oder in manchen Fällen Kinesis. MQ steht dann nicht mehr im Zentrum des Designs
MQ-basierte Architekturen sind gut für Datenverarbeitung, aber nicht ideal für interaktive Websites. Wenn die meisten Leute interaktive Websites bauen, scheint die Wahl damit naheliegend
Ich entwerfe weiterhin Event-Systeme für Datenverarbeitung (insbesondere für unveränderliche Geschäftsdaten, bei denen neue Fakten auftauchen können oder sich später herausstellt, dass man zu einem früheren Zeitpunkt andere Informationen hätte kennen müssen)
Aber für die meisten Apps gilt: ... man braucht es nicht

mannyv

Unser gesamtes Backend basiert auf Queues
Wenn etwas asynchron ist und keine schnelle Antwortzeit braucht, sollte man eine Queue verwenden. Das ist einfach und zuverlässig, und Queues können Lambdas antreiben
Mit Queues lassen sich außerdem Metriken und Performance-Daten leichter erfassen.
- Unter hoher Last kann sich die Queue auf Hunderttausende bis Millionen Nachrichten aufblähen und später wieder abbauen
- Oder man startet einfach Hunderte Lambdas, um alle Nachrichten zu verarbeiten

vishnugupta

Nach meiner Erfahrung sind MQs eher abstrahiert worden, nicht verschwunden
Zum Beispiel ist eine Queue wie SQS + Polling zu einem Prozess geworden, der Server seltener aufruft. Irgendwo gibt es also noch eine Message Queue, sie ist nur nicht mehr direkt sichtbar
AWS SNS, also eine Abstraktionsebene über SQS, ist inzwischen so funktionsreich geworden, dass es SQS faktisch ersetzen kann
Außerdem ist Streaming zu einer sehr stabilen Technologie geworden, sodass Anwendungsfälle, in denen Queues als Streaming-Pipeline verwendet wurden, zu reinem Streaming migriert sind

memset

Vielleicht liegt es daran, dass Lambdas (Cloud Functions) populärer geworden sind und auf vielen Plattformen unterstützt werden
Wenn man etwas in eine Queue legt, muss es am Ende wieder herausgenommen und verarbeitet werden. Eine Lambda kann das in einem Aufruf erledigen. Außerdem muss man keine Worker betreiben oder skalieren
Ich denke, Kafka bleibt beliebt, weil es als temporärer Datenspeicher genutzt wird und es ein großes Ökosystem für die Verarbeitung von Streams darum gibt
Ich persönlich nutze Queues viel und baue eine Open-Source-Alternative zu SQS. Ich frage mich, ob auch eine Open-Source-Alternative zu Lambda nützlich wäre

liampulles

„MQ-Technologie ist inzwischen ausgereift, daher nicht mehr spannend genug, um darüber zu schreiben, wird aber weiterhin breit eingesetzt“
- Das stimmt. Einfache Anwendungsfälle für asynchrone Kommunikation mit einfachem Pub/Sub-Messaging sind sehr nützlich und nicht allzu schwer zu verwenden
Wir (als Entwickler-Community) haben Event Sourcing, komplexe Netzwerke und unnötige Größenordnungen hinter uns gelassen. Das heißt: Wir haben den Hype-Zyklus überwunden
Unser Team nutzt NATS für asynchrones Pub/Sub und synchrones Request/Response
- Es ist ein befehlsbasiertes Modell, und wir haben eine große Log-Tabelle mit allen Nachrichten, die wir gesendet haben
- Das Schema und die Verwendung dieser Nachrichten sind intern auf unser Team beschränkt, und sie werden nach Gebrauch aus NATS gelöscht
- Wir arbeiten mit at-least-once delivery, und von den Message-Handlern wird Idempotenz erwartet
Durch Fehlkonfigurationen von NATS gab es ein oder zwei Probleme mit erneut abgespielten oder verlorenen Nachrichten, aber insgesamt war es sehr erfolgreich, und wir waren ein Entwicklerteam aus nur drei Personen
Für mich ist es wie Kubernetes: Wenn man sich an die Grundlagen hält und nicht versucht, übermäßig clever zu sein, funktioniert es gut

11 Kommentare

finnchoi 2024-06-25

Es gibt Situationen, in denen eine Queue sinnvoll ist. In den meisten Größenordnungen und Nutzungsszenarien führt der Einsatz einer Queue oder der Betrieb als Cluster jedoch oft vor allem zu mehr Komplexität, ohne bei der Performance große Vorteile zu bringen. Der komplexe Aufbau, auf den große Unternehmen stolz sind und der mit Blick auf Skalierbarkeit und große Datenmengen entworfen wurde, ist für das eigene System womöglich nie wirklich angemessen.

Auch bei technisch attraktiven neuen Technologien und beeindruckenden Architekturen ist es wichtig, reale Probleme zu betrachten und eine passende Lösung zu wählen. In den meisten Fällen gibt es keine großen Datenmengen zu verarbeiten, und oft lässt sich vieles auch mit PostgreSQL bewältigen.

Wir haben dieses Problem erkannt und entwickeln eine DB, die bei einer einfachen Architektur Daten im TB-Bereich auf einem einzelnen Node verarbeiten kann. Etwas vorsichtig formuliert, aber wir empfehlen, sie als eine weitere Option in Betracht zu ziehen.
Rechtsfalldaten in einen schnell durchsuchbaren Zustand bringen

dakbutfly 2024-06-24

Prozedurale Ansätze sind im Mainstream leicht zu verstehen, aber ein MQ-Ansatz ist nicht sofort intuitiv und ich denke, dass es schwierig sein kann, die Struktur zu verstehen. In Unternehmen ist das Wissensniveau oft nicht bei allen gleich, und wenn man in so einer Situation MQ mit falschem Wissen einsetzt, wird es offenbar zur Hölle.

Ich denke, das ist nicht nur bei MQ so, sondern ein Problem, das immer dann auftritt, wenn Technologien, die ein gewisses Maß an Wissen erfordern, ohne umfassende Schulung eingeführt werden.

nemorize 2024-06-21

Bei PHP ist MQ praktisch unverzichtbar...

halfenif 2024-06-21

Autsch!

Ich arbeite gerade an einem Toy Project, in dessen Namen Quee vorkommt.

kandk 2024-06-21

Ehrlich gesagt denke ich, dass man 99 % davon gar nicht braucht, wenn der Service nur innerhalb unseres Landes angeboten wird..

superwoou 2024-06-21

Ist nicht eher die Art des Service bzw. wie stark auf Kosteneffizienz geachtet werden muss wichtiger als der Umfang des Service?

2024-06-21

[Dieser Kommentar wurde ausgeblendet.]

bus710 2024-06-22

Liegt es vielleicht daran, dass Entscheidungsprozesse eher vertikal organisiert sind und deshalb „prozedurale“ Ansätze bevorzugt werden oder als passender gelten?
Wenn einzelne Abteilungen und Teams hingegen locker gekoppelt organisiert sind, frage ich mich, ob dann eine weniger prozedurale Architektur reibungsloser funktioniert und dadurch auch Anwendungen solcher Queues besser funktionieren könnten.

savvykang 2024-06-21

Ich denke, dass „resume-driven development“ das Schlagwort ist, das dieses Phänomen solcher Trends durchzieht.

hyeonseokoh94 2024-06-22

Wow, das ist ja ein prägnanter Spruch: lebenslaufgetriebene Entwicklung …

savvykang 2024-06-23

Als verwandtes Produkt gibt es auch Hype-driven Development.