API VS. MICROSERVICES: EIN MICROSERVICE IST MEHR ALS NUR EINE API

0
23

Berücksichtigen Sie beim Schreiben von Software sowohl die Implementierung als auch die Architektur des Codes. Die Software, die Sie schreiben, ist am effektivsten, wenn sie logisch sinnvoll geschrieben ist. Software sollte nicht nur architektonisch einwandfrei sein, sondern auch die Interaktion mit dem Benutzer und die Benutzeroberfläche berücksichtigen.

Sowohl das Konzept einer API als auch das Konzept eines Mikrodienstes umfassen die Struktur und Interaktion von Software. Ein Microservice kann als einfacher Endpunkt zur Bereitstellung einer API missverstanden werden. Aber Microservice haben viel mehr Flexibilität und Fähigkeiten als das. In diesem Artikel werden die Unterschiede zwischen APIs und Microservices sowie einige der Vorteile eines Microservices beschrieben.

Lassen Sie uns zunächst unsere Begriffe definieren.

Was ist eine API?

Definieren wir zunächst, was eine API ist. Eine API (Application Programming Interface) ist laut Wikipedia:Eine Reihe von Unterprogrammdefinitionen, Kommunikationsprotokollen und Tools zum Erstellen von Software. Im Allgemeinen handelt es sich um eine Reihe klar definierter  

Kommunikationsmethoden  zwischen verschiedenen Komponenten.

Eine einfache Möglichkeit, sich eine API vorzustellen, besteht darin, sie als einen Vertrag von Aktionen zu betrachten, die Sie für einen bestimmten Service anfordern können. APIs werden heute in einer Vielzahl von Webanwendungen wie Social Media, Bankensoftware und vielem mehr verwendet. Der standardisierte Vertrag ermöglicht, dass externe Anwendungen mit anderen zusammenarbeiten.

Angenommen, Sie erstellen eine Anwendung, die in Facebook integriert werden soll. Mithilfe der Facebook Graph-API können Sie auf Daten in Facebook zugreifen, z. B. Benutzer, Beiträge, Kommentare und mehr. Die API vereinfacht den Versuch, die Daten in Facebook zu verwenden, und bietet dem Entwickler eine benutzerfreundliche Möglichkeit, auf diese Daten zuzugreifen.

Allgemeine API-Aktionen

In der heutigen Welt werden APIs normalerweise im REST-Stil entwickelt. Diese APIs verfügen über eine Reihe von Verben, die mit HTTP-Aktionen verknüpft sind, z. B. die folgenden:

  • GET (einen einzelnen Gegenstand oder eine Sammlung abrufen)
  • POST (Hinzufügen eines Elements zu einer Sammlung)
  • PUT (Bearbeiten eines Elements, das bereits in einer Sammlung vorhanden ist)
  • LÖSCHEN (Element in einer Sammlung löschen)

Der Vorteil dieser Konsistenz durch verschiedene Anwendungen besteht darin, dass bei der Ausführung verschiedener Aktionen ein Standard vorhanden ist. Die oben genannten vier verschiedenen HTTP-Verben korrelieren mit den allgemeinen CRUD-Funktionen, die viele Anwendungen heutzutage verwenden. Wenn Sie mit verschiedenen APIs in einer Anwendung arbeiten, können Sie auf diese Weise die Auswirkungen der über verschiedene Schnittstellen hinweg durchgeführten Aktionen nachvollziehen.

Wenn Sie an einem interaktiven Beispiel interessiert sind, schauen Sie sich Reqres an . Reqres stellt Scheindaten für die Schnittstelle zu einer RESTful-API und die Aktionen bereit, die Sie bei der Interaktion mit einer API ausführen können.

Okay, jetzt, da wir das behandelt haben, werfen wir einen Blick auf Microservices.

Was ist ein Microservice?

Wikipedia definiert einen Microservice als:Eine  

Softwareentwicklungstechnik  – eine Variante des  

Architekturstils der serviceorientierten Architektur  (SOA), die eine 

Anwendung  als Sammlung  

lose gekoppelter  Dienste strukturiert  . In einer Microservices-Architektur sind die Dienste  

feinkörnig  und die  

Protokolle  leichtgewichtig.

Bevor wir uns jedoch eingehender mit den Mikrodienstleistungen befassen und erklären, wie sie nützlich sein können, werfen wir einen kurzen Blick auf den Monolithen. Wenn Sie wissen, wie sich Microservices von Monolithen unterscheiden, können Sie die Vorteile einer Microservices-Architektur besser verstehen.

Der Vorläufer von Microservices: Monolithen

In den frühen Tagen der Softwareentwicklung (und heute in vielen großen Unternehmensumgebungen) gibt es das Konzept eines Monolithen. Ein Monolith ist eine einzelne Anwendung, die eine vollständige Sammlung von Funktionen enthält und als ein Ort dient, an dem alles gespeichert wird. Architektonisch sieht es so aus:

Alle Komponenten der Anwendung befinden sich in einem Bereich, einschließlich der UI-Schicht, der Geschäftslogikschicht und der Datenzugriffsschicht. Das Erstellen von Anwendungen in einem Monolithen ist ein einfacher und natürlicher Prozess, und die meisten Projekte beginnen auf diese Weise. Das Hinzufügen von Funktionalität zur Codebasis führt jedoch zu einer Zunahme sowohl der Größe als auch der Komplexität des Monolithen, und das Ermöglichen, dass ein Monolith groß wird, bringt mit der Zeit Nachteile mit sich. Einige davon sind:

  • Es besteht die Gefahr, dass Sie in die große Schlammkugel fallen , keinen Reim oder Grund in ihrer Architektur haben und von einem hohen Niveau aus schwer zu verstehen sind.
  • Einschränkung des Technologie-Stacks innerhalb des Monolithen. Insbesondere wenn die Anwendung wächst, wird es immer schwieriger, auf einen anderen Technologie-Stack zu wechseln, auch wenn sich herausstellt, dass die Technologie nicht mehr die beste Wahl ist.
  • Änderungen an der Codebasis wirken sich auf die gesamte Anwendung aus, egal wie klein sie ist. Wenn beispielsweise nur einer der Geschäftslogikabschnitte ständige Änderungen erfährt, wird die gesamte Anwendung neu bereitgestellt, wodurch Zeit verschwendet und das Risiko erhöht wird.

Was ist die Alternative zum Bau eines Monolithen? Nehmen Sie den Monolithen und zerlegen Sie ihn in Microservices.

Rufen Sie den Microservice auf

Nehmen wir das Beispiel eines Monolithen von oben und wandeln es in Microservices um. In diesem Fall würde sich die Anwendungsarchitektur folgendermaßen ändern:

Es gibt einige wichtige Erkenntnisse aus dieser Umstrukturierung:

  • Die aufgeschlüsselten Abschnitte der Geschäftslogik umfassen jeweils einen Mikroservice. Anstatt eine einzige Grenze für die gesamte Anwendung zu haben, wird die Anwendung in Teile aufgeteilt. Die Komplexität der Anwendung wird reduziert, da die verschiedenen Dienste gut definierte Wechselwirkungen miteinander haben. Auf diese Weise können beispielsweise jedem einzelnen Service Ausrichtungsteams zugewiesen werden, die die Verantwortung in einem abstrahierten Teil umfassen.
  • Die UI-Schicht von zuvor muss lediglich eine Schnittstelle zu den Kunden- und Ereignis-Microservices herstellen, wodurch eine Abhängigkeit für den Abrechnungs-Microservice von der UI beseitigt wird.
  • Der Abrechnungs-Microservice muss keine Daten speichern und verfügt daher weder über eine Datenzugriffsebene noch über eine Datenbank. Stattdessen interagiert und verarbeitet es Daten direkt von den Mikrodiensten des Kunden und der Veranstaltung.

Diese Art von Architektur bietet eine Reihe von Vorteilen:

  • Es ist einfacher, Bedenken zu trennen. Diese Grenzen zwischen den Bereichen helfen bei der Entwicklung (Sie müssen sich nur um Ihren Microservice kümmern, nicht um die gesamte Anwendung) und beim Verständnis der Architektur der Anwendung.
  • Anders als bei einem Monolithen kann ein Microservice bei Bedarf einen anderen Tech-Stack verwenden. Überlegen Sie, alles in einer neuen Sprache zu schreiben? Ändern Sie einfach einen Microservice, um den neuen Tech Stack zu verwenden, bewerten Sie die erzielten Vorteile und entscheiden Sie, ob Sie fortfahren möchten.
  • Die Bereitstellung der gesamten Anwendung wird fokussierter. Mit Microservices können Sie verschiedene Dienste nach Bedarf bereitstellen.

Beachten Sie im obigen Beispiel, dass sich die API neben den anderen Teilen des Microservices befindet. Wir werden darauf eingehen. Es ist endlich Zeit, über die Unterschiede zwischen APIs und Microservices zu sprechen.

Der Unterschied zwischen APIs und Microservices

Hier sind die Hauptunterschiede zwischen APIs und Microservices:

  • Eine API ist ein Vertrag, der dem Verbraucher eine Anleitung zur Nutzung des zugrunde liegenden Dienstes bietet.
  • Ein Mikrodienst ist ein Architekturentwurf, der Teile einer (normalerweise monolithischen) Anwendung in kleine, eigenständige Dienste aufteilt.

Per Definition bedeutet dies, dass eine API normalerweise Teil eines Mikrodienstes ist und eine Interaktion mit dem Mikrodienst selbst ermöglicht. Eine andere Möglichkeit, dies zu bedenken, besteht darin, dass die API als Vertrag für Interaktionen innerhalb des Mikrodienstes dient und die verfügbaren Optionen für die Interaktion mit dem Mikrodienst darstellt.

Wenn wir uns das Diagramm oben ansehen, können wir jedoch feststellen, dass jeder Mikrodienst je nach Bedarf etwas anders aufgebaut ist. Hier einige Beispiele für verschiedene Funktionen, die ein Microservice haben kann:

  • Bereitstellung von CRUD-Operationen für einen bestimmten Entitätstyp, z. B. einen Kunden, ein Ereignis usw. Dieser Dienst kann Daten in einer Datenbank beibehalten.
  • Bereitstellung eines Mittels zum Akzeptieren von Parametern und zum Zurückgeben von Ergebnissen basierend auf (potenziell intensiven) Berechnungen. Der oben genannte Abrechnungs-Microservice kann Informationen zu einem Ereignis oder Kunden erfassen und die erforderlichen Abrechnungsinformationen zurückgeben, ohne dass Daten gespeichert werden müssen.

Anhand des obigen Beispiels können Sie wahrscheinlich erkennen, dass ein Mikrodienst mehr als nur eine API für ein System sein kann. Eine gesamte Anwendung kann eine Reihe von Mikrodiensten umfassen, die ihre eigenen APIs für die Kommunikation miteinander verwenden. Darüber hinaus kann jeder dieser Mikrodienste seine eigene Funktionalität abstrahieren, wobei logische Grenzen für die Verantwortung in der Anwendung gezogen und Bedenken getrennt werden, um eine wartbarere Codebasis zu erzielen.

Fazit

Hoffentlich haben Sie jetzt ein besseres Verständnis für APIs und Microservices. Codewartbarkeit und -qualität sind wichtige Bestandteile einer erfolgreichen IT-Strategie. Mit Microservices bleiben Sie ihnen treu. Sie halten Ihre Teams agil und helfen Ihnen, die Kundenanforderungen zu erfüllen, indem sie hochwertigen, wartbaren Code erstellen.

Arbeiten Sie in einer Monolith-Codebasis? Denken Sie daran, einen Teil dieses Monolithen zu entnehmen und ihn in einen eigenen Mikrodienst zu verwandeln. Sobald Sie dies tun, sollten Sie in der Lage sein, die Vorteile der Verwendung von Microservices zu erkennen. In der Tat könnten Sie sogar entscheiden, das ganze Ding zu konvertieren.

HINTERLASSEN SIE EINE ANTWORT

Please enter your comment!
Please enter your name here