Was sind Microservices?

Die Microservice-Architektur, oder einfach nur Microservices, ist eine eigene Entwicklungsmethode für Softwaresysteme, die sich auf die Entwicklung von Modulen mit nur einer Funktion mit gut definierten Schnittstellen und Operation zu konzentrieren versucht. Der Trend ist in den letzten Jahren beliebter geworden, da Unternehmen agiler werden möchten und sich hin zu DevOps und kontinuierlichem Testen bewegen. 

Das Entwerfen von Microservices

Swagger und SwaggerHub: Wie Sie die ideale Microservices-Erfahrung entwerfen.

Testen von Microservices

Erfahren Sie, wie Sie Ihre Microservices-Auslieferung mit automatisierten Tests beschleunigen.

Überwachung von Microservices

Lesen Sie, warum die Überwachung Ihrer Microservices wichtiger ist, als Sie denken.

Microservices bieten viele Vorteile für Agile- und DevOps-Teams. Wie Martin Fowler betont, haben Netflix, eBay, Amazon, Twitter, PayPal und andere große Technologiefirmen sich alle von einer monolithischen zu einer Microservices-Architektur entwickelt. Anders als Microservices wird eine monolithische Anwendung als eine einzige, autonome Einheit entwickelt. Das macht Veränderungen an der Anwendung langsam, da diese das gesamte System betreffen.  Eine an einem kleinen Codeabschnitt vorgenommene Änderung kann die Entwicklung und den Einsatz einer vollständig neuen Softwareversion erforderlich machen.  Bestimmte Funktionen einer Anwendung zu skalieren bedeutet auch, dass Sie die gesamte Anwendung skalieren müssen.

Microservices lösen diese Herausforderungen von monolithischen Systemen, indem sie so modular wie möglich sind. In der einfachsten Form helfen sie dabei, eine Anwendung als eine Sammlung kleiner Dienstprogramme zu entwickeln, die alle in einem eigenen Prozess ausgeführt werden und individuell einsetzbar sind. Diese Dienstprogramme können in verschiedenen Programmiersprachen geschrieben sein und verschiedene Datenspeichertechniken anwenden. Während dies zur Entwicklung von Systemen führt, die skalierbar und flexibel sind, macht es eine dynamische Überarbeitung erforderlich. Microservices werden häufig per APIs verbunden und können viele der gleichen Tools und Lösungen nutzen, die im RESTful- und Webservice-Ökosystem gewachsen sind. Durch das Testen dieser APIs können Sie den Daten- und Informationsfluss während der Bereitstellung Ihrer Microservices überprüfen.

Vorteile von Microservices

Einfacher einzusetzen
Einsatz in Stücken, ohne dass dies Auswirkungen auf andere Dienste hat.
Einfacher zu verstehen
Code ist einfacher zu verstehen, da die Funktion isoliert ist und weniger Abhängigkeiten besitzt.
Wiederverwendbarkeit im ganzen Unternehmen
Kleine Dienste, wie Zahlungs- oder Login-Systeme, können im Unternehmen geteilt werden.
Schnellere Fehlerisolierung
Wenn ein Test fehlschlägt oder ein Dienst ausfällt, kann er mit Microservices schnell isoliert werden.
Minimierte Änderungsrisiken
Eine Fixierung auf Technologien oder Sprachen wird vermieden, spontane Änderungen sind ohne Risiko.

Die Microservice-Architektur

Genauso wie es keine formelle Definition des Begriffs Microservices gibt, existiert auch kein Standardmodell, dass sie in jedem auf diesem Architekturstil basierenden System wiederfinden werden.  Aber Sie können erwarten, dass die meisten Microservice-Systeme ein paar wichtige Merkmale miteinander teilen. 

Erfahren Sie, wie SwaggerHub Teams dabei hilft, mit Microservices loszulegen.

Die sechs Merkmale von Microservices

1) Mehrere Komponenten

Als Microservices entwickelte Software kann, per Definition, in mehrere Komponentendienste aufgeteilt werden.  Warum?  Damit jeder dieser Dienste unabhängig ausgeliefert, optimiert und dann erneut ausgeliefert werden kann, ohne die Integrität einer Anwendung zu kompromittieren.  Als Ergebnis hieraus müssen Sie gegebenenfalls nur einen oder mehrere bestimmte Dienstprogramme ändern, anstatt gesamte Anwendungen neu auszuliefern.  Aber dieser Ansatz hat seine Nachteile, einschließlich vieler Remote-Aufrufe (anstelle von Aufrufen im selben Prozess), gröberer Remote-APIs und erhöhter Komplexität bei der Neuverteilung von Aufgaben zwischen Komponenten.

2) Für die Geschäftswelt entworfen

Der Microservices-Stil ist üblicherweise rund um geschäftliche Funktionen und Prioritäten organisiert.  Anders als ein traditioneller, monolithischer Entwicklungsansatz, bei dem verschiedene Teams sich jeweils auf ein Gebiet konzentrieren, z. B. GUI, Datenbanken, Technologieebenen oder serverseitige Logik, nutzt die Microservice-Architektur funktionsübergreifende Teams.  Die Verantwortungen jedes Teams sind es, bestimmte Produkte basierend auf einem oder mehreren individuellen Diensten zu erstellen, die über den Messaging-Bus kommunizieren.  Bei Microservices ist ein Team für die Lebenszeit seines Produktes dafür verantwortlich, wie im oft zitierten Leitspruch von Amazon: “Du entwickelst es, du betreibst es.

3) Einfaches Routing

Microservices agieren in etwa so wie das klassische UNIX-System: sie empfangen Anfragen, verarbeiten sie und generieren eine entsprechende Antwort.  Dies ist das Gegenteil davon, wie viele andere Produkte wie etwa ESBs (Enterprise Service Buses) arbeiten, bei denen High-Tech-Systeme für das Message-Routing, die Choreographie und die Anwendung von Geschäftsregeln eingesetzt werden.  Man könnte sagen, dass Microservices über intelligente Endpunkte verfügen, die Informationen verarbeiten und Logik darauf anwenden, sowie über dumme Leitungen, durch welche die Informationen fließen.

4) Dezentralisiert

Da Microservices eine Vielzahl von Technologien und Plattformen miteinschließen, sind traditionelle Methoden der zentralen Überwachung nicht ideal.  Die Microservices-Community bevorzugt eine dezentrale Überwachung, da ihre Entwickler danach streben, nützliche Tools zu produzieren, die dann von anderen für die Lösung derselben Probleme eingesetzt werden können.  Genau wie eine dezentrale Überwachung bevorzugt die Microservice-Architektur auch eine dezentrale Datenverwaltung.  Monolithische Systeme verwenden eine einzige logische Datenbank in mehreren Anwendungen.  In einer Microservice-Anwendung verwaltet üblicherweise jedes Dienstprogramm seine eigene Datenbank.

5) Fehlerbeständig

Wie ein wohlerzogenes Kind sollen auch Microservices mit Fehlern klarkommen können.  Da mehrere einzigartige und unterschiedliche Dienste miteinander kommunizieren, ist es durchaus möglich, dass aus dem einen oder anderen Grund ein Dienst ausfällt (z. B. wenn der Lieferant nicht verfügbar ist).  In diesen Fällen sollte der Client es seinen benachbarten Diensten ermöglichen, weiterhin zu funktionieren, während er sich so elegant wie möglich zurückzieht. Allerdings kann die Überwachung von Microservices das Risiko von Fehlern verringern. Aus naheliegenden Gründen fügt diese Anforderung im Vergleich zu monolithischen Systemarchitekturen mehr Komplexität zu Microservices hinzu.

6) Evolutionär

Die Microservices-Architektur ist ein evolutionäres Design und, noch einmal, eignet sich ideal für evolutionäre Systeme, bei denen Sie die Art der Geräte nicht vollständig voraussehen können, die eines Tages vielleicht auf Ihre Anwendung zugreift.  Viele Anwendungen beginnen auf Basis einer monolithischen Architektur, können aber, während verschiedene unvorhergesehene Anforderungen auftauchen, langsam in Microservices verwandelt werden, die über eine ältere monolithische Architektur hinweg per APIs kommunizieren.

Die besten Microservices werden mit Swagger-Tools entwickelt

Design ist die Grundlage Ihrer Microservice-Entwicklung. Swagger macht das Design von APIs und Microservices kinderleicht, mit anwenderfreundlichen Tools für Entwickler, Architekten und Product Owner.

Beispiele für Microservices

Netflix verfügt über eine weitverbreitete Architektur, die sich von monolithisch zu SOA entwickelt hat.  Es empfängt mehr als eine Milliarde Aufrufe pro Tag von mehr als 800 verschiedenen Gerätearten an seine Videostream-API.  Jeder API-Aufruf löst dann etwa fünf zusätzliche Aufrufe an den Backend-Dienst aus.

Amazon hat ebenfalls zu Microservices gewechselt.  Es erhält zahllose Aufrufe von einer Vielzahl von Anwendungen, einschließlich Anwendungen, die sowohl die Web-Service-API als auch die Webseite selbst verwalten, was für seine alte, Two-Tier-Architektur einfach unmöglich zu handhaben gewesen wäre.

Die Auktions-Webseite eBay ist ein weiteres Beispiel, das denselben Übergang durchlebt hat.  Ihre Kernanwendung besteht aus mehreren autonomen Anwendungen, wobei jede davon die Geschäftslogik für verschiedene Funktionsbereiche ausführt.

Vor- und Nachteile von Microservices

Microservices sind keine Wunderwaffe, und indem Sie sie implementieren, stellen Sie die Kommunikation, die Teamarbeit und andere Probleme bloß, die vielleicht vorher unausgesprochen blieben, jetzt aber offenliegen. Aber API-Gateways in Microservices können die Zeit und den Aufwand für Entwicklung und Qualitätssicherung deutlich verringern.

Ein häufiges Problem hat damit zu tun, Schema-/Validierungslogik zwischen Diensten zu teilen.  Was A benötigt, um Daten als valide anzusehen, trifft nicht immer auch auf B zu, falls B andere Anforderungen hat.  Die beste Empfehlung ist, Versionierung anzuwenden und Schema in geteilten Bibliotheken zu verteilen.  Änderungen an Bibliotheken können dann zu Diskussionen zwischen Teams führen.  Und mit starker Versionierung kommen Abhängigkeiten, die zu mehr Overhead führen können.  Ein bewährtes Verfahren, um dies zu bewältigen, ist eine Planung rund um Rückwärtskompatibilität und die Akzeptanz von Regressionstests von externen Diensten/Teams.  Das führt dazu, dass Sie Besprechungen führen, bevor Sie den Geschäftsprozess eines anderen stören, und nicht erst hinterher.

Wie auch bei allem anderen gilt: Ob Microservices für Sie geeignet sind oder nicht, hängt von Ihren Anforderungen ab, denn alles hat seine Vor- und Nachteile.  Hier ist eine kurze Zusammenfassung der Licht- und Schattenseiten:

Vorteile

  • Die Microservice-Architektur gibt Entwicklern die Freiheit, Dienste unabhängig zu entwickeln und auszuliefern.
  • Ein Microservice kann von einem recht kleinen Team entwickelt werden.
  • Code für verschiedene Dienste kann in verschiedenen Sprachen geschrieben werden (obwohl viele Praktiker hiervon abraten).
  • Einfache Integration und automatische Auslieferung (mithilfe von Open-Source-Tools für die kontinuierliche Integration wie Jenkins, Hudson usw.).
  • Leicht verständlich für Entwickler, kann daher neuen Teammitgliedern dabei helfen, schnell produktiv zu arbeiten.
  • Die Entwickler können die neuesten Technologien einsetzen.
  • Der Code ist rund um Geschäftsfunktionen organisiert.
  • Startet den Web-Container schneller, also ist auch die Auslieferung schneller.
  • Wenn Änderungen an einem bestimmten Teil der Anwendung erforderlich sind, kann allein der entsprechende Dienst verändert und neu ausgeliefert werden —es ist nicht notwendig, die gesamte Anwendung zu verändern und neu auszuliefern.
  • Bessere Fehlerisolierung: Wenn ein Microservice ausfällt, funktionieren die anderen weiterhin (obwohl ein Problembereich einer monolithischen Anwendung das gesamte System gefährden kann).
  • Einfach zu skalieren und in Drittanbieterdienste zu integrieren.
  • Keine langfristige Bindung an eine Technologie.

Nachteile

  • Aufgrund der verteilten Auslieferung kann das Testen kompliziert und langwierig werden.
  • Eine steigende Anzahl an Diensten kann zu Informationsbarrieren führen.
  • Die Architektur bringt zusätzliche Komplexität mit sich, da die Entwickler die Fehlertoleranz sowie die Netzwerklatenz mindern und mit einer Vielzahl an Messaging-Formaten sowie Load-Balancing umgehen müssen.
  • Bei einem verteilten System kann es zu Doppelarbeiten kommen.
  • Wenn die Anzahl der Dienste steigt, kann die Integration und Verwaltung ganzer Projekte kompliziert werden.
  • Zusätzlich zu verschiedenen Komplexitäten einer monolithischen Architektur müssen die Entwickler mit der zusätzlichen Komplexität eines verteilten Systems umgehen.
  • Entwickler müssen zusätzliche Mühe in die Umsetzung eines Kommunikationsmechanismus zwischen den Dienstprogrammen investieren.
  • Der Umgang mit Anwendungsfällen, die mehr als einen Dienst umfassen, ist ohne verteilte Transaktionen nicht nur schwer, sondern verlangt auch nach Kommunikation und Kooperation zwischen verschiedenen Teams.

Wie die Microservice-Architektur funktioniert

1) Monolithen und das Gesetz von Conway

Zu Beginn sehen wir uns das Gesetz von Conway an, das aussagt: “Organisationen, die Systeme entwerfen,…sind auf Entwürfe festgelegt, die die Kommunikationsstrukturen dieser Organisationen abbilden.”

Stellen wir uns das Unternehmen X mit zwei Teams vor: Support und Buchhaltung.  Instinktiv sortieren wir die Hochrisikoaktivitäten aus: Es ist einfach nur schwierig, Verantwortungen wie Kundenrückerstattungen zu entscheiden.  Bedenken Sie, wie wir Fragen beantworten könnten wie: “Verfügt das Buchhaltungs-Team über genug Personal, um sowohl Kundenrückerstattungen als auch Guthaben zu bearbeiten?” Oder: “Wäre es nicht ein besseres Ergebnis, wenn unsere Support-Leute Guthaben vergeben und sich um frustrierte Kunden kümmern könnten?”  Die Antworten werden durch eine neue Richtlinie des Unternehmens X gelöst: Der Support kann ein Guthaben vergeben, aber die Buchhaltung muss eine Rückerstattung bearbeiten, um Geld an den Kunden zurückzuzahlen.  Die Rollen und Verantwortlichkeiten in diesem verbundenen System wurden erfolgreich aufgeteilt, während die Kundenzufriedenheit erhöht und Risiken minimiert werden.

Gleichermaßen stellen Unternehmen beim Design-Beginn einer Softwareanwendung üblicherweise ein Team zusammen und erschaffen ein Projekt.  Mit der Zeit wächst das Team und mehrere Projekte auf derselben Codebasis werden abgeschlossen.  Meistens führt dies zu miteinander wetteifernden Projekten: Zwei Personen finden es schwierig, an verschiedenen Zwecken im selben Codebereich zu arbeiten, ohne Kompromisse einzugehen.  Und mehr Menschen zu der Gleichung hinzuzufügen, macht das Ganze nur noch schlimmer.  Wie Fred Brooks es ausdrückt: Neun Frauen können kein Baby in einem Monat erschaffen.

Außerdem verändern sich die Prioritäten bei Unternehmen X oder in jedem Entwicklerteam häufig, was zu Management- und Kommunikationsproblemen führt.  Das Element mit der höchsten Priorität im letzten Monat kann dazu geführt haben, dass unser Team sich hart angestrengt hat, Code auszuliefern, aber jetzt berichtet ein Anwender von einem Problem und wir haben keine Zeit mehr, es zu lösen, und zwar wegen der Priorität dieses Monats.  Dies ist der überzeugendste Grund für die Übernahme von SOA, einschließlich der Microservices-Vielfalt.  Dienstorientierte Ansätze erkennen die Reibungen zwischen Änderungsverwaltung, Domain-Kenntnissen und Geschäftsprioritäten, so dass Entwicklerteams diese ausdrücklich trennen und behandeln können.  Natürlich ist dies selbst ein Kompromiss – es erfordert Koordination – aber es ermöglicht es Ihnen, Reibung zu zentralisieren und Effizienz einzuführen, im Gegensatz zum Leiden an einer großen Anzahl kleiner Ineffizienzen.

Und am wichtigsten: Einen SOA oder eine Microservice-Architektur intelligent umzusetzen, zwingt Sie dazu, das Interface-Segregation-Prinzip anzuwenden.  Aufgrund der verbundenen Natur von gereiften Systemen ist es der übliche Ansatz bei der Isolation von Problemen, eine Nahtstelle oder einen Kommunikationspunkt zu finden und dann eine gestrichelte Linie zwischen zwei Hälften des Systems zu ziehen.  Ohne gründliches Nachdenken kann dies jedoch zu einer unbeabsichtigten Schaffung zweier kleinerer, aber wachsender Monolithen führen, die nun durch eine Art Brücke verbunden sind.  Die Konsequenz hiervon kann sein, dass sich um wichtigen Code auf der falschen Seite einer Barriere nicht mehr gekümmert wird: Team A kümmert sich nicht mehr darum, aber Team B braucht es, also wird es neu erschaffen.

2) Microservices: Monolithen vermeiden

Wir haben einige der Probleme benannt, die üblicherweise auftreten. Jetzt werfen wir einen Blick auf mögliche Lösungen.

Wie liefern Sie relativ unabhängige, aber dennoch integrierte Dienste aus, ohne zusätzliche Monolithen zu erschaffen?  Nun, nehmen Sie an, Sie haben eine große Anwendung, wie im Beispiel mit unserem Unternehmen X unten, und teilen die Codebasis und Teams in kleinere Stücke auf.  Anstatt einen gesamten Bereich der Anwendung zum Abtrennen zu finden, können Sie nach etwa am Rand des Anwendungsdiagramms Ausschau halten.  Welche Bereiche dies sind, sehen Sie daran, dass nichts von ihnen abhängig ist.  In unserem Beispiel legen die auf Printer und Storage zeigenden Pfeile nahe, dass dies zwei Dinge sind, die leicht aus unserer Hauptanwendung entfernt und wegabstrahiert werden können.  Ob man einen Job oder eine Rechnung druckt, ist irrelevant. Ein Drucker erwartet einfach nur druckbare Daten.  Diese beiden —Printer und Storage— in externe Dienstprogramme umzuwandeln, vermeidet das vorher erwähnte Monolithenproblem.  Es macht auch Sinn, zu sagen, dass sie mehrfach genutzt werden und es gibt nur wenig, was neu erfunden werden kann.  Anwendungsfälle sind gut aus der Vergangenheit bekannt, also können Sie es vermeiden, unabsichtlich wichtige Funktionen zu entfernen.

MicroServices-Architektur

3) Service-Objekte und Identifizierung von Daten

Also wie kommen wir von Monolithen zu Diensten?  Ein Weg führt über Service-Objekte.  Ohne Code aus unserer Anwendung zu entfernen, beginnen Sie einfach nur damit, ihn so zu strukturieren, als wäre er vollständig extern.  Hierzu müssen Sie zuerst die Aktionen unterscheiden, die ausgeführt werden können, ebenso wie die Daten, die als Ein- und Ausgaben dieser Aktionen vorhanden sind.  Sehen Sie sich den folgenden Code an, mit der Idee, dass etwas Nützliches getan wird und einem Status der Aufgabe.

# Eine Klasse, um eine Kerntransaktion zu modellieren und auszuführen

 class Job
 def initialize
 @status = 'Queued'
 end
        
 def do_useful_work
          ....
 @status = 'Finished'
 end
        
 def finished?
 return @status == 'Finished'
 end
        
 def ready?
 return @status == 'Queued'
 end
 end

Was muss als nächstes kommen, damit das anfängt, wie ein Microservice auszusehen?

# Dienst, der nützliche Arbeit leistet und einen Status ändert

 class JobService
 def do_useful_work(job_status)
        ....
        
 job_status.finish!
        
 return job_status
 end
 end

 # Ein Modell für den Status unseres Jobs

 class JobStatus
 def initialize
 @status = 'Queued'
 end
      
 def finished?
 return @status == 'Finished'
 end
      
 def ready?
 return @status == 'Queued'
 end
      
 def finish!
 @status = 'Finished'
 end
 end

Nun haben wir zwei bestimmte Klassen unterschieden: eine Klasse, die Daten modelliert, und eine, die Operationen ausführt.  Maßgeblich ist, dass unser JobService keinen oder nur wenig Zustand besitzt. Sie können dieselben Aktionen wieder und wieder durchführen, dabei nur die Daten verändern und konsistente Ergebnisse erwarten.  Falls der JobService auf irgendeine Art und Weise über ein Netzwerk ausgeführt wird, würde das unsere ansonsten monolithische Anwendung nicht interessieren.  Diese Arten von Klassen in eine Bibliothek umzuschichten und die vorherige Implementierung mit einem Netzwerk-Client zu ersetzen, würde es Ihnen ermöglichen, den vorhandenen Code in einen skalierbaren externen Dienst umzuwandeln.

Dies ist eine Hexagonal-Architektur, bei der der Kern Ihrer Anwendung und die Koordination im Zentrum stattfinden und die externen Komponenten rund herum angeordnet sind, um Ihre Ziele zu erreichen.

hexagonalarchitecture.png

(Mehr über Service-Objekte und die Hexagonal-Architektur erfahren Sie hier und hier.)

4) Koordination und dumme Pipes

Werfen wir jetzt einen genaueren Blick darauf, was etwas zu einem Microservice macht, im Unterschied zu einem traditionellen SOA.

Vielleicht der wichtigste Unterschied sind Nebenwirkungen.  Microservices vermeiden sie.  Um zu sehen, warum, sehen wir uns einen älteren Ansatz an: Unix-Pipes.

ls | wc -l

Dort oben werden zwei Programme aneinandergekettet: Das erste listet alle Dateien in einem Verzeichnis auf, das zweite liest die Anzahl der Zeilen in einem Eingabe-Stream.  Stellen Sie sich vor, ein vergleichbares Programm zu schreiben und es dann in Folgendes modifizieren zu müssen:

ls | less

Der Entwurf kleinerer Funktionsstücke ist abhängig von wiederholbaren Ergebnissen, einem Standardmechanismus für Ein- und Ausgabe sowie einem Exit-Code, mit dem ein Programm Erfolg oder Fehler anzeigt.  Wir wissen von unseren Beobachtungen her, dass dies funktioniert und wir wissen auch, dass eine Unix-Pipe eine “dumme” Schnittstelle ist, da sie über keinerlei Steuerungsbefehle verfügt.  Die Pipe wendet SRP an, indem Sie Daten von A nach B schiebt und es liegt an den Mitgliedern der Pipeline, zu entscheiden, ob die Eingaben akzeptabel sind.

Kommen wir zurück zu den Job- und Invoice-Systemen von Unternehmen X.  Jedes steuert eine Transaktion und kann gemeinsam oder einzeln verwendet werden: Rechnungen können für Jobs erstellt werden, Jobs können ohne Rechnung erstellt werden und Rechnungen können ohne einen Job erstellt werden.  Anders als bei Unix-Shell-Befehlen arbeiten die Anwender der Systeme, die Jobs und Invoices besitzen, unabhängig voneinander.  Aber ohne Rückgriff auf eine Richtlinie ist es unmöglich, Regeln für eines der Systeme global durchzusetzen.

Nehmen wir an, wir möchten die Schlüsseloperationen, die wiederholt ausgeführt werden können, extrahieren: —Die Dienste für das Senden einer Rechnung, das Ändern eines Job-Status und das Ändern eines Invoice-Status.  Diese sind vollständig getrennt von der Aufgabe des Fortbestehens von Daten.

illing.png

Dies ermöglicht es uns hier, die einzelnen Komponenten in zwei Pipelines zu verbinden:

Anwender erstellt eine manuelle Rechnung.

  • Fügt Daten zur Rechnung hinzu, Status created.

    — Ruft BillingPolicyService auf, um zu bestimmen, wann eine Rechnung für einen gegebenen Kunden fällig ist.

  • Rechnung an den Kunden wird ausgestellt.
  • Besteht fort zum Invoice-Datendienst, Status sent.

Anwender schließt Job ab, eine Rechnung wird erstellt.

  • Bestätigt, dass der Job abschließbar ist.
  • Fügt Daten zur Rechnung hinzu, Status created.

    —Ruft BillingPolicyService auf, um zu bestimmen, wann eine Rechnung für einen gegebenen Kunden fällig ist.

  • Rechnung an den Kunden wird ausgestellt.
  • Besteht fort zum Invoice-Datendienst, Status sent.

Die Schritte für die Berechnung der Rechnung sind idempotent und es ist dann trivial, eine Rechnungsvorlage zu entwerfen oder eine Vorschau der vom Kunden zu zahlenden Beträge zu zeigen, indem unsere neuen, dedizierten Microservices verwendet werden.

Anders als bei traditionellen SOA ist der Unterschied hier, dass wir Low-Level-Details über eine einfache Schnittstelle aufgedeckt haben, im Unterschied zu einem High-Level-API-Aufruf, der eine gesamte Geschäftsaktion ausführen kann.  Mit einer High-Level-API wird es tatsächlich schwierig, kleine Komponenten neu miteinander zu verbinden, da der Dienst-Designer viele der Nahtstellen oder Entscheidungen, die wir treffen können, durch die Erstellung einer One-Shot-Schnittstelle entfernt hat.

An diesem Punkt führt die Wiederholung der Geschäftslogik, der Richtlinien und Regeln dazu, dass viele diese Komplexität traditionell in einen Service-Bug oder ein einzelnes, zentrales Workflow-Orchestrierungs-Tool verschieben.  Allerdings ist der wesentliche Vorteil der Microservice-Architektur nicht, dass wir niemals Geschäftsregeln/-prozesse/-richtlinien teilen, sondern dass wir sie in einzelne Packages verschieben, angepasst an die Geschäftsbedürfnisse.  Das bedeutet nicht nur, dass die Richtlinie verteilt wird, sondern auch, dass Sie Ihre Geschäftsprozesse risikofrei verändern können.

SOA vs. Microservices

“Moment mal”, murmeln Sie vielleicht gerade über Ihrem Morgenkaffee: “„Ist das nicht einfach nur ein neuer Name für SOA?“”  Die serviceorientierte Architektur (SOA) entstand während der ersten paar Jahre dieses Jahrhunderts und die Microservice-Architektur (von einigen als MSA abgekürzt) ist ihr in mancherlei Hinsicht ähnlich.  Die traditionelle SOA ist allerdings ein breiteres Framework und kann eine Vielzahl von Bedeutungen haben.  Einige Microservices-Verfechter weisen die Bezeichnung als SOA generell zurück, während andere der Meinung sind, Microservices wären eine ideale, verfeinerte Form der SOA.  In jedem Fall denken wir, dass es genug Unterschiede gibt, um ein getrenntes Konzept der “Microservices” zu rechtfertigen (zumindest als Spezialfall der SOA, wie wir später zeigen werden).

Das übliche SOA-Modell besitzt beispielsweise meistens mehr abhängige ESBs, während Microservices schnellere Messaging-Mechanismen einsetzen.  SOA konzentriert sich auch auf die imperative Programmierung, während die Microservices-Architektur einen responsiven Programmierstil bevorzugt.  Des Weiteren tendieren SOA-Modelle dazu, über eine riesige relationale Datenbank zu verfügen, während Microservices häufig NoSQL- oder Micro-SQL-Datenbanken verwenden (die an konventionelle Datenbanken angebunden werden können).  Aber der wahre Unterschied hat mit den Architekturmethoden zu tun, die dafür verwendet werden, zu einer integrierten Menge von Diensten zu gelangen.

Da sich in der digitalen Welt alles verändert, sind agile Entwicklungstechniken, die mit den Erfordernissen der Software-Evolution Schritt halten können, unverzichtbar.  Die meisten der in der Microservices-Architektur eingesetzten Praktiken kommen von Entwicklern, die Softwareanwendungen für Großunternehmen entwickelt haben und die wissen, dass die Endanwender von heute dynamische, aber dennoch konsistente Erfahrungen über eine Vielzahl verschiedener Geräte hinweg erwarten.  Skalierbare, anpassbare, modulare und schnell zugängliche, cloudbasierte Anwendungen sind begehrt.  Und dies hat dazu geführt, dass viele Entwickler ihren Ansatz verändern.

Die Zukunft der Microservice-Architektur

Ob die Microservice-Architektur in Zukunft zum bevorzugten Stil von Entwicklern wird oder nicht, es ist ganz klar eine kraftvolle Idee, die wesentliche Vorteile für das Design und die Umsetzung von Enterprise-Anwendungen bietet.  Viele Entwickler und Organisationen haben, ohne jemals den Namen zu benutzen oder ihre Praktik überhaupt als SOA zu bezeichnen, einen Ansatz hin zur Nutzung von APIs verwendet, der als Microservices eingestuft werden könnte.

Wir haben auch eine Vielzahl existierender Technologien dabei beobachtet, wie sie Teile der Segmentierungs- und Kommunikationsprobleme zu lösen versuchen, die Microservices lösen will.  SOAP ist gut darin, mit den WSDLs die an einem bestimmten Endpunkt verfügbaren Operationen und deren Standort zu beschreiben.  UDDI ist theoretisch ein guter Schritt hin zur Bekanntmachung, was ein Dienst tun kann und wo er zu finden ist.  Aber diese Technologien wurden durch eine relativ komplexe Umsetzung kompromittiert und werden in neueren Projekten häufig nicht mehr eingesetzt.  REST-basierte Dienste sehen sich denselben Schwierigkeiten gegenüben und obwohl man WSDLs mit REST verwenden kann, ist dies nicht weit verbreitet.

Angenommen, das Auffinden von Diensten (Discovery) ist ein gelöstes Problem, bleibt das Mitteilen von Schema und Bedeutung über eigenständige Anwendungen hinweg weiterhin ein schwieriges Thema für alle anderen als Microservices und andere SOA-Systeme.  Technologien wie RDFS, OWL und RIF existieren und sind standardisiert, werden aber nicht häufig verwendet.  JSON-LD und Schema.org bieten einen Einblick darin, wie ein gesamtes offenes Web aussieht, das Definitionen teilt, aber diese sind in großen Privatunternehmen noch nicht akzeptiert worden.

Die Macht der geteilten, standardisierten Definitionen schreitet innerhalb von Regierungen allerdings voran.  Tim Berners Lee hat umfassend für „verlinkte Daten“ geworben.  Die Ergebnisse sind sichtbar in data.gov und data.gov.uk und Sie können die große Anzahl der verfügbaren Datensätze als gut beschriebene verlinkte Daten hier erkunden.  Falls eine große Anzahl an standardisierten Definitionen vereinbart werden kann, gehen die nächsten Schritte vermutlich in Richtung Agenten: Kleine Programme, die Microservices von einer großen Anzahl an Lieferanten arrangieren, um bestimmte Ziele zu erreichen.  Wenn man die zunehmende Komplexität und die Kommunikationsanforderungen von SaaS-Apps, Wearables und dem Internet der Dinge zu einem großen Ganzen zusammenfügt, wird deutlich, dass der Microservice-Architektur vermutlich eine strahlende Zukunft bevorsteht.

Autor: Tom Huston

Weitere Ressourcen

Tools:
Zusätzliches Lesematerial:

Warum sollten Sie bei API-Tests auf SmartBear setzen?

Einfache Testerstellung
SmartBear stellt Automatisierungstools und -frameworks für Entwickler und Tester bereit, um die Validierung und Überprüfung von Benutzeroberflächen, APIs und Datenbanken zu unterstützen. 
Kann in Ihren CI/CD automatisiert werden
Jedes unserer Tools zur Automatisierung von Tests wird mit einsatzbereiten Plugins mit gängigen CI-Servern wie Jenkins und einer CLI für andere ausgeliefert.
Kosteneinsparungen
Profitieren Sie von sofort einsetzbaren Renditen und Einsparungen mit benutzerfreundlichen Tools, die Sie vor dem Kauf testen und implementieren können.
Bessere Testabdeckung
Führen Sie Tests im Maßstab mit realen Daten auf einer virtualisierten Infrastruktur, realen Browsern oder mit generierter Last durch.
Breite Sprachunterstützung
Verbringen Sie keine Zeit mit dem Erlernen proprietärer Sprachen! Unsere Tools arbeiten mit Ihren bevorzugten Sprachen wie Python, JavaScript und mehr.
Schnelleres Debugging
Führen Sie automatisierte Tests in einer kontinuierlichen Pipeline durch, die Ihrem Team schnellere Rückmeldungen geben und die Debugging-Zeit und die Zeit zur Lösungsfindung reduzieren.