Ich bin neu bei Micro-Services und versuche, mein Projekt in ein auf Mikro-Services basierendes Projekt umzuwandeln. Mein Problem ist herauszufinden, wie jeder Dienst miteinander kommuniziert.
Zuerst habe ich den REST-Stil-Dienst erkundet, aber wenn jeder Dienst auf HTTP-REST basiert, "sprechen" sie schließlich miteinander?
Dann habe ich versucht, Spring Integration zu lernen, aber dann wurde es noch unklar, wie sie kommunizieren sollten, denn jetzt kam mir in den Sinn, dass ich vielleicht RabbitMQ als Middleware zwischen dem Front-End und dem Micro-Service-Backend verwenden muss.
Ich stoße auch auf Cloud- und Docker-Technologien, also denke ich, dass jeder Dienst in der Cloud sein sollte, aber es macht trotzdem nicht klar, wie Dienste miteinander kommunizieren.
Ich verwende Java, Spring-Technologien.
Ich würde mich freuen, wenn mir jemand ein besseres Bild von den Dingen geben würde.
Sie sind auf dem richtigen Weg. Die Bereitstellung eines Service mit einer REST-Architektur ist leistungsstark und einfach. Jeder Microservice stellt einige Funktionalitäten zur Verfügung, die von anderen Microservices aufgerufen werden können. Sie können dies mit SpingMVC und der Anmerkung @RestController tun. Um die REST-API aufzurufen, können Sie die Spring-Klasse RestTemplate verwenden.
Sie benötigen wahrscheinlich auch ein Gateway, das Anforderungen an den richtigen Dienst weiterleitet. Ich empfehle Ihnen, den Netflix Cloud Stack zu testen:
Wenn Sie Spring Boot verwenden, können Sie diese Architektur schnell mit einigen Anmerkungen einrichten.
Hier finden Sie ein einfaches Beispiel: Ссылка
Es gibt keinen Standard für Kommunikations- oder Transportmechanismen für Microservices. Im Allgemeinen kommunizieren Microservices miteinander unter Verwendung weit verbreiteter leichtgewichtiger Protokolle wie HTTP und REST oder von Messaging-Protokollen wie JMS oder AMQP. In bestimmten Fällen könnte man optimierte Kommunikationsprotokolle wie Thrift, ZeroMQ, Protocol Buffers oder Avro wählen.
Die Kommunikation zwischen Microservices kann entweder synchron (request-response) oder asynchron (fire und forget) erfolgen. Beide Ansätze haben ihre eigenen Vorzüge und Einschränkungen. Es ist nicht möglich, ein System mit nur einem Ansatz zu entwickeln. Aufgrund der Anwendungsfälle ist eine Kombination beider Ansätze erforderlich.
Sie sollten je nach Ihren Anwendungsfällen und Anforderungen diejenigen auswählen, die am besten zu Ihren Projekten passen.
Ich habe persönlich einen Eureka Discovery Service benutzt. Dies ist im Grunde der "Meister der Puppen" der Microservices, wenn Sie so wollen. Jeder Microservice meldet sich beim Start bei einem separaten Microservice (dem Discovery Service) an. Der Ermittlungsdienst kennt somit die Adresse und den Port jedes Mikroservice und jeder Microservice kann den Ermittlungsdienst fragen, welche (anderen) Microservices registriert sind. Darüber hinaus kann jeder Microservice den Discovery-Service einfach nach Informationen zu einem anderen Microservice fragen. Die gesamte Kommunikation (in meinem Fall) wurde mit REST durchgeführt, aber dies ist eine Wahl, da der Spring Boot mit der Abhängigkeit vom Eureka Discovery Service dies fördert.
Mit sehr wenig Konfiguration können Sie dieses ganze Framework zum Funktionieren bringen.
Dies basiert auf dem von Netflix verwendeten Framework. Ich glaube, Eureka ist sogar eine Netflix-Bibliothek.
Ich mag direkte API-Aufrufe von Dienst A zu Dienst B oder umgekehrt aus zwei Gründen nicht wirklich. Erstens schafft es eine Abhängigkeit zwischen Dienst A und B. Zweitens könnte es leicht eine Spaghetti-Art von unordentlichen Beziehungen erzeugen, wenn die Anzahl der Dienste wächst. Was ich gerne sehen möchte, ist ein Pub / Sub-Muster, z.B. Dienst A veröffentlicht eine Nachricht auf der Transportschicht (RabbitMQ ist keine schlechte Wahl) und geht weiter. Die Subskriptions- und Geschäftslogik zum Interpretieren der Nachricht ist in Service B gut gekapselt. Dadurch muss Service B überhaupt nichts über Service A wissen, und dennoch können sie gut miteinander kommunizieren.
Da Microservices eine synchrone Kommunikation miteinander eingehen, ist das große Problem die Kopplung, dh die Services sind nun miteinander gekoppelt, wenn einer von ihnen versagt, werden die Abhängigen nun vollständig oder teilweise deaktiviert / abstürzen, wäre eine bessere Lösung, die asynchrone Kommunikation für Zustandsänderungsoperationen zu verwenden.
Sie möchten klar zwischen Statuswechseloperationen und Leseoperationen unterscheiden (CQS-Befehlsabfragetrennung). Für Operationen, die den Status ändern, können Sie eine Art von Messaging-Infrastruktur verwenden und die Kommunikation unterbrechen und vergessen. Für Abfragen würden Sie eine synchrone Anfrageantwort-Kommunikation verwenden und könnten eine http-API verwenden oder einfach direkt zu Ihrem Datenspeicher gehen.
Wenn Sie Messaging verwenden, können Sie auch abonnieren abonnieren, um Ereignisse zwischen Services zu erhöhen.
Ein weiterer zu beachtender Punkt ist die (transaktionale) gemeinsame Nutzung von Daten (im Gegensatz zu schreibgeschützten Ansichten). Wenn Sie Ihren internen Zustand preisgeben, könnte der Leser den falschen Status Ihrer Daten oder die falsche Version erhalten und Ihre Daten möglicherweise sperren ?
Versuchen Sie nicht zuletzt, alles zu tun, um Ihre Dienste autonom zu halten (zumindest auf der logischen Ebene).
Ich hoffe, das macht Sinn.
Tags und Links java spring rest microservices spring-integration