- Ein Drop-in-Service, der SQS direkt ersetzen kann und die Developer Experience deutlich verbessert
- Bietet eine funktionale UI, Sichtbarkeit, Nachverfolgung, Message Scheduling und Rate Limiting
- Eine private SQS-Instanz kann in jeder Cloud betrieben werden
- Wird als einzelnes Go-Binary bereitgestellt und kann mit bestehenden SQS-Clients verwendet werden
- Die UI läuft auf
:3000, der SQS-kompatible Server auf :3001
- Kompatibel mit SQS-Clients aller Sprachen
- Python
-
import boto3
# Es muss nur endpoint_url geändert werden
sqs = boto3.client("sqs", ..., endpoint_url="http://localhost:3001")
sqs.send_message(QueueUrl="...", MessageBody="hello world")
- Funktioniert auch reibungslos mit Celery
-
app = Celery("tasks", broker_url="sqs://...@localhost:3001")
Meinung von GN⁺
- SmoothMQ erweitert die Funktionen von SQS und bietet Entwicklern eine bessere Erfahrung
- Da sich eine private Instanz ohne Cloud-Bindung betreiben lässt, ist die Lösung sehr flexibel
- Bestehende SQS-Clients können unverändert weiterverwendet werden, wodurch die Umstellungskosten gering bleiben
- Über die UI lassen sich Queues und Messages einfach verwalten, was die Betriebseffizienz erhöht
- Bei der Einführung neuer Technologien sollte die Kompatibilität mit bestehenden Systemen ausreichend berücksichtigt werden
3 Kommentare
SQLite und Postgres wird man wohl auch in 10 Jahren noch verwenden. Bei Redis dachte ich das auch, aber inzwischen bin ich mir da nicht mehr so sicher.
Was verwendet man heutzutage statt Redis?
Hacker-News-Kommentare
Die Idee ist großartig, k8s-, kubernetes-, cloud-native-, self-hosted- und edge-enabled-Technologien günstig nutzbar zu machen
rqundminiomehrere Jahre auf k8s verwendet und richtet den Blick in letzter Zeit auf SQLite als AlternativeEs wird darauf hingewiesen, dass SQLite auf einem einzelnen Server läuft und in den meisten Fällen funktioniert, aber nicht zu 100 % zuverlässig ist
Abgesehen von Skalierung und Benchmarks ist es ein nützliches Tool für Feature-/Unit-Tests, die SQS verwenden
Zielt auf ein gehostetes Queue-System ab und will günstiger als SQS sein, ohne dabei Leistung zu opfern
Jemand schreibt gern AWS-API-kompatible Dienste und erwähnt das Projekt Dyna53
Mit LocalStack kann man SQS und viele AWS-Services für Tests/Entwicklung verwenden; es ist gut dokumentiert und Open Source
Es gefällt, wenn Projekte einfache self-hosted Alternativen zu populären Services bauen
Ein schneller Vorschlag zur Projektstruktur:
models/in das Root-Verzeichnis zu verschiebenq.Messageundq.Queueverwenden, und Namenskonflikte werden vermieden, falls Nutzer ein eigenes PaketmodelshabenElasticMQ wird erwähnt; es wird genutzt, um SQS in Docker-Umgebungen zu simulieren
Es wird gefragt, warum die Unterstützung für Fremdschlüssel deaktiviert wird, obwohl sie im Datenbankschema weiterhin verwendet werden
TODO: check for errorsund Stellen, die das Prüfen von Fremdschlüssel-Constraints zu deaktivieren scheinen, lassen zögern, es auszuprobieren