Microservices zerlegen monolithischen Code in leicht zu wartende Blöcke und sind der Schlüssel zur Devops-Philosophie. [...]
Fast jedes Computersystem führt mehrere Aufgaben mit gemeinsamen Ressourcen aus, und eine der Grundfragen der Computerprogrammierung ist, wie eng die Codebits, die diese Aufgaben ausführen, miteinander verknüpft sein sollten. Eine immer beliebtere Antwort darauf ist das Konzept eines Microservices – ein kleiner, diskreter Teil der Funktionalität, der mit anderen Microservices interagiert, um ein größeres System zu schaffen.
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 stimmt auch mit der Devops-Philosophie überein, die eine schnelle und kontinuierliche Einführung neuer Funktionen fördert.
Was sind Microservices?
Das „Micro“ in Microservices impliziert, dass es sich um kleine Anwendungen handelt. Das ist manchmal wahr, aber eine bessere Art, darüber zu reflektieren, ist, dass sie nur so groß wie nötig sein sollten, um eine bestimmte Sache zu tun oder ein bestimmtes Problem zu lösen. Dieses Problem sollte konzeptionell und nicht technisch sein. Wie Microsoft es ausdrückt: „Microservices sollten auf der Grundlage von Unternehmensfunktionen konzipiert werden, nicht auf horizontalen Ebenen wie Datenzugriff oder Messaging“. Sie kommunizieren mit anderen Mikroservices und externen Benutzern über relativ stabile APIs, um eine größere Anwendung zu erstellen.
So kann die interne Funktionalität eines einzelnen Microservice optimiert oder radikal erweitert werden, ohne den Rest des Systems zu beeinträchtigen. Dies wiederum hängt damit zusammen, wie Devops-Shops funktionieren sollen: Wenn die spezifischen Funktionen einer größeren Anwendung in diskrete, unabhängig arbeitende Codeteile zerlegt werden, ist es einfacher, das Devops-Mantra von CI/CD (Continuous Integration and Continuous Delivery) zu leben. Darüber hinaus erleichtern gut definierte APIs das automatische Testen von Microservices.
Microservices-Architektur vs. monolithische Architektur
Sie werden oft hören, dass Microservices in Form einer „Microservices-Architektur“ diskutiert werden. Dieser Begriff umfasst nicht nur die Microservices selbst, sondern auch Komponenten für Management und Service Discovery sowie ein API-Gateway, das die Kommunikation zwischen Microservices und der Außenwelt übernimmt.
Eine „monolithische Anwendung“ ist das Gegenteil von dem, was Microservices sind. Es ist ein Retronym für eine Anwendung, bei der sich der gesamte Code in einer großen binären ausführbaren Datei befindet. Wie TechTarget erklärt, ist eine monolithische Anwendung schwieriger zu skalieren und zu verbessern. Da es sich jedoch um eine einzige zusammenhängende Anwendung handelt, erfordert es nicht so viel Management wie eine Microservices-Architektur.
Begrenzte Konzepte: Wie man einen Microservice definiert
Lassen Sie uns für einen Moment zu unserem früheren Gebot zurückkehren, dass Microservices eine bestimmte Sache tun sollen. Das ist einfach zu sagen, aber in der Praxis ist die Funktionalität oft verworren, und das Zeichnen von Teilungen ist schwieriger, als es aussieht. Domänenanalyse und domänengesteuertes Design sind die theoretischen Ansätze, die Ihnen helfen, Ihre Großbildaufgabe in individuelle Probleme zu zerlegen, die ein Mikroservice lösen kann. In diesem Prozess, der in einer aufschlussreichen Reihe von Blog-Posts von Microsoft skizziert wird, erstellen Sie ein abstraktes Modell Ihrer Geschäftsdomäne und entdecken dabei die begrenzten Kontexte, die Funktionen zusammenfassen, die auf eine bestimmte Weise mit der Welt interagieren.
Beispielsweise können Sie einen begrenzten Kontext für den Versand und einen anderen für Konten haben. Ein realistisches physisches Objekt hätte natürlich sowohl einen Preis als auch einen Ort, an den es gehen muss, aber die begrenzten Kontexte stellen spezifische Möglichkeiten dar, wie Ihre Anwendung darüber nachdenkt und mit diesen Objekten interagiert. Jeder Microservice sollte vollständig in einem einzigen begrenzten Kontext existieren, obwohl einige begrenzte Kontexte mehr als einen Microservice umfassen können.
Microservices vs. Service-orientierte Architektur vs. Webservices
Wenn Sie an dieser Stelle ein IT-Profi sind, der schon eine Weile in der Branche tätig ist, könnte Ihnen vieles davon bekannt vorkommen. Die Idee, dass kleine Einzelprogramme zusammenarbeiten, könnte Sie sowohl an SOA (Service-orientierte Architektur) als auch an Web Services erinnern, zwei Schlagworte aus den berauschenden Web 2.0-Tagen der 2000er Jahre. Während es in gewisser Weise wirklich nichts Neues unter der Sonne gibt, gibt es wichtige Unterschiede zwischen diesen Konzepten und Microservices. Datamation hat eine gute Aufschlüsselung der Unterschiede, aber hier ist eine Kurzversion:
In einer serviceorientierten Architektur sind die einzelnen Komponenten relativ eng miteinander verbunden, wobei sie sich oft Assets wie Speicher teilen, und sie kommunizieren über eine spezielle Software, den sogenannten Enterprise Storage Bus. Microservices sind unabhängiger, teilen sich weniger Ressourcen und kommunizieren über einfachere Protokolle. Es ist anzumerken, dass Microservices aus dem SOA-Milieu entstanden sind und manchmal als eine Art SOA oder Nachfolger des Konzepts angesehen werden.
Ein Webservice ist ein öffentlich zugänglicher Funktionssatz, auf den andere Anwendungen über das Web zugreifen können; das wahrscheinlich häufigste Beispiel ist Google Maps, das die Website eines Restaurants einbetten könnte, um den Kunden eine Wegbeschreibung zu geben. Dies ist eine viel lockerere Verbindung, als man sie in einer Microservices-Architektur sehen würde.
Kommunikation mit Microservices
Ein Schlagwort, das Sie oft über Mikroservice-Architekturen hören werden, ist, dass sie „intelligente Endpunkte und dumme Pipes“ enthalten sollten. Mit anderen Worten, Microservices sollten darauf abzielen, grundlegende und etablierte Kommunikationsmethoden anstelle einer komplexen und engen Integration zu verwenden. Wie bereits erwähnt, ist dies eine weitere Besonderheit, die Microservices von SOA unterscheidet.
Im Allgemeinen sollte die Kommunikation zwischen den Microservices asynchron erfolgen, in dem Sinne, dass Code-Threads nicht blockiert werden, wenn sie 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 flexibler gegenüber dem Ausfall 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 der Microservices stammen aus der Java-Community; Martin Fowler war ein früher Befürworter. Auf einer Java-Konferenz 2012 in Polen wurde einer der wichtigsten Vorträge zum Thema mit dem Titel „Micro services – Java, the Unix Way“ gehalten. Es wurde empfohlen, die Prinzipien anzuwenden, die bei der Entwicklung der ersten Unix-Anwendungen in den 1970er Jahren galten („Schreiben Sie Programme, die eine Sache machen und es gut machen. Schreiben Sie Programme, damit sie zusammenarbeiten“) in der Java-Entwicklung.
Als Ergebnis dieser Geschichte gibt es viele Java-Frameworks, die es Ihnen ermöglichen, Microservices aufzubauen. Einer der beliebtesten ist Spring Boot, der speziell für Microservices entwickelt wurde; Boot wird um Spring Cloud erweitert, die es Ihnen, wie der Name schon sagt, ermöglicht, diese Dienste auch in der Cloud einzusetzen. Pivotal Software, der Entwickler von Spring, hat ein gutes Tutorial über den Einstieg in die Entwicklung von Microservices mit diesen Frameworks zur Verfügung gestellt.
Microservices und Container: Docker, Kubernetes und darüber hinaus
Die grundlegende Technologie, die am weitesten fortgeschritten ist, um Microservices in den Mainstream zu bringen, sind Container. Ein Container ist ähnlich wie eine VM-Instanz, aber anstatt ein komplettes, in sich geschlossenes Betriebssystem einzubinden, ist ein Container nur ein isolierter Benutzerbereich, der den Kernel des Host-Betriebssystems nutzt, den Code aber ansonsten in sich selbst führt. Container sind viel kleiner als VM-Instanzen und lassen sich einfach und schnell implementieren, entweder lokal oder in der Cloud, und können nach Bedarf und verfügbaren Ressourcen auf- oder abgefahren werden.
Die Attraktivität von Containern für Mikroservices sollte offensichtlich sein: Jeder einzelne Microservice kann in einem eigenen Container laufen, was den Aufwand für die Verwaltung von Services deutlich reduziert. Die meisten Containerimplementierungen verfügen über ergänzende Orchestrierungswerkzeuge, die die Bereitstellung, Verwaltung, Skalierung, Vernetzung und Verfügbarkeit von containerbasierten Anwendungen automatisieren. Es ist die Kombination aus kleinen, einfach zu erstellenden Microservices und einfach zu implementierenden Containern, die die Devops-Philosophie möglich macht. Es gibt mehrere Implementierungen des Containerkonzepts, aber die bei weitem beliebteste ist Docker, das in der Regel mit Kubernetes als Orchestrierungsplattform kombiniert wird.
Spring ist zwar beliebt, aber an die Java-Plattform gebunden. Container-basierte Systeme hingegen sind mehrsprachig; sie können sich auf eine Vielzahl von Systemen stützen: Jede Programmiersprache, die das Betriebssystem unterstützt, kann in einem Container ausgeführt werden, was den Programmierern mehr Flexibilität gibt. In der Tat ist ein großer Vorteil von Microservices, dass jeder einzelne Service in der Sprache geschrieben werden kann, die am sinnvollsten ist, oder mit der sich die Entwickler am wohlsten fühlen. Tatsächlich könnte ein Dienst vollständig in einer neuen Sprache neu aufgebaut werden, ohne das System als Ganzes zu beeinträchtigen, solange seine APIs stabil bleiben. Die DZone hat einen Artikel über die Vor- und Nachteile von Spring Cloud vs. Kubernetes für Microservices veröffentlicht.
Microservices Entwurfsmuster
Unabhängig davon, in welcher Sprache Sie Microservices entwickeln, werden Sie mit Problemen konfrontiert, auf die andere Entwickler bereits gestoßen sind. Entwurfsmuster sind formalisierte, abstrakte Lösungen für wiederkehrende Probleme in der Informatik, und eine Reihe von ihnen sind speziell für Microservices gedacht. Devopedia hat eine großartige Liste, die Folgendes beinhaltet:
- Service Registry: zur Verbindung von Clients mit verfügbaren Instanzen von Microservices
- Circuit Breaker: um zu verhindern, dass fehlerhafte Dienste wiederholt aufgerufen werden.
- Fallback: für die Bereitstellung einer Alternative zu einem ausgefallenen Dienst
- Sidecar: zur Bereitstellung eines Hilfsdienstes für den Hauptcontainer, wie z.B. zum Protokollieren, Synchronisieren von Diensten oder Überwachen.
- Adapter: zur Standardisierung oder Normalisierung der Schnittstelle zwischen dem Hauptbehälter und der Außenwelt.
- Ambassador: Verbindung des Hauptcontainers mit der Außenwelt, z.B. zum Proxying von Localhost-Verbindungen zu Außenverbindungen.
Microservices und die Cloud: AWS und Azur
Wie bereits erwähnt, ist einer der Vorteile der Verwendung von Containern, dass sie einfach in der Cloud bereitgestellt werden können, wo flexible Rechenressourcen zur Verfügung stehen, damit Sie die Effizienz Ihrer Anwendung maximieren können. Wie Sie sich vorstellen können, sind die großen Anbieter von Public Clouds alle sehr daran interessiert, dass Sie ihre Plattformen für den Betrieb Ihrer Microservice-basierten Anwendungen nutzen. Weitere Informationen finden Sie in den Ressourcen von Amazon, Microsoft und Google.
*Josh Fruhlinger ist ein Schriftsteller und Redakteur, der in Los Angeles lebt.
Be the first to comment