Serviceorientierte Architektur - Transportschicht (http vs. messaging)

Question

Wir betrachten die Migration unserer Architektur (und das Hinzufügen neuer Komponenten) mithilfe einer serviceorientierten Architektur (SOA). Es wird eine Reihe von externen APIs geben, die von Dritten verwendet werden, die wir unter Verwendung einer REST HTTP-Schnittstelle verwenden werden. Ich frage mich jedoch, was am besten intern zu verwenden ist, da alle Komponenten in unserer Kontrolle sind und auf der Gleiches Netzwerk, jedoch potenziell unterschiedliche Technologien (hauptsächlich .net und Ruby on Rails).

Wäre es große Leistung/Funktionalität Gewinne in der Verwendung eines Messaging-System (Redis, Rabbitmq, EMS, andere bemerkenswerte Ausnahmen habe ich noch nicht gehört ...) anstelle von HTTP (REST, SOAP, etc).

Ich habe gekämpft, um gute Informationen zu diesem Thema zu finden und (wie Sie wahrscheinlich sagen können) Ich bin ziemlich neu in diesem Bereich, so dass jeder Rat oder gute Ressourcen geschätzt werden würde!

Thnaks

Answer 1

Zusätzlich zu dem, was @Will Hartung erwähnt hat, würde ich auch sagen, dass es darauf ankommt, was Sie mit Ihrem System machen werden. Wenn Sie hauptsächlich Anwendungen vom Client-Server-Typ haben, bei denen Sie wenige Server/Dienste haben und diese in der Regel völlig unabhängig sind, ist es wahrscheinlich einfacher, Serviceverträge über REST über HTTP zu implementieren.

Wenn andererseits Ihr gesamtes System eine bidirektionale Kommunikation durchführt oder wenn es viele Interprozess-Aufrufe gibt (und insbesondere, wenn jeder Teilnehmer im System sowohl ein Client als auch ein Server ist) irgendwann), dann ist Messaging die beste Wahl. Unter den Messaging-Optionen finde ich, dass AMQP/RabbitMQ die umfangreichsten und benutzerfreundlichsten von allen ist. Es bietet Ihnen eine echte asynchrone Plattform zum Codieren.

Der Hauptvorteil der Verwendung von Messaging ist, dass Sie Warteschlangen für jeden Nachrichtentyp haben können. Wenn Ihr System erweitert und geändert wird, können die Warteschlangen/Nachrichten identisch sein, aber der Dienst, der sie verarbeitet, kann sich darunter ändern. Es fördert die Trennung von Schichten.

Schließlich, und das ist eine große Sache meiner Meinung nach, fördert die ordnungsgemäße Verwendung von Messaging kleine, unabhängige Teile des Codes. Diese sind testbarer und wartungsfreundlicher und vereinfachen im Allgemeinen Ihre Unternehmensarchitektur. Wenn Sie versuchen, zu viele Dienste von HTTP-Endpunkten zu behandeln, werden Sie schließlich (über den Verlauf eines Jahres oder zwei) entweder (1) viel zu viele Endpunkte, um zu verfolgen, oder (2) ein nicht zu behaltendes Durcheinander von Spaghetti-Code .

Meine Firma begann mit der Verwendung eines Nachrichten-basierten Frameworks, und es hat sehr gut für uns gearbeitet. Der RabbitMQ-Server war ohne weiteres die zuverlässigste Komponente. Fühlen Sie sich frei zu fragen, wenn Sie weitere Fragen zu Messaging oder SOA haben.

Answer 2

Messaging neigt Sie eine lose gekoppelte Architektur zu geben. Es kann möglicherweise auch robuster sein, da einzelne Komponenten ausfallen können, ohne die gesamte Infrastruktur zu zerstören.

Der Nachteil ist die Komplexität, der Paradigmenwechsel zu einem asynchronen Modell und möglicherweise die Leistung (vor allem, wenn Sie Nachrichten überall persistieren).

Sie müssen auch sicherstellen, dass Ihr Messaging-System besonders robust ist. Ein einzelner Aspekt Ihrer Logik kann heruntergefahren und neu gestartet werden, ohne dass dies Auswirkungen auf alles hat. Wenn Sie jedoch Ihre Kernbotschaft verlieren, wartet ALLES Ihre Logik darauf, dass das Messaging wieder verfügbar ist.

Glücklicherweise kann der Nachrichtenbus lange laufen, ohne dass Menschen damit herumhantieren und ihn berühren, die größte Quelle von Fehlern und Instabilität in jedem System.