Du hast deinen AdBlocker an?

Es wäre ein Traum, wenn du ihn für t3n.de deaktivierst. Wir zeigen dir gerne, wie das geht. Und natürlich erklären wir dir auch, warum uns das so wichtig ist. Digitales High-five, deine t3n-Redaktion

t3n 45

Die Minions der Softwareentwicklung: Wie Microservices funktionieren und was sie leisten

Seite 3 / 3

Neben REST über HTTP eignen sich auch asynchrone Kommunikationsprotokolle wie das Advanced Message Queuing Procotol (kurz genannt AMQP) sehr gut, um Services untereinander zu integrieren. Die Nutzung von AMQP ermöglicht beispielsweise die Implementierung einer Publish/Subscribe-Architektur. Zentrale Komponente in einer solchen Architektur ist ein so genannter Message Broker (eine beliebte Implementierung ist beispielsweise RabbitMQ, in welcher ein Service Nachrichten bei einem Message-Broker veröffentlichen kann; andere Services lassen sich dann am Broker für eine automatische Zustellung dieser Nachrichten registrieren.

Auf diese Weise werden der veröffentlichende und empfangende Service voneinander entkoppelt – dies geht so weit, dass der Sender gar nicht wissen muss, an wen er die Nachrichten später zustellen muss.

Deployment

Die Verteilung einzelner Services auf einzelne Server ist in Microservice-Architekturen komplexer, da nun nicht nur eine Applikation verteilt werden muss, sondern viele. Außerdem bauen diese womöglich auf verschiedenen Technologien auf. Als Antwort auf diese Herausforderung haben sich Container-Lösungen wie Docker oder rkt etabliert. Damit lassen sich Anwendungen mitsamt ihren Abhängigkeiten (wie etwa Laufzeitumgebungen und Bibliotheken) in Containern verpacken, die dann einfach ausgeliefert werden können.

Die Verteilung solcher Container über mehrere Server wird zudem von Cluster-Managern wie MesosKubernetes oder Swarm unterstützt. Allen Lösungen ist gemein, dass sie einen sehr hohen Grad der Automatisierung ermöglichen. Hierzu gehört beispielsweise, dass der Cluster-Manager die tatsächliche Verteilung von Containern auf die physischen Server übernimmt und Container automatisch dort platziert, wo noch entsprechende Kapazitäten frei sind.

Viele Lösungen übernehmen auch eine automatische Skalierung, um unter Last weitere Instanzen eines Services zu starten. Über einen etwas erweiterten Continuous-Delivery-Workflow lässt sich somit – ausgelöst durch eine Quelltextänderung in der Versionskontrolle – der gesamte Prozess vom Bauen eines Container-Abbilds, dessen Integrationstest sowie der Auslieferung der neuen Version einer Software über hunderte von Servern vollständig automatisieren.

Service Discovery

Ein Microservice ist nicht sonderlich nützlich, wenn er nicht für andere Services ansprechbar ist. Hierzu müssen Service-Konsumenten jedoch wissen, wo und auf welche Weise sie den Service erreichen. Dieses Problem nennt sich „Service Discovery“, also das Auffinden von Diensten in einer komplexen Architektur. Es ist insbesondere in hochdynamischen Architekturen wichtig, in denen beispielsweise ein Cluster-Manager wie Kubernetes abhängig von der aktuellen Last und nach eigenem Ermessen neue Instanzen von Services startet und beendet.

Service Discovery in einer (micro)serviceorientierten Architektur: In der zentralen Service Registry registrieren sich alle laufenden Dienste. Sie gibt darauf die Adressen der laufenden Instanzen an andere Dienste zurück, die einen bestimmten Dienst nutzen wollen.

Service Discovery in einer (micro)serviceorientierten Architektur: In der zentralen Service Registry registrieren sich alle laufenden Dienste. Sie gibt darauf die Adressen der laufenden Instanzen an andere Dienste zurück, die einen bestimmten Dienst nutzen wollen.

Die Abbildung zeigt eine abstrahierte Form einer (micro-)serviceorientierten Architektur mit Service Discovery. Zentrale Komponente ist die Service Registry, in der sich laufende Dienste registrieren (1). Möchten andere Dienste nun einen bestimmten Dienst nutzen, so können sie bei der Registry nach gerade laufenden Instanzen dieses Dienstes anfragen (2). Die Service Registry liefert dann eine oder mehrere Adressen (beispielsweise HTTP-URLs) zurück (3), unter denen der gewünschte Dienst erreichbar ist (4).

Als Lösungen haben sich hier vor allem Zookeeper und Consul etabliert. Insbesondere Consul erfreut sich aufgrund seiner Einfachheit und guter Integrationsmöglichkeiten zunehmender Beliebtheit und arbeitet gut mit Container- und Clustermanagern zusammen. So lassen sich beispielsweise neu gestartete Docker-Container automatisch als Service in Consul registrieren, um dort für andere Services zur Verfügung zu stehen.

Ausblick

Entwickler-Teams sollten Microservices nicht unreflektiert anwenden, da dies auch Risiken mit sich bringt. Durch die Aufteilung einer monolithischen Applikation in mehrere Microservices verlagert sich die Komplexität des Gesamtsystems von der Anwendungssoftware in die Orchestrierung der einzelnen Services. Um diese beherrschbar zu machen, ist der konsequente Einsatz von Automatisierung und Continuous Delivery nötig. Die Verteilung eines Systems über ein Netzwerk führt zudem neue mögliche Fehlerquellen ein, die es bei der Programmierung zu berücksichtigen gilt.

Werden diese Fallstricke berücksichtigt, ist die Microservice-Architektur ein guter Ansatz, um der steigenden Komplexität wachsender Softwaresysteme Herr zu werden. Der Ansatz ermöglicht es, eine Software schnell an sich verändernde Anforderungen anzupassen und zeitnah neue Technologien einzusetzen. Zudem sind so einzelne Teile der Applikation einfach skalierbar.

Darüber hinaus funktionieren Microservice-Architekturen sehr gut in Organisationen, die nach dem DevOps-Prinzip arbeiten, da einzelne Produktteams nun einen einzelnen Service über dessen kompletten Lebenszyklus betreuen und somit unabhängig und agil arbeiten können.

Startseite
  • Seite:
  • 1
  • 2
  • 3

Bitte beachte unsere Community-Richtlinien

Schreib den ersten Kommentar!

Du musst angemeldet sein, um einen Kommentar schreiben zu können.

Jetzt anmelden