In den 60er und 70er Jahren monolithische Architektur wurde wegen der begrenzten Rechenressourcen, die die Kombination aller Funktionalitäten in einer einzigen, zusammenhängenden Einheit erforderten, für die Entwicklung von Anwendungen bevorzugt.
Das dauerte bis in die späten 90er und 2000er Jahre, als die monolithische Struktur für die ständig wachsende Größe und Komplexität von Anwendungen zu begrenzt wurde, insbesondere mit dem Aufkommen des Internets und verteilter Systeme.
Dies führte zur Entwicklung modularerer Ansätze, wie z Serviceorientierte Architekturen (SOA) und später, Microservices-Architektur (MSA), die schließlich Anfang der 2010er Jahre bekannt wurde.
Dies ist jedoch lediglich eine kurze Erläuterung des Grundkonzepts und der Verwendung von Microservices. Lassen Sie uns also besprechen, wie Microservices die monolithische Architektur ersetzt haben, wie Microservices funktionieren und einige Beispiele für Microservices. Anschließend besprechen wir die wichtigsten Aspekte der Bereitstellung von Microservices und was zu tun ist, wenn Sie Microservices bereitstellen möchten.
Was sind Microservices? Wie funktionieren sie?
Wie ich bereits erwähnt habe, haben sich Microservices als Lösung für die zunehmende Komplexität und Größe von Anwendungen herauskristallisiert und es Unternehmen ermöglicht, Funktionen in unabhängig einsetzbare Dienste aufzuteilen.
Der Begriff „Microservices“ wurde von Branchenexperten wie Martin Fowler und James Lewis populär gemacht, die ihn 2014 in einem Blogbeitrag offiziell einführten. Ihre Arbeit definierte Schlüsselprinzipien und Merkmale, einschließlich der Notwendigkeit unabhängig einsetzbarer Dienste, dezentraler Datenverwaltung und Technologieagnostizismus.
Seitdem sind Microservices, unterstützt durch Fortschritte in der Architektur, zu einer gängigen Architekturwahl geworden Containerisierungstechnologien wie Docker, Orchestrierungstools wie Kubernetes und Serverless-Computing-Plattformen. Doch wie funktionieren Microservices?
Wie funktionieren Microservices?
Im Kern zerlegt eine Microservices-Architektur eine große Anwendung in kleinere, unterschiedliche Dienste, von denen jeder für eine bestimmte Geschäftsfähigkeit verantwortlich ist. Diese Dienste kommunizieren über ein Netzwerk miteinander, häufig über REST-APIs, gRPC oder Nachrichtenbroker wie RabbitMQ oder Apache Kafka.
Nach der Definition von Martin Fowler und James Lewis weisen Microservices alle vier Hauptmerkmale auf:
- Einzelverantwortung: Jeder Microservice ist darauf ausgelegt, eine bestimmte Aufgabe oder Funktion auszuführen, was eine Spezialisierung ermöglicht und die Komplexität reduziert.
- Unabhängigkeit: Microservices können unabhängig voneinander entwickelt, bereitgestellt und skaliert werden, was für Flexibilität und Ausfallsicherheit sorgt.
- Dezentrales Datenmanagement: Microservices verfügen häufig über eigene Datenbanken, sodass keine einzige, zentrale Datenbank erforderlich ist.
- Technologie-Agnostizismus: Teams können für jeden Dienst die beste Technologie auswählen, ohne an die Auswahl anderer Dienste gebunden zu sein.
Dieser Ansatz steht im Gegensatz zur traditionellen monolithischen Architektur, bei der alle Anwendungskomponenten eng in einer einzigen, zusammenhängenden Einheit integriert sind.
Schlüsselphasen der Microservices-Bereitstellung
Während eine Microservices-Architektur eine Vielzahl von Vorteilen bietet, wie z. B. hohe Skalierbarkeit, Flexibilität, Effizienz, Fehlerisolierung usw., erfordert sie das Wissen, wie man Microservices effektiv einsetzt, und ein gutes Maß an Planung, damit sie erfolgreich ist.
That’s why having a comprehensive idea of key concepts, stages, and microservices best practices in deploying microservices is essential to a successful microservices architecture. Sehen wir uns also die wichtigsten Phasen der Microservices-Bereitstellung an und was jede Phase mit sich bringt.
Planung und Vorbereitung der Bereitstellung von Microservices
All good things require planning and patience, and to deploy microservices successfully, you’ll certainly need a good deal of planning and patience. Aus diesem Grund ist es wichtig, die Best Practices für Microservices zu befolgen und alles zu planen und vorzubereiten, was Sie für die Bereitstellung von Microservices benötigen.
Wie ich bereits erwähnt habe, ist eines der wichtigsten Prinzipien und Merkmale von Microservices das Prinzip der Einzelverantwortung. By staying faithful to this principle and making sure that each microservice focuses on and is responsible for one function and capability, you allow your team to develop, deploy, and scale services independently.
Darüber hinaus ist eine Unterkategorie dieses Prinzips die Konstruktionsprinzip der losen Kupplung. Dies bedeutet, dass jeder Dienst für die Kommunikation unabhängig funktionieren kann und nur minimal von anderen Diensten abhängig ist. Dies wiederum ermöglicht, dass Änderungen oder Aktualisierungen an einem Dienst keine Auswirkungen auf andere Dienste haben, was eine unabhängige Skalierung von Microservices ermöglicht.
Dies verringert das Risiko kaskadierender Ausfälle, bei denen ein Problem oder Ausfall in einem Teil eines Systems eine Kettenreaktion auslöst, die zu Ausfällen im gesamten System und zum Ausfall des gesamten Dienstes führt.
Eine wichtige Vorgehensweise bei Microservices ist die Bereitstellung eines dedizierten Datenspeichers für jeden Service bei der Bereitstellung von Microservices als Erweiterung des Designprinzips der losen Kopplung, da dies Konflikte verhindert und eine bessere Service-Skalierbarkeit ermöglicht.
Darüber hinaus benötigen Sie asynchrone Kommunikationsmuster für Mikrodienste, wie z. B. Nachrichtenbroker, um sicherzustellen, dass jeder Dienst ohne direkte Abhängigkeiten kommunizieren kann.
Das letzte Puzzleteil ist die Implementierung von CI/CD-Pipelines (Continuous Integration und Continuous Delivery) für Microservices. Mithilfe dieser Pipelines können Teams neue Funktionen oder Korrekturen bereitstellen CI/CD-Tools wie Jenkins und GitLab, die es Unternehmen ermöglichen, die Systemstabilität aufrechtzuerhalten und gleichzeitig häufig neue Funktionen zu veröffentlichen.
Nachdem Sie nun eine allgemeine Vorstellung von der Planung und Vorbereitung haben, die für die Bereitstellung von Microservices erforderlich ist, sprechen wir über Strategien für die Bereitstellung von Microservices.
Microservices-Bereitstellungsstrategien
Wenn Sie Microservices bereitstellen, hängt die Auswahl einer Bereitstellungsstrategie von der Dienstfunktion, dem Datenverkehr, der Infrastruktureinrichtung, der Teamkompetenz und Kostenüberlegungen ab. Im Allgemeinen lauten die Strategien zur Bereitstellung von Microservices jedoch wie folgt:
- Serviceinstanz pro Container: Bei diesem Ansatz wird jeder Microservice in einem eigenen Container ausgeführt, was eine bessere Isolation bietet als das Modell mit mehreren Instanzen pro Host. Container ermöglichen eine einfache Skalierung und verbessern die Ressourcenzuteilung.
- Dienstinstanz pro virtueller Maschine: Jeder Dienst wird in einer separaten virtuellen Maschine (VM) ausgeführt und bietet so eine noch größere Isolation als Container. Dies verbessert zwar die Sicherheit und Stabilität, verursacht jedoch in der Regel mehr Overhead.
- Gestaffelte Veröffentlichungen: Stellen Sie Microservice-Versionen zunächst für eine kleine Untergruppe von Benutzern bereit und testen Sie deren Stabilität vor einem vollständigen Rollout. Dieser Ansatz minimiert die Auswirkungen bei auftretenden Problemen und ermöglicht schnelle Rollbacks, um die Systemintegrität aufrechtzuerhalten.
- Blau-Grün-Bereitstellung: Bei dieser Methode werden zwei identische Produktionsumgebungen verwendet, wobei eine Umgebung den Live-Verkehr bedient, während die andere zum Testen der nächsten Version verwendet wird. Die Blau-Grün-Bereitstellung ermöglicht einfache Rollbacks und Aktualisierungen ohne Ausfallzeiten, da der Datenverkehr nahtlos zwischen den beiden Umgebungen umgeschaltet werden kann.
- Gestaffelte Veröffentlichungen: Diese Strategie beinhaltet die schrittweise Einführung von Updates für verschiedene Benutzersegmente oder Umgebungen. Es beginnt oft mit internen Umgebungen, bevor es in die Produktion geht, wodurch der Explosionsradius potenzieller Probleme begrenzt wird und Teams die Möglichkeit haben, Probleme schrittweise anzugehen.
- Serverlose Bereitstellung: Dieser Ansatz nutzt serverlose Plattformen wie AWS Fargate und Google Cloud Run, die die Infrastrukturverwaltung automatisieren, indem sie die Skalierung und Ressourcenzuweisung für Sie übernehmen. Bei der serverlosen Bereitstellung müssen Sie die zugrunde liegenden Server nicht verwalten, sodass Sie sich auf Ihre Microservices selbst konzentrieren können.
Sobald Sie einen der oben genannten Microservices für die Bereitstellung von Microservices ausgewählt haben, benötigen Sie ein Microservices-Orchestrierungstool.
Microservices-Orchestrierung
Nachdem Sie sich für eine der vielen Microservices-Bereitstellungsstrategien entschieden haben, benötigen Sie eine Art Dirigent für die Microservice-Orchestrierung. Microservice-Orchestrierungstools, wie z Kubernetes, helfen bei der Automatisierung der Microservices-Bereitstellung, der Microservices-Skalierung, der Microservices-Überwachung und der Verwaltung von Container-Microservices.
Airbnb beispielsweise nutzt Kubernetes und ermöglicht seinen Ingenieuren so die Bereitstellung Hunderter Änderungen an ihren Microservices ohne manuelle Aufsicht. Ein wichtiges Merkmal von Microservices-Orchestrierungstools wie Kubernetes ist der integrierte Lastausgleich.
Eine kompetente Lastausgleichsfunktion hilft dabei, eingehenden Datenverkehr auf mehrere Instanzen eines Microservices zu verteilen. Dies verhindert, dass eine einzelne Instanz zu einem Engpass wird, und verbessert die Fähigkeit des Systems, Nachfragespitzen zu bewältigen.
Kubernetes spielt durch seine Selbstheilungsfunktionen, bei denen ausgefallene Container automatisch ersetzt und neu gestartet werden, eine wichtige Rolle bei der Verwaltung von Microservices. Die New York Times nutzt diese Funktion, um ihre Microservices aufrechtzuerhalten, ohne die Benutzererfahrung zu beeinträchtigen und Ausfallzeiten zu erleiden.
Darüber hinaus verbessert Kubernetes mithilfe von ConfigMaps und Secrets auch die Sicherheit von Microservices wie Konfigurationen und Geheimnisse wie Datenbankanmeldeinformationen oder API-Schlüssel. Dies ist besonders wichtig für Unternehmen und Dienste wie Uber, die mit sensiblen Kunden- und Benutzerinformationen umgehen.
Schließlich sind Microservices-Orchestrierungstools wie Kubernetes besonders nützlich für Microservice-Strategien, die fortlaufende Updates und Rollbacks beinhalten, wie etwa gestaffelte Releases. Rolling Updates ermöglichen die Bereitstellung neuer Microservice-Versionen ohne Dienstunterbrechungen, indem einige Instanzen der alten Version weiterhin ausgeführt werden.
Sobald Sie Ihr Microservices-Orchestrierungstool eingerichtet haben, müssen Sie es erstellen und automatisieren CI/CD-Pipelines für die Bereitstellung von Microservices.
CI/CD-Pipelines für die Bereitstellung von Microservices
Wie bereits erwähnt, sind Continuous Integration- und Continuous Delivery-Pipelines für Microservices wichtige Aspekte der Microservices-Bereitstellung. Die CD-Pipelines in CI/CD-Pipelines sind für die automatische Bereitstellung von Codeänderungen in der Produktion verantwortlich, sobald sie die Test- und Integrationsphasen der CI/CD-Pipeline bestehen.
Dann kommt der CD-Teil der CI/CD-Pipelines ins Spiel, sodass der Dienst immer dann, wenn Codeänderungen die Test- und Integrationsphasen bestehen, in einem Microservices-Orchestrierungstool wie einem Kubernetes-Cluster bereitgestellt wird.
Darüber hinaus werden die Test- und Integrationsphasen alle automatisch von den CI/CD-Pipelines durchgeführt, da Unit-Tests, Integrationstests und End-to-End-Tests in die Pipeline integriert werden.
Dies ermöglicht es Teams, Aktualisierungen in jeder Phase zu validieren und gleichzeitig die Systemstabilität aufrechtzuerhalten. Und wenn trotz der verschiedenen Tests Probleme mit Codeänderungen auftreten, können automatisierte Rollbacks auf die vorherige stabile Version zurückgesetzt werden.
Schließlich hilft die Implementierung von CI/CD-Pipelines für Microservices gemäß den Best Practices für Microservices Unternehmen, eine schnellere Entwicklung zu erreichen, manuelle Fehler zu reduzieren und hohe Qualitätsstandards aufrechtzuerhalten.
Viele Unternehmen wie Spotify, Expedia, iRobot, Lufthansa, Pandora usw. nutzen CI/CD-Pipelines für Microservices über CI/CD-Tools wie CircleCI, AWS CodePipeline und GitLab, um Bereitstellungsprozesse zu automatisieren, eine konsistente Codequalität sicherzustellen und neue Funktionen schnell bereitzustellen und gleichzeitig die Systemstabilität aufrechtzuerhalten.
Kommunikationsmuster von Microservices
Wie Microservices miteinander kommunizieren, hängt vollständig von der Funktion, der Gesamtarchitektur, der gewünschten Skalierbarkeit und der Zuverlässigkeit Ihrer Microservices ab. Im Allgemeinen werden zwei Haupttypen von Microservices-Kommunikationsmustern verwendet: synchron Und asynchron Kommunikationsmuster von Microservices.
Bei synchronen Microservices-Kommunikationsmustern interagieren Dienste in Echtzeit, was bedeutet, dass ein Dienst eine Anfrage sendet und auf eine Antwort wartet, bevor er fortfährt. Die am häufigsten verwendeten Kommunikationsmuster für synchrone Microservices sind REST-APIs (Representational State Transfer)., gRPC (Google Remote Procedure Call), Und GraphQL.
Typischerweise werden diese Art von Microservices-Kommunikationsmustern in Branchen und Unternehmen verwendet, die typischerweise Echtzeit-Datenverarbeitung und sofortige Antworten benötigen. Branchen wie das Finanzwesen, das Gesundheitswesen und der E-Commerce nutzen häufig synchrone Kommunikationsmuster, um sicherzustellen, dass Transaktionen, Datenabrufe oder Interaktionen sofort erfolgen und ein reibungsloses und reaktionsfähiges Benutzererlebnis gewährleistet ist.
Obwohl synchrone Microservices-Kommunikationsmuster Vorteile wie Echtzeitantworten und Einfachheit bieten, weisen sie aufgrund ihrer engen Kopplung, geringer Skalierbarkeit bei hoher Auslastung, langsamer Reaktionszeiten und hoher Latenz bei Instanzen mit hohem Datenverkehr auch bestimmte Nachteile auf, z. B. potenzielle Engpässe.
Andererseits sind asynchrone Microservices-Kommunikationsmuster in der Regel besser für Microservices geeignet, da sie auf dem Prinzip der losen Kopplung basieren, das wir zuvor besprochen haben.
Diese Art von Microservices-Kommunikationsmuster entkoppelt Dienste, indem es ihnen ermöglicht, Nachrichten über einen Broker wie Kafka oder RabbitMQ zu senden und zu empfangen. Durch das Senden von Nachrichten an eine Warteschlange, die als Puffer fungiert, kommunizieren Dienste unabhängig voneinander, anstatt wie bei synchronen Kommunikationsmustern auf eine Antwort zu warten. Dieser Puffer ermöglicht es anderen Diensten, Nachrichten in ihrem eigenen Tempo zu verarbeiten, sodass der Absender seine Arbeit fortsetzen kann, ohne auf den Empfänger warten zu müssen.
Das asynchrone Microservices-Kommunikationsmuster bietet nicht nur eine entkoppelte Struktur für die Microservices-Bereitstellung, sondern bietet auch die gleiche Echtzeitreaktion wie synchrone Microservices-Kommunikationsmuster.
Dies liegt an der ereignisgesteuerten Architektur der asynchronen ereignisgesteuerten Kommunikationsmuster der Microservices, da Dienste kommunizieren, indem sie Ereignisse aussenden, wenn eine bestimmte Aktion auftritt. Andere Dienste können diese Ereignisse abonnieren und entsprechend reagieren. Dies ermöglicht hochreaktionsfähige Systeme, die in Echtzeit auf Änderungen reagieren, ohne dass eine direkte Kopplung zwischen Diensten erforderlich ist.
Darüber hinaus in asynchron Veröffentlichen-Abonnieren (Pub/Sub) Bei Kommunikationsmustern von Microservices senden die Dienste (Herausgeber) Nachrichten an ein Thema und andere Dienste (Abonnenten) hören auf dieses Thema, um Aktualisierungen zu erhalten. Dieses Modell unterstützt mehrere Abonnenten und sendet gleichzeitig Nachrichten an viele Dienste.
Und schließlich, ähnlich wie bei ereignisgesteuerten Mustern, asynchron choreografiebasierte Saga Kommunikationsmuster von Microservices verwenden auch Ereignisse, um miteinander zu kommunizieren; In diesem Muster gilt jedoch eine bestimmte Reihenfolge, was bedeutet, dass Ereignisse den nächsten Schritt und die Aktivierung eines bestimmten Dienstes auslösen.
Der Unterschied besteht darin, dass es bei ereignisgesteuerten Mustern keine bestimmte Reihenfolge oder keinen bestimmten Arbeitsablauf gibt und mehrere Dienste auf ein Ereignis reagieren können, anstatt auf den spezifischen Prozess und die spezifische Reihenfolge in choreografiebasierten Saga-Mustern.
Welche Art von asynchronem Microservices-Kommunikationsmuster Sie verwenden, hängt von der Aufgabe und der Gesamtfunktion Ihrer Microservices ab. Nachrichtenwarteschlangen wie RabbitMQ und Amazon SQS werden typischerweise für die Aufgabenplanung, Arbeitslastverteilung und E-Commerce für Bestellabwicklungs- und Benachrichtigungssysteme verwendet.
Ereignisgesteuerte Nachrichtenbroker wie Apache Kafka und AWS EventBridge werden typischerweise für die Verarbeitung großer Ereignisströme in Echtzeit und das Ereignisrouting zwischen Mikrodiensten in Bereichen wie Finanzdienstleistungen und AWS-Umgebungen verwendet.
Was Publish-Subscribe-Nachrichtenbroker (Pub/Sub) wie Google Cloud Pub/Sub und Redis Streams betrifft, werden diese Nachrichtenbroker normalerweise für skalierbare Nachrichten über verteilte Systeme hinweg für Echtzeitanalysen und Ereignisaufnahme sowie Echtzeitbenachrichtigungen und Chat-Anwendungen verwendet.
Schließlich werden choreografiebasierte Saga-Nachrichtenbroker hauptsächlich für die Bestellabwicklung im E-Commerce, Reisebuchungssysteme und Anwendungsfälle verwendet, bei denen komplexe, mehrstufige Transaktionen über mehrere Dienste hinweg ohne zentrale Steuerung koordiniert werden müssen.
Microservice-Service-Erkennung
Sobald Sie ein Kommunikationsmuster eingerichtet und implementiert haben, das Ihren Anforderungen entspricht, müssen Sie zunächst sicherstellen, dass Ihre Dienste einander überhaupt finden können. Wie ich bereits erwähnt habe, spielen Orchestrierungstools für Microservices wie Kubernetes eine wichtige Rolle bei der Erkennung von Microservice-Services.
Dies geschieht durch die integrierte Diensterkennung, die Kubernetes DNS bereitstellt, die IP-Adressen und DNS-Einträge dynamisch aktualisiert, wenn Dienste skaliert werden oder ihren Standort innerhalb des Clusters ändern.
Diese Methode der Erkennung von Microservices-Diensten wird als serverseitige Erkennung bezeichnet, da die Routing-Verantwortung an einen Load Balancer delegiert wird, der dann die Registrierung abfragt und den Datenverkehr an die entsprechende Instanz weiterleitet.
Andererseits verfügen wir auch über die clientseitige Erkennungsmethode für die Erkennung von Microservice-Diensten, bei der der Dienst oder das API-Gateway eine Dienstregistrierung wie Consul oder Eureka abfragt, um verfügbare Instanzen zu finden.
Welche Methode der Serviceerkennung für Ihre Microservices-Bereitstellung am besten geeignet ist, hängt von den Anforderungen und der Skalierung des Systems ab.
Mit der clientseitigen Microservice-Service-Discovery hat der Client die volle Kontrolle darüber, mit welcher Instanz er kommuniziert. Dies ermöglicht nicht nur eine stärkere Anpassung, sondern reduziert auch die Komplexität, da kein zentraler Erkennungsdienst erforderlich ist.
Beispielsweise nutzt die Microservices-Bereitstellung von Netflix die clientseitige Microservice-Service-Erkennung mit Eureka und Ribbon für den Lastausgleich, sodass der Client anhand von Kriterien wie Latenz und Serverlast die beste Instanz auswählen kann.
Allerdings eignet sich die serverseitige Microservice-Service-Erkennung besser für größere Umgebungen, da eine zentralisierte Service-Erkennung die Effizienz verbessern und einen konsistenten Lastausgleich über ein verteiltes System hinweg ermöglichen kann.
Serverseitige Microservice-Service-Discovery-Lösungen wie Kubernetes, AWS Elastic Load Balancing und API-Gateways (Kong, NGINX usw.) tragen zur effizienten Weiterleitung des Datenverkehrs und zur Aufrechterhaltung einer hohen Verfügbarkeit bei und werden von Unternehmen wie Airbnb, Pinterest, Expedia, Lyft usw. verwendet.
Microservice-Sicherheit
Während die monolithische Architektur MSA größtenteils unterlegen ist, war die Sicherheit ein Aspekt, bei dem die monolithische Architektur die Nase vorn hatte. Da Microservices auf dem Loose Coupling-Prinzip basieren und in der Natur verteilt sind, kann eine singuläre, allgemeine Sicherheitsmaßnahme nicht umgesetzt werden.
Da jeder Dienst unabhängig abgesichert werden muss, sind zusätzliche Schutzmaßnahmen erforderlich, da die Angriffsfläche bei Microservices viel größer ist. Zu diesem Zweck werden, wie Sie vielleicht schon vermutet haben, häufig Standards wie OAuth2 und JSON Web Tokens (JWT) für die Authentifizierung und Autorisierung verwendet.
Darüber hinaus wird ein API-Gateway häufig auch zur Verwaltung der Sicherheit über Mikrodienste hinweg eingesetzt, da es die Authentifizierung und Autorisierung am Einstiegspunkt erzwingt. Darüber hinaus können Gateway-APIs auch Ratenbegrenzung, Protokollierung und Überwachung implementieren, was zusätzliche Ebenen der Microservice-Sicherheit bietet.
Während diese den Haupteinstiegspunkt sichern, sind weitere Mikroservice-Sicherheitsmaßnahmen erforderlich, um die Kommunikation zwischen Diensten abzudecken.
Hier kommen Service Meshes ins Spiel, da sie eine Ebene der Netzwerk-Microservice-Sicherheit hinzufügen, den Datenverkehr zwischen Diensten verschlüsseln und Richtlinien wie gegenseitiges TLS durchsetzen. Diese Server-Meshes richten grundsätzlich eine umfassende Ende-zu-Ende-Verschlüsselung ein, die die Sicherheit von Microservices deutlich verbessert.
Microservice-Skalierung
Einer der größten Vorteile von MSA und der eigentliche Grund, warum es entwickelt wurde, um die monolithische Architektur zu ersetzen, ist seine hohe Skalierbarkeit. Typischerweise kann die Skalierung von Microservices auf zwei Arten erfolgen: vertikal und horizontal.
Im Grunde bedeutet die vertikale Skalierung (Skalierung) von Microservices das Hinzufügen weiterer Ressourcen wie CPU oder Arbeitsspeicher zu einer vorhandenen Instanz. Alternativ verteilt die horizontale Microservice-Skalierung (Scale-out) die Last und erhöht die Kapazität.
Hinsichtlich der Implementierung ist die vertikale Microservice-Skalierung die einfachere von beiden, da Sie lediglich eine einzelne Instanz ändern müssen, indem Sie auf einen größeren Server upgraden, den Arbeitsspeicher oder die Verarbeitungsleistung in einer Cloud-Instanz erhöhen oder mehr Speicher hinzufügen.
Diese Art der Skalierung wird typischerweise in Fällen verwendet, in denen eine Erhöhung der RAM- oder CPU-Leistung die Abfrageleistung und Datenverarbeitung verbessern kann, beispielsweise bei Diensten, die für das In-Memory-Caching verantwortlich sind.
Die vertikale Skalierung von Microservices ist zwar einfacher und bietet eine sofortige Leistungssteigerung, hat aber auch Nachteile. Die vertikale Skalierung ist durch die Hardwarekapazität des Servers begrenzt. Daher müssen Sie irgendwann zur horizontalen Skalierung wechseln, um die vertikale Skalierung fortzusetzen.
Darüber hinaus ist die vertikale Skalierung mit hohen Kosten verbunden, da Hardware und größere Instanzen in der Regel einen hohen Preis haben. Wenn schließlich die hochskalierte Instanz ausfällt, fällt der Dienst vollständig aus, da keine zusätzlichen Instanzen zur Bewältigung der Last vorhanden sind.
Für die horizontale Microservice-Skalierung stellen Sie neue Instanzen dieses Dienstes bereit, anstatt die Ressource einer einzelnen Instanz zu aktualisieren. Obwohl diese Instanzen unabhängig voneinander arbeiten, verarbeiten sie dennoch denselben Dienst und Teile derselben Arbeitslast.
Im Gegensatz zur vertikalen Skalierung ist die horizontale Microservice-Skalierung unbegrenzt. Das bedeutet, dass Sie so viele Instanzen hinzufügen können, wie Sie möchten, um steigende Arbeitslasten und Datenverkehrsspitzen zu bewältigen, und bietet so eine bessere Skalierbarkeit.
Da Sie außerdem über mehrere Instanzen verfügen, legen Sie bei einem Ausfall einer Instanz nicht alle Eier in einen Korb, da andere Instanzen weiterhin Anfragen bearbeiten können. Schließlich ist die horizontale Skalierung auf lange Sicht viel kosteneffizienter, da Sie mehrere kleinere und günstigere Instanzen verwenden können, um eine zuverlässigere und leistungsfähigere Leistung zu erzielen.
Allerdings erfordern die horizontale Skalierung und das Hinzufügen weiterer Instanzen mehr Load Balancer, Microservice-Service-Erkennungsmechanismen und Microservice-Orchestrierungstools, wodurch Ihre Microservices-Architektur deutlich komplexer wird.
Die horizontale Skalierung eignet sich besser für Anwendungsfälle wie Webdienste und Anwendungen wie E-Commerce oder Social-Media-Plattformen, die häufig einem schwankenden Datenverkehr und einem hohen Anforderungsvolumen unterliegen.
Dabei handelt es sich jedoch nicht wirklich um ein Entweder-Oder, da beide Arten der Skalierung in Microservices unterstützt werden und in vielen Fällen notwendig sind. In der Regel verwenden kleinere Unternehmen die vertikale Skalierung, da diese viel einfacher zu implementieren und zu verwalten ist. Mit der Zeit und wenn die Anwendung wächst, wird jedoch eine horizontale Skalierung eingeführt, um der hohen Nachfrage gerecht zu werden.
Schließlich bieten Cloud-Plattformen Dienste zur automatischen Skalierung an, die basierend auf der Echtzeitnachfrage automatisch Instanzen hinzufügen oder entfernen, was Unternehmen erheblich dabei hilft, die vertikale und horizontale Skalierung auszubalancieren.
Microservice-Überwachung
Zu diesem Zeitpunkt sind Sie mit der Bereitstellung Ihrer Microservices so gut wie fertig. Es bleibt nur noch sicherzustellen, dass es konstant und zuverlässig funktioniert. Hier kommen Microservice-Überwachungstools zum Einsatz Prometheus und Grafana einsteigen.
Diese Tools bieten Echtzeiteinblicke in Servicemetriken, sodass Teams die Ressourcennutzung, Latenz und Fehlerraten verfolgen können. Darüber hinaus bieten diese Tools auch verteiltes Tracing (Jaeger, Zipkin usw.), das bei der Visualisierung von Anforderungsströmen über Dienste hinweg hilft und bei der Diagnose von Problemen von großem Nutzen sein kann.
Da sich Fehler schließlich aufgrund des verteilten Designs von Microservices über mehrere Services hinweg ausbreiten können, ist die Protokollaggregation eine entscheidende Praxis bei der Microservice-Überwachung. Durch die Konsolidierung von Protokollen auf einer zentralen Plattform und die Einrichtung von Echtzeitwarnungen sind Sie Problemen immer einen Schritt voraus und können proaktiv darauf reagieren, bevor sie sich auf Benutzer auswirken.
Letzte Gedanken
Auch wenn es sicherlich schwierig ist, sich mit der Welt der Microservices vertraut zu machen, kann das Verständnis der Grundlagen und Schlüsselphasen der Microservices-Bereitstellung den gesamten Prozess erheblich erleichtern. Darüber hinaus stehen Ihnen im Laufe der Jahre immer mehr Tools mit deutlich mehr Funktionen zur Verfügung, wodurch die Bereitstellung von Microservices einfacher denn je wird.
FAQ
Welche Bereitstellungsstrategien werden üblicherweise für Microservices verwendet?
Während es viele verschiedene Strategien für die Bereitstellung von Microservices gibt, umfassen die am häufigsten verwendeten Bereitstellungsstrategien Dienstinstanzen pro Container, schrittweise Veröffentlichungen, Blue-Green-Bereitstellung und serverlose Bereitstellung, die jeweils unterschiedliche Grade an Isolation, Flexibilität und Skalierbarkeit bieten.
Welche Rolle spielt Kubernetes bei der Orchestrierung von Microservices?
Microservices sind auf Microservice-Orchestrierungstools wie Kubernetes angewiesen, um die Bereitstellung, Skalierung und Verwaltung von Containerdiensten zu automatisieren und Lastausgleichs-, automatische Skalierungs- und Selbstheilungsfunktionen bereitzustellen, um belastbare und effiziente Microservices sicherzustellen.
Wie kann ich die Sicherheit in einer Microservices-Umgebung gewährleisten?
Aufgrund ihrer verteilten Natur sind Microservices hinsichtlich der Sicherheit komplizierter als monolithische Architekturen. Zur Sicherheit in Microservices gehören die Authentifizierung und Autorisierung von Anfragen, die Verschlüsselung der Kommunikation zwischen Diensten und die Implementierung von API-Gateways und Service-Netzen wie Istio für eine zentralisierte Sicherheitsverwaltung.
