Serviceorientierte Architektur - AMQP oder HTTP
Ein wenig hintergrund.
Sehr großen monolithischen Django-Anwendung. Alle Komponenten nutzen die gleiche Datenbank. Wir müssen gesonderte Leistungen für so können wir unabhängig upgrade werden einige Teile des Systems, ohne den rest.
Verwenden wir RabbitMQ als broker Sellerie.
Rechts, jetzt haben wir zwei Optionen:
- HTTP-Services über eine REST-Schnittstelle.
- JSONRPC über AMQP zu einem event-loop service
Mein team ist eine Anlehnung an den HTTP-denn das ist, was Sie mit vertraut sind, aber ich denke, dass die Vorteile der Verwendung von RPC-über-AMQP überwiegen bei weitem.
AMQP bietet uns die Möglichkeiten, um einfach durch hinzufügen in den Lastenausgleich und hohe Verfügbarkeit, mit garantierten Nachricht Lieferungen.
In der Erwägung, dass mit HTTP wir erstellen client-HTTP-Wrapper für die Arbeit mit REST-Schnittstellen wir haben, um in einem load balancer und eingerichtet, dass die Infrastruktur in Ordnung zu haben, HA usw.
Mit AMQP ich kann nur spawn einer anderen Instanz des service, es wird eine Verbindung zu der gleichen Warteschlange wie die anderen Instanzen und bam, HA und load-balancing.
Bin ich etwas fehlt mit meine Gedanken über AMQP?
InformationsquelleAutor der Frage jreid42 | 2013-05-30
Du musst angemeldet sein, um einen Kommentar abzugeben.
Zunächst
pickle
die schneller sein soll als JSON-oder andere Formate.Also, wenn Sie wählen, was zu verwenden: HTTP+REST oder AMQP+RPC, die Antwort ist wirklich Thema der Infrastruktur-Komplexität und Ressourcen-Nutzung. Ohne irgendwelche spezifischen Anforderungen sowohl Lösung wird funktionieren, aber ich würde lieber einige Abstraktion, um in der Lage sein, zwischen Ihnen wechseln, transparent.
Sagte Sie, dass Ihr team vertraut mit HTTP, aber nicht mit AMQP. Wenn die Entwicklung Zeit ist eine wichtige Zeit, die Sie bekam eine Antwort.
Wenn Sie bauen wollen, HA-Infrastruktur mit minimalen Komplexität, die ich denke, AMQP-Protokoll ist, was Sie wollen.
Hatte ich ein Erlebnis mit den beiden und Vorteile von RESTful services sind:
Vorteile von AMQP-basierte Lösung:
Beachten Sie, dass Sie bieten RESTful API für third-party-services auf der Oberseite des AMQP-basierte API während der REST ist kein Protokoll, sondern Paradigma, aber Sie sollten darüber nachdenken, Sie bauen Ihre AQMP-RPC-api. Ich habe es getan, auf diese Weise zu versorgen, API zu externen third-party-Dienste und Zugriff auf die API auf diesen Teil der Infrastruktur, die es auf der alten Codebasis oder wo ist es nicht möglich, AMQP-support.
Wenn ich richtig deine Frage, wie man besser zu organisieren, die Kommunikation zwischen den verschiedenen Teile der software, nicht wie eine API bereitstellen, um end-Benutzer.
Wenn Sie einen high-load-Projekt RabbitMQ ist verdammt gutes Stück software, und Sie können einfach fügen Sie eine beliebige Anzahl von Beschäftigten, die auf unterschiedlichen Rechnern laufen. Auch er hat die spiegelung und clustering aus der box. Und eine weitere Sache, RabbitMQ ist, bauen auf Erlang OTP, das hoch-zuverlässige,stabile Plattform ... (bla-bla-bla), es ist gut nicht nur für marketing, sondern für die Ingenieure zu. Ich hatte ein Problem mit RabbitMQ nur einmal, wenn der nginx-logs nahm alle disc-Speicherplatz auf der gleichen partition, wo RabbitMQ laufen.
InformationsquelleAutor der Antwort pinepain
Die Ironie der Lösung OP hatte akzeptieren können, ist, AMQP oder andere MQ-Lösungen werden Häufig verwendet, um zu isolieren Anrufer aus den inhärenten Unzuverlässigkeit von nur-HTTP-services-um einige level von timeout & retry-Logik und message-Persistenz, so dass der Anrufer nicht implementieren müssen, um seinen eigenen HTTP-Isolierung-code. Eine sehr dünne, HTTP-gateway oder-adapter-Schicht über eine zuverlässige AMQP-core, mit der option, um direkt zu AMQP durch eine zuverlässige client-Protokolls, wie JSONRPC würde oft die beste Lösung für dieses Szenario.
InformationsquelleAutor der Antwort Chris Johnson