Was sind Microservices? Ihre nächste Software-Architektur

Nahezu jedes Computersystem führt mehrere Aufgaben mit gemeinsam genutzten Ressourcen aus, und eine der Fragen der Computerprogrammierung ist, wie eng die Codebits, die diese Aufgaben ausführen, miteinander verknüpft werden sollten. Eine zunehmend beliebte Antwort ist das Konzept eines Mikrodienstes - ein kleiner, diskreter Funktionsblock, der mit anderen Mikrodiensten interagiert, um ein größeres System zu erstellen.

Obwohl die Grundidee, solche diskreten Komponenten zu haben, nicht neu ist, macht die Art und Weise, wie Microservices implementiert werden, sie zu einer natürlichen Grundlage für beide modernen Cloud-basierten Anwendungen. Microservices passen auch gut zur Devops-Philosophie, die die schnelle und kontinuierliche Einführung neuer Funktionen fördert.

Was sind Microservices?

Das "Mikro" in Microservices impliziert, dass dies kleine Anwendungen sind. Das ist manchmal wahr, aber eine bessere Art, über sie nachzudenken, ist, dass sie nur so groß sein sollten, wie es nötig ist, um eine bestimmte Sache zu tun oder ein bestimmtes Problem zu lösen. Dieses Problem sollte konzeptionell und nicht technisch sein. Microsoft drückt es so aus: "Microservices sollten auf Geschäftsfunktionen ausgerichtet sein, nicht auf horizontalen Ebenen wie Datenzugriff oder Messaging." Sie kommunizieren mit anderen Microservices und externen Benutzern über relativ stabile APIs, um eine größere Anwendung zu erstellen.

Somit kann die interne Funktionalität eines einzelnen Mikrodienstes optimiert oder radikal verbessert werden, ohne den Rest des Systems zu beeinträchtigen. Dies hängt wiederum damit zusammen, wie Devops-Shops arbeiten möchten: Wenn die spezifischen Funktionen einer größeren Anwendung in diskrete, unabhängig voneinander arbeitende Codeteile unterteilt sind, ist es einfacher, das Devops-Mantra von CI / CD (kontinuierliche Integration und kontinuierliche Bereitstellung) zu leben. . Durch gut definierte APIs können Microservices einfach automatisch getestet werden.

Microservices-Architektur vs. monolithische Architektur

Sie werden oft von Microservices hören, von denen im Sinne einer „Microservices-Architektur “ gesprochen wird. Dieser Satz umfasst nicht nur die Microservices selbst, sondern auch Komponenten für die Verwaltung und Serviceerkennung sowie ein API-Gateway, das die Kommunikation zwischen Microservices und der Außenwelt verwaltet.

Eine „monolithische Anwendung“ ist das Gegenteil von Microservices. Es ist ein Retronym für eine Anwendung, bei der sich der gesamte Code in einer großen ausführbaren Binärdatei befindet. Wie TechTarget erklärt, ist eine monolithische Anwendung schwieriger zu skalieren und zu verbessern. Da es sich jedoch um eine einzelne zusammenhängende Anwendung handelt, ist weniger Management erforderlich als bei einer Microservices-Architektur.

Begrenzte Konzepte: So definieren Sie einen Microservice

Lassen Sie uns für einen Moment auf unser früheres Gebot zurückkommen, dass Microservices eine bestimmte Sache tun sollten. Das ist leicht zu sagen, aber in der Praxis ist die Funktionalität oft miteinander verflochten, und das Zeichnen von Unterteilungen ist schwieriger als es aussieht. Domänenanalyse und domänengesteuertes Design sind die theoretischen Ansätze, mit denen Sie Ihre Gesamtaufgabe in einzelne Probleme zerlegen können, die ein Microservice lösen kann. In diesem Prozess, der in einer aufschlussreichen Reihe von Blog-Posts von Microsoft beschrieben wird, erstellen Sie ein abstraktes Modell Ihrer Geschäftsdomäne und entdecken dabei die begrenzten Kontexte , in denen Funktionen zusammengefasst werden, die auf bestimmte Weise mit der Welt interagieren.

Beispielsweise haben Sie möglicherweise einen begrenzten Kontext für den Versand und einen anderen für Konten. Ein reales physisches Objekt hätte natürlich sowohl einen Preis als auch einen Ort, an den es gehen muss, aber die begrenzten Kontexte stellen bestimmte Arten dar, wie Ihre Anwendung über diese Objekte nachdenkt und mit ihnen interagiert. Jeder Mikrodienst sollte vollständig in einem einzigen begrenzten Kontext existieren, obwohl einige begrenzte Kontexte möglicherweise mehr als einen Mikrodienst umfassen.

Microservices vs. serviceorientierte Architektur vs. Web Services

Wenn Sie ein IT-Profi sind, der schon eine Weile in der Branche tätig ist, denken Sie vielleicht, dass Ihnen vieles bekannt vorkommt. Die Idee, dass kleine Einzelprogramme zusammenarbeiten, könnte Sie sowohl an SOA (serviceorientierte Architektur) als auch an Webdienste erinnern , zwei Schlagworte aus den berauschenden Web 2.0-Tagen der 2000er Jahre. Während es in gewisser Hinsicht unter der Sonne wirklich nichts Neues gibt, gibt es wichtige Unterschiede zwischen diesen Konzepten und Microservices. Datamation hat eine gute Aufschlüsselung der Unterschiede, aber hier ist eine kurze Version:

  • In einer serviceorientierten Architektur sind einzelne Komponenten relativ eng miteinander verbunden und teilen sich häufig Assets wie Speicher und kommunizieren über eine spezielle Software, die als Enterprise Storage Bus bezeichnet wird . Microservices sind unabhängiger, teilen weniger Ressourcen und kommunizieren über leichtere Protokolle. Es ist erwähnenswert, dass Microservices aus dem SOA-Milieu entstanden sind und manchmal als eine Art SOA oder Nachfolger des Konzepts angesehen werden.
  • Ein Webdienst ist eine öffentlich zugängliche Reihe von Funktionen, auf die andere Anwendungen über das Web zugreifen können. Das wahrscheinlich am weitesten verbreitete Beispiel ist Google Maps, das auf der Website eines Restaurants eingebettet werden kann, um Kunden Anweisungen zu geben. Dies ist eine viel lockerere Verbindung als in einer Microservices-Architektur.

Microservices-Kommunikation

Ein Schlagwort, das Sie häufig über Microservices-Architekturen hören, lautet, dass sie über „intelligente Endpunkte und dumme Pipes“ verfügen sollten. Mit anderen Worten, Microservices sollten darauf abzielen, grundlegende und gut etablierte Kommunikationsmethoden anstelle einer komplexen und engen Integration zu verwenden. Wie bereits erwähnt, ist dies eine weitere Sache, die Microservices von SOA unterscheidet.

Im Allgemeinen sollte die Kommunikation zwischen Mikrodiensten asynchron sein , in dem Sinne, dass Codethreads nicht blockiert werden und auf Antworten warten. (Es ist immer noch in Ordnung, synchrone Kommunikationsprotokolle wie HTTP zu verwenden, obwohl asynchrone Protokolle wie AMQP (Advanced Message Queuing Protocol) auch in Microservices-Architekturen üblich sind.) Diese Art der losen Kopplung macht eine Microservices-Architektur angesichts des Fehlers flexibler einzelner Komponenten oder Teile des Netzwerks, was ein wesentlicher Vorteil ist.

Microservices, Java und Spring Boot und Spring Cloud

Einige der ersten Arbeiten im Bereich Microservices entstanden in der Java-Community. Martin Fowler war ein früher Befürworter. Auf einer Java-Konferenz 2012 in Polen wurde eine der wichtigsten frühen Präsentationen zu diesem Thema mit dem Titel „Mikrodienste - Java, der Unix-Weg“ vorgestellt. Es wurde empfohlen, die Prinzipien anzuwenden, die die Entwicklung der ersten Unix-Anwendungen in den 1970er Jahren leiteten („Write Programme, die eines tun und es gut machen. Schreiben Sie Programme, um zusammenzuarbeiten “) für die Java-Entwicklung.

Aufgrund dieser Historie gibt es zahlreiche Java-Frameworks, mit denen Sie Microservices erstellen können. Einer der beliebtesten ist Spring Boot, der speziell für Microservices entwickelt wurde. Das Booten wird durch Spring Cloud erweitert, mit der Sie, wie der Name schon sagt, diese Dienste auch in der Cloud bereitstellen können. Pivotal Software, der Entwickler von Spring, bietet ein gutes Tutorial für den Einstieg in die Microservice-Entwicklung mit diesen Frameworks.

Microservices und Container: Docker, Kubernetes und darüber hinaus

Die zugrunde liegende Technologie, die am weitesten fortgeschritten ist, um Microservices in den Mainstream zu bringen, sind Container .  Ein Container ähnelt einer VM-Instanz, aber anstatt ein vollständiges in sich geschlossenes Betriebssystem einzuschließen, ist ein Container nur ein isolierter Benutzerbereich, der den Kernel des Host-Betriebssystems verwendet, den Code jedoch ansonsten in sich geschlossen hält. Container sind viel kleiner als VM-Instanzen und können einfach lokal oder in der Cloud schnell bereitgestellt werden. Sie können je nach Bedarf und verfügbaren Ressourcen hoch- oder heruntergefahren werden.

Die Attraktivität von Containern für Microservices sollte offensichtlich sein: Jeder einzelne Microservice kann in einem eigenen Container ausgeführt werden, was den Aufwand für die Verwaltung von Services erheblich verringert. Die meisten Containerimplementierungen verfügen über ergänzende Orchestrierungswerkzeuge, die die Bereitstellung, Verwaltung, Skalierung, Vernetzung und Verfügbarkeit von containergestützten Anwendungen automatisieren. Es ist die Kombination aus kleinen, einfach zu erstellenden Microservices und einfach zu implementierenden Containern, die die Devops-Philosophie ermöglicht. Es gibt mehrere Implementierungen des Containerkonzepts, aber das mit Abstand beliebteste ist Docker, das im Allgemeinen mit Kubernetes als Orchestrierungsplattform gepaart wird.

Der Frühling ist zwar beliebt, aber an die Java-Plattform gebunden. Containerbasierte Systeme hingegen sind mehrsprachig: Jede vom Betriebssystem unterstützte Programmiersprache kann in einem Container ausgeführt werden, was Programmierern mehr Flexibilität bietet. Ein großer Vorteil von Microservices besteht darin, dass jeder einzelne Service in einer Sprache geschrieben werden kann, die am sinnvollsten ist oder mit der Entwickler am besten vertraut sind. In der Tat könnte ein Dienst vollständig in einer neuen Sprache neu erstellt werden, ohne das gesamte System zu beeinträchtigen, solange seine APIs stabil bleiben. DZone hat einen Artikel über die Vor- und Nachteile von Spring Cloud vs. Kubernetes für Microservices. 

Microservices-Entwurfsmuster

Unabhängig davon, in welcher Sprache Sie Microservices entwickeln, treten Probleme auf, auf die andere Entwickler bereits gestoßen sind. Entwurfsmuster sind formalisierte, abstrakte Lösungen für wiederkehrende Probleme in der Informatik, und einige von ihnen sind speziell für Mikrodienste bestimmt. Devopedia hat eine großartige Liste, die Folgendes enthält:

  • Serviceregistrierung: Zum Verbinden von Clients mit verfügbaren Instanzen von Microservices
  • Leistungsschalter: Um zu verhindern, dass fehlgeschlagene Dienste wiederholt aufgerufen werden
  • Fallback: Zum Bereitstellen einer Alternative zu einem fehlgeschlagenen Dienst
  • Beiwagen: Zum Bereitstellen eines Hilfsdienstes für den Hauptcontainer, z. B. zum Protokollieren, Synchronisieren von Diensten oder Überwachen
  • Adapter: Zum Standardisieren oder Normalisieren der Schnittstelle zwischen dem Hauptcontainer und der Außenwelt
  • Botschafter: Zum Verbinden des Hauptcontainers mit der Außenwelt, z. B. zum Proxying von Localhost-Verbindungen zu Außenverbindungen

Microservices und die Cloud : AWS und Azure

Wie oben erwähnt, besteht einer der Vorteile der Verwendung von Containern darin, dass sie problemlos in der Cloud bereitgestellt werden können, wo flexible Rechenressourcen verfügbar sind, sodass Sie die Effizienz Ihrer Anwendung maximieren können. Wie Sie sich vielleicht vorstellen können, sind die großen Anbieter öffentlicher Clouds bestrebt, dass Sie ihre Plattformen zum Ausführen Ihrer Microservice-basierten Apps verwenden. Weitere Informationen finden Sie in den Ressourcen von Amazon, Microsoft und Google.