Einführung in die Microservices-Architektur
Indem Sie sich auf diesen Artikel beziehen, können Sie sich ein besseres Bild von der Microservice-Architektur machen und wissen, wann Sie sie verwenden sollten. Darüber hinaus besteht dieser Artikel aus den folgenden Inhalten.
◼ Abkürzungen des Artikels
◼ Einführung
◼ Microservices-Ökosystem
◼ Monolith-Architektur vs. Microservice-Architektur
◼ Herausforderungen bei Microservices
◼ Wann Microservices verwendet werden sollten
Abkürzungen
- API: Anwendungsprogrammierschnittstelle
- MS: Mikrodienst
- NoSQL: Nicht nur SQL
- RTE: Laufzeitumgebung
Die Microservices-Architektur ist ein Ansatz für die Anwendungsentwicklung, bei dem eine große Anwendung als eine Suite modularer Dienste erstellt wird (Dies bedeutet, dass es sich (Microservice) um eine Art Anwendungsarchitektur handelt, bei der die Anwendung als Sammlung von Diensten entwickelt wird). Jedes Modul unterstützt ein bestimmtes Geschäftsziel und verwendet eine einfache, gut definierte Schnittstelle, um mit anderen Dienstgruppen zu kommunizieren. Darüber hinaus gibt es ein absolutes Minimum an zentralisierten Verwaltungsdiensten, die in verschiedenen Programmiersprachen wie Java, Python usw. geschrieben sein können und unterschiedliche Datenspeichertechnologien wie relational und NoSQL in der Microservices-Architektur verwenden.
Es gibt einige wichtige Merkmale/Merkmale von Microservices wie folgt.
- Sehr wartbar und testbar
- Lose gekoppelt (kommunizieren über eine Schnittstelle)
- Unabhängig einsetzbar
- Um geschäftliche Fähigkeiten herum organisiert
- Im Besitz eines kleinen Teams (funktionsübergreifendes Team)
Im Allgemeinen enthält das Microservices-System die nachfolgend aufgelisteten Entitäten. Einige dieser Entitäten sind Phasen in der Standardsoftwareentwicklung und einige von ihnen sind Microservices-spezifische Prozesse, die das Rückgrat für ein effizientes Microservices-System bilden.
Lastenausgleicher
Die Hauptaufgabe des Load Balancers besteht darin, die eingehende Last auf viele Instanzen von Microservices zu verteilen. Hauptsächlich gibt es zwei Arten von Load Balancern, die Client Discovery (clientseitiger Load Balancer) und Server Discovery (serverseitiger Load Balancer) genannt werden. Bei der Clienterkennung kommuniziert der Client mit der Dienstregistrierung und führt einen Lastausgleich durch. Aus diesem Grund muss der Client die Dienstregistrierung kennen. Bei der Servererkennung kommuniziert der Client mit dem Load Balancer und der Load Balancer mit der Dienstregistrierung. Daher braucht der Client-Dienst die Dienstregistrierung nicht zu kennen. Wenn Sie sich die folgenden Diagramme ansehen, können Sie diese beiden Arten von Load Balancern besser verstehen.
Service-Discovery-Server
Die Diensterkennungsfunktion ermöglicht es Mikrodiensten, sich beim Start selbst zu registrieren, anstatt manuell nachzuverfolgen, auf welchen Mikrodiensten derzeit bereitgestellt wird und welche Hosts und Ports wir benötigen. Wenn also MS1 mit MS2 sprechen möchte, erhält MS1 zuerst die Details von dem Registrierungsdienst, der zur Landschaft gehört, und spricht dann mit MS2. Darüber hinaus wird der Registrierungsdienst automatisch aktualisiert, wenn es eine andere MS namens MS3 gibt, die in derselben Landschaft hoch- oder heruntergefahren ist.
API-Gateway
Das API-Gateway ist ein Server. Es ist ein einzelner Einstiegspunkt in ein System. API Gateway kapselt die interne Systemarchitektur. Es bietet eine API, die auf jeden Client zugeschnitten ist. Es hat auch andere Verantwortlichkeiten wie Authentifizierung, Überwachung, Lastausgleich, Caching, Anforderungsformung und -verwaltung sowie statische Antwortbehandlung. API Gateway ist auch für das Anforderungsrouting, die Zusammensetzung und die Protokollübersetzung verantwortlich. Alle Anfragen des Clients durchlaufen das API-Gateway. Danach leitet das API-Gateway Anforderungen an den entsprechenden Microservice weiter.
Das API-Gateway verarbeitet die Anforderung auf eine von zwei Arten:
- Es leitete oder leitete die Anforderungen an den entsprechenden Dienst weiter.
- Auffächern (Verteilen) einer Anfrage auf mehrere Dienste.
Jetzt wissen wir, dass viele Microservices auf verschiedenen Knoten im selben Ökosystem ausgeführt werden. Daher müssen wir sie zusammen in einem einzigen System überwachen. Das Hystrix-Dashboard und das Spring Boot-Admin-Dashboard sind einige Beispiele für Überwachungstools. Es gibt fünf Prinzipien für die Überwachung von Microservices:
- Überwachen Sie Behälter und deren Inhalt.
- Alert zur Serviceleistung.
- Überwachen Sie elastische und standortübergreifende Dienste.
- APIs überwachen.
- Überwachen Sie die Organisationsstruktur
Wenn wir Microservices implementieren, laufen sie auf verschiedenen RTEs wie JRE und Node.js, da die Implementierung der Microservices mit unterschiedlichen Technologien erfolgen kann. Außerdem wissen Sie, dass diese Microservices mehrsprachig bereitgestellt werden. Daher kennen Knoten die RTE des bereitgestellten Microservice nicht und wir müssen sie manuell in jedem Knoten installieren. Aber wenn es um Containerisierung geht, verpacken wir unsere RTE mit unserem Microservice. Daher können wir die Microservices überall ausführen, ohne die RTE zu berücksichtigen, und wir können diese Dienste einfach verwalten und aktualisieren.
Leistungsschalter
Es ist eine sehr wichtige Einheit im Ökosystem der Microservices. Meistens wird dies als Muster definiert. Zum Verständnis ist dies dem Leistungsschalter Ihres Hauses ziemlich ähnlich. Es schützt Sie vor Katastrophen und stoppt die Ausbreitung des aufgetretenen Problems. Dasselbe Szenario passiert hier (Circuit Breaker in MS) in Bezug auf die Microservices. Nehmen wir an, der Client sendet eine Anfrage an den Lieferanten-Microservice und während die Antwort kommt, gibt es ein Verbindungsproblem. Aus diesem Grund wartet der Client lange auf eine Antwort, was sich möglicherweise auch auf andere Dienste auswirkt. Seit der Schaltungsunterbrecherarchitektur wird der problematische Kanal verworfen und das vorherige Warteproblem gelöst. Darüber hinaus gibt es drei verschiedene Zustände des Leistungsschalters, die als geschlossen bezeichnet werden, offen und halb offen.
Monolith-Architektur vs. Microservice-Architektur
Preis
- Monolithisch: Höher, sobald das Projekt skaliert
- Microservice : Höher in der ersten Ausbaustufe
- Monolithisch: Eine einheitliche Codebasis und Datenbank für das gesamte Produkt
- Microservice: Mehrere Codedateien; Jeder Dienst verwaltet eine Basis und einen Datenspeicher
- Monolithisch: Die gesamte Codebasis muss bereitgestellt werden
- Microservice: Jeder Microservice wird einzeln bereitgestellt
- Monolithisch: Derselbe Code-Stack
- Microservice: Verschiedene Stacks (Sprache, Laufzeitumgebung usw.)
Es gibt einige Herausforderungen, wenn wir mit Microservices umgehen, wie folgt.
- Kommunikation zwischen Prozessen (über Netzwerk)
- Verteilte Transaktionen
- Eine große Anzahl von Dienstleistungen
- Benötigen Sie mehr Automatisierung
Jetzt haben wir ein gutes Verständnis für Microservices und ihre Herausforderungen. Mal sehen, welche Szenarien für Microservices geeignet sind.
- Das Unternehmen möchte sofort sauberen, lesbaren Code erstellen und technische Schulden vermeiden
- Das Unternehmen verfügt über Personal für die Entwicklung von Microservices
- Das Unternehmen priorisiert langfristige Gewinne gegenüber kurzfristigen Vorteilen
- Ein Team von Entwicklern verwendet verschiedene Tech-Stacks und Tools
- Die Plattform muss hochgradig skalierbar sein und auf verschiedene Märkte expandieren