Von einer monolithischen Anwendung zu Mikrodiensten in Google Kubernetes Engine migrieren

Last reviewed 2022-12-29 UTC

In diesem Artikel werden die allgemeinen Konzepte des Migrierens einer Website von einer monolithischen Plattform zu einer refaktorierten, containerbasierten Mikrodiensteplattform in Google Cloud beschrieben. Die Migration wird für jedes Feature einzeln durchgeführt, um ein umfangreiches Migrationsereignis und die damit verbundenen Risiken zu vermeiden. Dieser Artikel richtet sich an IT-Experten, die für eine komplexe Website verantwortlich sind, die auf einer monolithischen Plattform gehostet wird und modernisiert werden soll. Das Lesen dieses Artikels erfordert keine tieferen Kenntnisse von Google Cloud oder Kubernetes.

Das Ziel einer solchen Migration besteht darin, für einzelne Features der Website eine flexiblere und skalierbare Umgebung bereitzustellen, in der die Features einfacher verwaltet und aktualisiert werden können, als wenn sie Teil der monolithischen Plattform wären. Das Ausführen der Website in einer solchen Umgebung führt zu schnelleren Verbesserungen der einzelnen migrierten Features, sodass für die Nutzer ein Mehrwert geschaffen wird.

In diesem Artikel werden E-Commerce-Websites als Beispielarbeitslast verwendet. Viele E-Commerce-Websites werden mit monolithischen und proprietären Plattformen erstellt und eignen sich daher gut für die hier beschriebene Migration. Sie können die in diesem Artikel beschriebenen Prinzipien jedoch auf eine Vielzahl von Arbeitslasten anwenden. Sie können dann von den in diesem Artikel behandelten Prinzipien profitieren, wenn Ihre Systeme und Einschränkungen den hier beschriebenen ausreichend ähneln. Zum Beispiel eignen sich Websites für die Buchung von Hotels oder Mietwagen ebenfalls sehr gut für dieses Migrationsmuster.

Wie unter Migration zur Google Cloud: Einstieg beschrieben, gibt es drei Hauptmuster für die Migration in die Cloud: Lift-and-Shift, Improve-and-Move und Rip-and-Replace. In diesem Artikel wird eine bestimmte Variante des Rip-and-Replace-Musters beschrieben, bei der das Muster schrittweise auf jedes Feature der Anwendung anstatt auf die Anwendung als Ganzes angewendet wird.

Abgesehen von diesem Migrationsmuster wird in diesem Artikel auch auf zwei Hybridmuster eingegangen. Während der Migration an sich weist die Anwendung eine Hybridarchitektur auf, bei der sich manche Features bereits in der Cloud befinden und andere noch lokal zu finden sind. Nachdem die Migration abgeschlossen ist, wird die gesamte Anwendung zwar in der Cloud gehostet, interagiert jedoch immer noch mit Back-End-Diensten, die vor Ort verbleiben.

Terminologie

Anwendung

In diesem Artikel bezeichnet der Begriff Anwendung ein umfassendes Softwaresystem mit potenziell vielen Features, das von Endnutzern als eine Einheit wahrgenommen wird. Eine E-Commerce-Website ist beispielsweise eine Anwendung. Alle Aktionen, die mit einer Anwendung möglich sind, werden mit einem bestimmten Feature (oder einer Funktion) dieser Anwendung ausgeführt.

Feature

Eine Funktionseinheit einer Anwendung. Features können an die Nutzer gerichtet sein und für die Anwendung eine zentrale Rolle spielen (z. B. der Einkaufswagen auf einer E-Commerce-Website), an die Nutzer gerichtet und für die Anwendung erforderlich sein (z. B. die Anmeldefunktion) oder anwendungsintern sein (z. B. Verwaltung der Lagerbestände bei E-Commerce-Websites).

Dienst

Eine eigenständige Komponente einer Anwendung. In diesem Artikel geht es um Anwendungen aus verschiedenen Diensten, die für die Endnutzer nicht sichtbar sind. Beispielsweise ist eine Datenbank, die von einer Website verwendet wird, ein Dienst.

Monolithische Anwendung

Eine Anwendung, die als eine einzelne bereitstellbare Einheit erstellt wurde, wird auch einfach als Monolith bezeichnet. Zu den Beispielen zählen eine einzelne Java EE-Anwendung und eine einzelne .NET-Webanwendung. Eine monolithische Anwendung ist häufig mit einer Datenbank verknüpft und hat eine clientseitige Benutzeroberfläche.

Mikrodienst

Ein einzelner Dienst, der für ein Anwendungsfeature entwickelt wurde. Anwendungen, die in Form von Mikrodiensten entwickelt wurden, bestehen aus mehreren Diensten, die jeweils ein bestimmtes Ziel verfolgen. Beispielsweise könnten Sie einen Dienst haben, der für Ihre Kunden den Einkaufswagen verwaltet, einen weiteren zur Handhabung des Zahlungsdiensts sowie einen als Schnittstelle zu einer Back-End-Anwendung für Lagerartikel. Diese Mikrodienste sollten lose miteinander verknüpft sein und klar definierte APIs als Schnittstellen haben. Sie können in verschiedenen Sprachen und Frameworks geschrieben sein und unterschiedliche Lebenszyklen haben.

Hybridarchitektur

Eine Architektur, bei der Sie einen öffentlichen Cloud-Anbieter (z. B. Google Cloud) in Kombination mit privaten Ressourcen verwenden, die in Ihrem eigenen Rechenzentrum gehostet werden. Es gibt viele Gründe, die für eine Hybridarchitektur sprechen, und viele Möglichkeiten, diese zu implementieren. Genauere Informationen dazu erhalten Sie im Artikel Hybrid- und Multi-Cloud-Muster und -Praktiken.

Zustandslose und zustandsorientierte Dienste

Ein Hinweis darauf, ob ein Dienst die Datenspeicherung direkt verwaltet. In diesem Artikel wird die gleiche Definition von Zustandslosigkeit und Zustandsorientiertheit wie bei der Twelve-Factor App-Methode verwendet. Ein Dienst ist dann zustandslos, wenn er nicht auf Daten angewiesen ist, um zu funktionieren. Ein zustandsorientierter Dienst ist das Gegenteil davon. Beispielsweise ist ein Dienst, der die Einkaufswagen Ihrer Kunden verwaltet, zustandsorientiert, da er speichern und abrufen muss, welche Artikel sich im Einkaufswagen befinden. Ein Dienst, der die Verfügbarkeit von Artikeln über das Back-End-System prüft, ist zustandslos, da die Daten (der Zustand) vom Back-End-System gespeichert werden und nicht vom Dienst.

Was spricht dafür, auf Mikrodienste umzusteigen?

Das Aufteilen der Features einer Anwendung auf Mikrodienste hat die folgenden Vorteile, wovon die meisten darauf beruhen, dass die Mikrodienste lose miteinander verknüpft sind:

• Die Mikrodienste können unabhängig voneinander getestet und bereitgestellt werden. Je kleiner die Bereitstellungseinheit ist, desto einfacher ist das Bereitstellen.
• Sie können in verschiedenen Sprachen und Frameworks implementiert werden. Für jeden Mikrodienst können Sie die Technologie wählen, die sich für den jeweiligen Anwendungsfall am besten eignet.
• Sie können von verschiedenen Teams verwaltet werden. Dadurch, dass die Mikrodienste voneinander abgegrenzt sind, ist es leichter, einem Team einen Mikrodienst oder mehrere Mikrodienste zuzuweisen.
• Durch den Umstieg auf Mikrodienste sind die Teams weniger stark aufeinander angewiesen. Für jedes Team sind nur die APIs der Mikrodienste von Belang, für die es zuständig ist. Die Teams müssen sich weder darüber Gedanken machen, wie diese Mikrodienste implementiert werden, noch über ihre Releasezyklen usw.
• Sie können Ausfälle leichter im Design einplanen. Dadurch, dass die Dienste klar voneinander abgegrenzt sind, lässt sich leichter feststellen, was zu tun ist, wenn ein Dienst ausfällt.

Mikrodienste haben gegenüber monolithischen Anwendungen jedoch auch ein paar Nachteile:

• Da es sich bei einer auf Mikrodiensten basierenden Anwendung um ein Netzwerk verschiedener Dienste handelt, die häufig auf nicht offensichtliche Weise interagieren, nimmt die allgemeine Komplexität des Systems tendenziell zu.
• Im Gegensatz zu monolithischen Anwendungen läuft die Kommunikation bei Mikrodiensten über ein Netzwerk und nicht über interne Strukturen ab. In manchen Fällen könnte dies ein Sicherheitsproblem darstellen. Bei Istio wird dieses Problem gelöst, indem der Traffic zwischen den Mikrodiensten automatisch verschlüsselt wird.
• Aufgrund von Latenzen zwischen den Diensten kann es schwierig sein, das gleiche Leistungsniveau wie mit einem monolithischen Ansatz zu erreichen.
• Das Verhalten Ihres Systems wird nicht von einem einzelnen, sondern von mehreren Diensten und deren Zusammenspiel bestimmt. Aus diesem Grund ist es schwieriger, nachzuvollziehen, wie sich Ihr System in der Produktionsumgebung verhält (seine Beobachtbarkeit). Auch dieses Problem kann mit Istio umgangen werden.

Zwar setzen einige Unternehmen, wie z. B. Google, Mikrodienste bereits seit Jahren ein, das Konzept – und seine Verbindung zu serviceorientierter Architektur (SOA) – wurde jedoch von James Lewis, Martin Fowler und Sam Newman in ihrem Artikel Microservices formalisiert.

Übersicht über den Migrationsprozess

Der in diesem Artikel beschriebene Migrationsprozess ist langwierig und kann Monate in Anspruch nehmen, da es sich dabei um ein umfangreiches Projekt handelt. In diesem Abschnitt wird schrittweise erläutert, wie Sie eine monolithische, lokale Anwendung zu einer Anwendung machen, die vollständig in Google Cloud gehostet wird und auf Mikrodiensten basiert.

Monolithische, lokale Anwendung als Ausgangspunkt

In diesem Artikel wird davon ausgegangen, dass Sie derzeit eine monolithische Anwendung lokal ausführen. Die folgende Architektur-Übersichtsgrafik ähnelt wahrscheinlich Ihrer aktuellen Architektur.

Dieses Diagramm wurde nicht in der Absicht erstellt, Ihre aktuellen Systeme exakt abzubilden. Bei einer Architektur dieser Art finden sich zum Beispiel typischerweise die folgenden Technologien:

• Relationale Datenbanken wie Oracle®-Datenbank oder SAP HANA
• E-Commerce-Plattformen wie Oracle ATG oder SAP Hybris
• Apache Solr oder andere Suchmaschinen

Hinweis: Wenn Sie für Ihre monolithische Anwendung bereits eine Lift-and-Shift-Migration zur Cloud durchgeführt haben, können Sie sich dennoch an die in diesem Artikel beschriebenen Konzepte halten. Die Migration zu Mikrodiensten wird dann vermutlich leichter gelingen, da sich Ihre Daten bereits in der Cloud befinden.

Auf Mikrodiensten basierende Anwendung in Google Cloud als Endpunkt

Der hier beschriebene Migrationsprozess führt von einer lokalen, monolithischen Architektur zu einer auf Mikrodiensten basierenden Architektur, die in Google Cloud ausgeführt wird. Die Zielarchitektur sieht so aus:

Bei der Zielarchitektur führen Sie Mikrodienste in Google Kubernetes Engine (GKE) aus. Kubernetes ist eine Plattform zum Verwalten, Hosten, Skalieren und Bereitstellen von Containern. Container bieten die Möglichkeit zum portablen Verpacken und Ausführen von Code. Sie eignen sich gut für Anwendungen, die in Form von Mikrodiensten entwickelt wurden, bei denen jeder Mikrodienst in einem eigenen Container ausgeführt werden kann. Die Mikrodienste können über eine private Netzwerkverbindung, die mit Cloud Interconnect oder Cloud VPN erstellt wurde, Aufrufe an Ihre Back-End-Systeme senden. Alternativ können Sie mit Apigee die Back-End-Dienste verfügbar machen und den sicheren Zugriff darauf ermöglichen. Weitere Informationen zu diesen Produkten sowie dazu, wie Sie das passende auswählen, finden Sie weiter unten in diesem Dokument unter Apigee, Cloud VPN und Cloud Interconnect.

Die Mikrodienste können je nach Bedarf auch mit einer Reihe anderer Google Cloud-Produkte interagieren. Cloud Storage und Cloud SQL sind zwei der gängigsten Google Cloud-Produkte für E-Commerce-Anwendungen. Pub/Sub kann bei asynchronen Aufgaben als Nachrichtenbus zwischen verschiedenen Mikrodiensten verwendet werden.

Sie geben Ihre Anwendung im Internet auf zwei Arten frei: direkt über einen Google Cloud-Load-Balancer für Assets wie Bilder und optional über Apigee für Ihre öffentlichen APIs.

In den folgenden Tabellen sind die Produkte aufgeführt, die Sie in Ihrer Zielarchitektur verwenden können. Nicht alle sind obligatorisch; ihre Verwendung hängt von Ihrem genauen Anwendungsfall ab.

Netzwerk

Google Cloud-Produkt	Nutzung	Hinweise
Virtual Private Cloud	Eine VPC ist ein softwarebasiertes privates Netzwerk, in dem sich Ihre Ressourcen (z. B. ein GKE-Cluster) befinden. VPC umfasst Features wie Firewallregeln und Routing. VPCs sind global verfügbar. Durch Cloud VPN werden mithilfe der Glasfasernetzwerke von Google weltweit private Verbindungen ermöglicht.	Cloud VPC ist in dieser Architektur obligatorisch.
Cloud Interconnect	Cloud Interconnect erweitert Ihr lokales Netzwerk über eine hochverfügbare Verbindung mit niedriger Latenz auf das Google-Netzwerk. Die Verbindung zu Google kann direkt über Dedicated Interconnect oder über Partner Interconnect und einen unterstützten Dienstanbieter hergestellt werden.	Ihre E-Commerce-Website muss wahrscheinlich lokale Back-End-Dienste wie ein Verwaltungssystem für ein Warenlager oder ein Abrechnungssystem aufrufen. Cloud Interconnect ist eine der möglichen Lösungen für diesen Zweck.
Cloud VPN	Mit Cloud VPN können Sie Ihr lokales Netzwerk über einen IPsec-VPN-Tunnel sicher auf das Google-Netzwerk ausdehnen. Traffic wird verschlüsselt über das Internet zwischen den beiden Netzwerken übertragen. Cloud VPN eignet sich für die Übertragung kleinerer Datenmengen.	Ihre E-Commerce-Website muss wahrscheinlich lokale Back-End-Dienste wie ein Verwaltungssystem für ein Warenlager oder ein Abrechnungssystem aufrufen. Cloud VPN ist eine der möglichen Lösungen für diesen Zweck.
Cloud Load Balancing	Cloud Load Balancing ist die verwaltete Load-Balancing-Lösung von Google. Es unterstützt sowohl L4-Load-Balancing (TCP/UDP) als auch L7-Load-Balancing (HTTP). Es kann auch als SSL-Terminierungsendpunkt (HTTPS) dienen. Beim Erstellen eines Google Cloud-Load-Balancers erhalten Sie eine einzelne Anycast-IP-Adresse. Alle Nutzer, die auf diese IP-Adresse zuzugreifen versuchen, werden automatisch zum nächstgelegenen Point of Presence von Google weitergeleitet, um die Netzwerklatenz zu reduzieren – dank des Netzwerks der Premium-Stufe von Google.	Cloud Load Balancing ist in dieser Architektur obligatorisch.
Cloud CDN	Cloud CDN (Content Delivery Network) verwendet global verteilte Edge Points of Presence von Google, um Inhalte mit HTTP(S)-Load-Balancing in Nutzernähe im Cache zu speichern. Das Caching von Inhalten am Rand des Google-Netzwerks ermöglicht eine schnellere Bereitstellung von Inhalten für Ihre Nutzer bei gleichzeitiger Senkung der Bereitstellungskosten.	Cloud CDN ist in diesem Szenario nicht obligatorisch, wird jedoch empfohlen, insbesondere für statische Inhalte.

Plattform

Google Cloud-Produkt	Nutzung	Hinweise
Google Kubernetes Engine (GKE)	GKE ist das verwaltete Kubernetes-Produkt von Google für die Erstellung von Containeranwendungen. GKE ist mit Open-Source-Kubernetes vollständig kompatibel und bietet viele erweiterte Features, wie regionale Cluster für Hochverfügbarkeit, private Cluster, vertikales Pod-Autoscaling, Cluster-Autoscaling, GPUs und Knoten auf Abruf.	GKE ist in dieser Architektur obligatorisch.
Istio	Durch Istios einheitliche Methode, Mikrodienste zu schützen, zu verbinden und zu überwachen, wird das Verwalten von Mikrodienst-Bereitstellungen leichter.	Istio ist in dieser Architektur nicht obligatorisch, bietet jedoch nützliche Features wie erweitertes Monitoring, Trafficverschlüsselung und Routing sowie die Fehlereinfügung, um die Robustheit Ihrer Anwendung zu testen.
Apigee	Apigee ist ein verwaltetes API-Gateway. Mit Apigee können Sie Ihre APIs sicher entwerfen, veröffentlichen, überwachen und monetarisieren. Sie können Apigee verwenden, um sowohl öffentliche als auch private APIs verfügbar zu machen. In einer Mikrodienstarchitektur werden öffentliche APIs in Google Cloud gehostet, während die lokalen Back-End-Systeme als private APIs verfügbar gemacht werden können, die nur von Mikrodiensten in Google Cloud genutzt werden.	Apigee ist in dieser Architektur nicht obligatorisch, es wird jedoch empfohlen, dass der gesamte Inhalt Ihrer Website von öffentlichen APIs bereitgestellt wird. Ein API-Gateway wie Apigee bietet viele Features für die API-Verwaltung, z. B. Kontingente, Versionsverwaltung und Authentifizierung.
Pub/Sub	Pub/Sub ist ein Nachrichten- und Streamingsystem. Wenn es in dieser Architektur verwendet wird, fungiert es als Nachrichtenbus zwischen Mikrodiensten; dies ermöglicht asynchrone Workflows zwischen den Mikrodiensten.	Pub/Sub ist nicht obligatorisch, aber durch sein Publisher/Abonnenten-Muster können Skalierungsprobleme ggf. verringert werden.

Speicher

Google Cloud-Produkt	Nutzung	Hinweise
Cloud Storage	Cloud Storage bietet eine API für einen einheitlichen Objektspeicher. Es eignet sich für viele Anwendungsfälle, z. B. zum Bereitstellen von Websiteinhalten, zum Sichern und Archivieren von Daten und zum Verteilen großer Objekte. Bei einer E-Commerce-Website wird Cloud Storage hauptsächlich zum Speichern und Bereitstellen statischer Assets wie Produktbilder und -videos verwendet.	Aufgrund seiner nahtlosen Skalierbarkeit und da es zusammen mit Cloud CDN verwendet werden kann, eignet sich Cloud Storage für die in diesem Dokument beschriebene Mikrodienstarchitektur sehr gut. Es wird daher empfohlen, Cloud Storage zu verwenden.
Firestore	Firestore ist eine schnelle, vollständig verwaltete NoSQL-Dokumentendatenbank.	Cloud SQL ist in diesem Szenario nicht obligatorisch, eignet sich jedoch gut für einige gängige Anwendungsfälle im Zusammenhang mit E-Commerce-Websites. Sie können damit beispielsweise den Inhalt der Einkaufswagen von Nutzern und Nutzermetadaten speichern.
Cloud SQL	Cloud SQL ist das verwaltete Produkt für MySQL und PostgreSQL von Google. Diese relationalen Datenbanken sind vielseitig einsetzbar.	Cloud SQL ist in diesem Szenario nicht obligatorisch, eignet sich jedoch gut für einige gängige Anwendungsfälle im Zusammenhang mit E-Commerce-Websites. Mit Cloud SQL können Sie beispielsweise Bestellungen speichern und somit das Durchführen von einfachen Aggregationen und Berechnungen ermöglichen.
Cloud Spanner	Spanner ist eine global verfügbare, horizontal skalierbare, strikt konsistente relationale Datenbank. Da im entsprechenden SLA eine Betriebszeit von 99,999 % für multiregionale Instanzen garantiert wird, bedeutet dies eine sehr hohe Verfügbarkeit Ihrer geschäftskritischen Daten.	Spanner ist in diesem Szenario nicht obligatorisch. Da sie eine relationale Datenbank mit Transaktionskonsistenz in globalem Maßstab ist, eignet sich Spanner gut für E-Commerce-Websites, die auf eine internationale Zielgruppe ausgelegt sind.
Memorystore	Memorystore for Redis ist eine verwaltete Version von Redis, einer In-Memory-Datenbank mit einer Schlüssel/Wert-Datenstruktur. Als Datenbank mit niedriger Latenz eignet sich Redis gut für Daten, auf die häufig zugegriffen wird.	Memorystore ist in diesem Szenario nicht obligatorisch, eignet sich jedoch gut für verschiedene gängige Anwendungsfälle von Websites, z. B. das Speichern von Informationen zu Nutzersitzungen und das Bereitstellen eines Anwendungs-Caches.

Natürlich können Sie auch andere Google Cloud-Produkte verwenden, aber in dieser Liste sind die Google Cloud-Produkte aufgeführt, die in E-Commerce-Architekturen am häufigsten verwendet werden. Behalten Sie auch im Hinterkopf, dass der logische nächste Schritt hinsichtlich der Erweiterung dieser Architektur darin besteht, mit Produkten wie Cloud Bigtable, BigQuery und Vertex AI spezielle Komponenten hinzuzufügen, um aus den vorhandenen Daten Informationen zu gewinnen.

Vielleicht entscheiden Sie sich auch dafür, einige Ihrer aktuellen Technologien in dieser Zielarchitektur weiter zu verwenden, entweder weil diese für Sie immer noch relevant sind oder weil es zu teuer ist, sie umzustellen. Im Folgenden finden Sie einige Beispiele dafür, wie Sie gängige E-Commerce-Technologien in Google Cloud ausführen können:

• Google Cloud-Partner können Ihre Oracle-Arbeitslasten verwalten, sodass zwischen diesen Arbeitslasten und Ihrer Google Cloud-Infrastruktur eine Latenz von unter einer Millisekunde liegt. Dadurch können Sie auch Ihre vorhandenen Lizenzen wiederverwenden.
• Dank der Partnerschaft zwischen SAP und Google Cloud können Sie eine Vielzahl von SAP-Arbeitslasten in Google Cloud ausführen, einschließlich HANA und Hybris.
• Sie können Apache Solr in GKE ausführen oder einige der in Google Cloud Marketplace verfügbaren Solr-Lösungen verwenden.
• Sie können Elasticsearch in GKE ausführen (z. B. mit der Cloud Marketplace-Lösung) oder den auf Google Cloud basierenden verwalteten Dienst von Elastic verwenden.

Apigee, Cloud VPN und Cloud Interconnect

Eine der wichtigsten Entscheidungen, die Sie gleich zu Beginn dieses Projekts treffen müssen, ist der Umgang mit der Kommunikation zwischen den neuen, in GKE gehosteten Mikrodiensten und Ihrem lokalen Legacy-System. Es gibt zwei Hauptlösungen, die auch zusammen eingesetzt werden können: API-basierte Kommunikation oder auf einer privaten Verbindung basierende Kommunikation

Bei der API-basierten Lösung verwenden Sie eine API-Verwaltungslösung wie Apigee als Proxy zwischen den beiden Umgebungen. So können Sie genau steuern, welche Bestandteile Ihrer Legacy-Systeme Sie verfügbar machen und wie Sie dabei vorgehen. Außerdem können Sie die Implementierung einer API reibungslos refaktorieren (d. h. von einem Legacy-Dienst auf einen Mikrodienst umstellen), ohne dass sich für die Nutzer der API Beeinträchtigungen ergeben. Das folgende Diagramm zeigt die Interaktionen zwischen Apigee, Ihren lokalen Systemen und Ihren Google Cloud-Systemen.

Bei dieser Variante können Muster für die skalierbare Bereitstellung von Kubernetes APIs mit Apigee und das E-Book Beyond ESB Architecture with APIs von Apigee hilfreich sein.

Bei einer Lösung, die auf einer privaten Verbindung basiert, verbinden Sie die Google Cloud-Umgebung und die lokale Umgebung über eine private Netzwerkverbindung. Die Mikrodienste kommunizieren über diese Verbindung mit Ihren Legacy-Systemen. Sie können IPSec-basierte VPN-Tunnel mit Cloud VPN einrichten. Wenn Sie mehr Bandbreite benötigen, bietet Cloud Interconnect eine hochverfügbare Verbindung mit geringer Latenz. Eine Übersicht über die verschiedenen Optionen erhalten Sie unter Interconnect-Typ auswählen.

Das folgende Diagramm zeigt die Interaktionen zwischen Ihren lokalen Systemen und Ihren Google Cloud-Systemen über Cloud VPN oder Cloud Interconnect.

Eine API-basierte Lösung wird von den Anwendungsteams implementiert. Sie erfordert ab Beginn des Projekts eine stärkere Einbindung in die Legacy-Anwendung als eine Lösung, die auf einer privaten Verbindung basiert. Eine API-basierte Lösung bietet jedoch langfristig mehr Verwaltungsoptionen. Eine auf Cloud VPN oder Cloud Interconnect basierende Lösung wird von einem Netzwerkteam implementiert und erfordert zuerst eine weniger tiefgreifende Einbindung in die Legacy-Anwendung. Sie bietet jedoch auf lange Sicht keinen besonderen Mehrwert.

Hinweis: Sie können sowohl Apigee als auch Cloud VPN oder Cloud Interconnect verwenden. Sie könnten beispielsweise für die öffentlichen APIs ausschließlich Apigee verwenden – vor den Mikrodiensten und Legacy-Systemen, jedoch nicht zwischen diesen – und Cloud VPN oder Cloud Interconnect für die Kommunikation zwischen den Mikrodiensten und Legacy-Systemen nutzen. Sie können auch Apigee for Private Cloud verwenden, um APIs über Cloud VPN oder Cloud Interconnect verfügbar zu machen.

Der Migrationsprozess

In diesem Abschnitt werden die übergeordneten Schritte beschrieben, die Sie ausführen müssen, um zur neuen Architektur zu migrieren.

Vorbereitung

Bevor Sie den ersten Mikrodienst in GKE verschieben, müssen Sie die Google Cloud-Umgebung vorbereiten, in der Sie arbeiten werden. Erledigen Sie zuerst Folgendes, bevor Sie den ersten Mikrodienst in die GKE-Produktionsumgebung verschieben:

• Richten Sie Ihre Google Cloud-Organisation ein. Dies ist die globale Umgebung, in der später Ihre Google Cloud-Ressourcen gehostet werden. In diesem Schritt konfigurieren Sie außerdem Ihre Google-Identitäten – die Konten, die die Mitarbeiter Ihrer Organisation benötigen, um Google-Produkte verwenden zu können. Weitere Informationen finden Sie unter Entscheiden, wie Identitäten in Google Cloud eingebunden werden.
• Entwerfen Sie Ihre Google Cloud-Richtlinien für die Verwaltung Ihrer Google Cloud-Ressourcen. Im Artikel Richtlinienentwurf für Unternehmenskunden erhalten Sie hilfreiche Informationen zu diesem Thema.
• Erstellen Sie mit Infrastruktur als Code (IaC) einen Plan zum Bereitstellen Ihrer Google Cloud-Ressourcen, einschließlich der GKE-Cluster. Dadurch erhalten Sie standardisierte, reproduzierbare und prüfbare Umgebungen. Hierfür empfehlen wir Cloud Deployment Manager oder Terraform.
• Sehen Sie sich die unterschiedlichen GKE-Features an und passen Sie diese bei Bedarf an. Wenn es sich um eine geschäftskritische Anwendung handelt, möchten Sie möglicherweise einige der Standardeinstellungen ändern und Ihre Cluster härten. Hier erfahren Sie, wie Sie die Sicherheit Ihres Clusters erhöhen.
• Erstellen Sie Ihre Tools zur kontinuierlichen Integration/kontinuierlichen Bereitstellung (CI/CD) für Kubernetes. Sie können Cloud Build verwenden, um Ihre Container-Images zu erstellen, und Container Registry, um diese zu speichern und Image-Sicherheitslücken zu ermitteln. Sie können diese Produkte auch mit Ihren bestehenden CI/CD-Tools kombinieren. Bauen Sie auf dieser Arbeit auf und implementieren Sie die Best Practices für das Erstellen und Betreiben von Containern. Wenn Sie dies zu einem frühen Zeitpunkt im Projektverlauf tun, werden Probleme in der Produktionsumgebung vermieden.
• Richten Sie je nach gewählter Option ein Apigee-Konto bzw. eine private Verbindung zwischen Google Cloud und Ihrem lokalen Rechenzentrum mit Cloud VPN oder Cloud Interconnect ein.

Schrittweise migrieren

Sie sollten die Features Ihrer E-Commerce-Website nach und nach in die neue Umgebung migrieren und die Mikrodienste dann erstellen, wenn es erforderlich wird. Diese Mikrodienste können bei Bedarf ein Callback an das Legacy-System durchführen.

Dieser Ansatz entspricht dem Umwandeln dieses großen Migrations- und Refaktorierungsprojekts in mehrere kleinere Projekte. Diese Vorgehensweise hat zwei Vorteile:

• Die kleineren Projekte sind leichter abzugrenzen und hinsichtlich ihres Ablaufs und Umfangs einfacher zu verstehen als das Migrationsprojekt als Ganzes. Wenn die Website in einem Schritt migriert werden soll, benötigen die Teams mehr Wissen über die Interaktionen zwischen den Systemen, über die Einschränkungen und über Drittanbietersysteme, die davon abhängig sind, dass die Website verfügbar ist, und so weiter. Dadurch erhöht sich das Fehlerrisiko.
• Wenn Sie sich für viele kleinere Projekte entscheiden, bleiben Sie flexibler. Wenn Sie ein kleineres Team haben, kann das Team diese Projekte nacheinander angehen, ohne überfordert zu werden. Wenn Sie mehrere Teams haben, können Sie möglicherweise einen Teil der Arbeiten parallelisieren und mehrere Migrationen gleichzeitig leiten.

Die Entscheidung, welche Features migriert werden sollen und wann dies geschehen soll, ist eine der wichtigsten Entscheidungen, die Sie in dieser Phase des Projekts treffen. Bei dieser Entscheidung müssen Sie das Netz von Abhängigkeiten zwischen den einzelnen Features berücksichtigen. Manche Features sind möglicherweise stark auf andere Features angewiesen, um korrekt zu funktionieren, während andere Features möglicherweise sehr eigenständig funktionieren. Je weniger Abhängigkeiten ein Feature hat, desto einfacher ist deren Migration. Das Problem der Abhängigkeiten sowie weitere Faktoren, die Sie bei der Entscheidung, welches Feature zuerst migriert werden soll, berücksichtigen sollten, werden später im Abschnitt Welche Features sollten Sie zuerst migrieren? detaillierter behandelt.

Beispiel: Einkaufswagen migrieren

In diesem Abschnitt wird die Migration eines einzelnen Features, nämlich des Einkaufswagens einer E-Commerce-Website, beschrieben, um den Migrationsprozess zu veranschaulichen.

Damit Sie die Abhängigkeiten dieses Features verstehen, sollten Sie sich vor Augen führen, wie Nutzer auf E-Commerce-Websites typischerweise vorgehen und wie dies in einer monolithischen Anwendung implementiert werden kann:

1. Der Nutzer schaut sich auf der Website um und findet einen Artikel, an dem er interessiert ist.
2. Der Nutzer klickt auf Zum Einkaufswagen hinzufügen. Diese Aktion löst einen API-Aufruf vom Browser des Nutzers an das Einkaufswagenfeature aus. Dies stellt die erste Abhängigkeit dar: Das Front-End nimmt auf den Einkaufswagen Einfluss.
3. Wenn der Aufruf beim Einkaufswagenfeature eingeht, wird geprüft, ob der Artikel auf Lager ist. Dieses Ereignis löst einen API-Aufruf vom Einkaufswagenfeature an das System aus, mit dem das Warenlager verwaltet wird. Dies ist die zweite Abhängigkeit: Der Einkaufswagen hängt vom Subsystem des Warenlagers ab.
4. Wenn der Artikel auf Lager ist, speichert das Einkaufswagenfeature Informationen wie "Nutzer A hat 1 Instanz von Artikel X in seinem Einkaufswagen". Dies ist die dritte Abhängigkeit: Das Einkaufswagenfeature benötigt eine Datenbank, um diese Informationen zu speichern.
5. Wenn der Nutzer bezahlen möchte und den Zahlungsvorgang durchläuft, wird der Inhalt des Einkaufswagens vom Zahlungssubsystem abgefragt, um die Gesamtsumme zu berechnen. Wenn die Zahlung abgeschlossen ist, benachrichtigt das Zahlungssubsystem die Einkaufswagenfeature, damit diese den Einkaufswagen leert. Dies ist die vierte Abhängigkeit: Der Inhalt des Einkaufswagens wird vom Zahlungssubsystem abgefragt.

Das Einkaufswagenfeature wird also vom Front-End und vom Zahlungssubsystem aufgerufen und fragt selbst wiederum eine Datenbank und das Subsystem des Warenlagers ab.

Eine Dokumentendatenbank eignet sich gut, um die Inhalte von Einkaufswagen zu speichern. Sie benötigen die leistungsstarken Funktionen relationaler Datenbanken nicht, um diese Daten zu speichern. Außerdem lassen sich Einkaufswagen leicht über Nutzer-IDs indexieren. Firestore ist eine verwaltete und serverlose NoSQL-Dokumentendatenbank, die sich für diesen Anwendungsfall besonders gut eignet. Daher empfehlen wir diesen Datenspeicher für die Zielarchitektur.

Sie können die Einkaufswagendaten auf verschiedene Arten migrieren. Dies wird später im Abschnitt Strategien zur Datenmigration ausführlicher beschrieben. In diesem Dokument wird davon ausgegangen, dass der später beschriebene Ansatz "Planmäßige Wartung" für Sie akzeptabel ist. Gemäß diesem Ansatz migrieren Sie das Einkaufswagenfeature mit den folgenden übergeordneten Arbeitsschritten:

1. Erstellen Sie einen neuen Mikrodienst, der eine Einkaufswagen API implementiert. Verwenden Sie Firestore, um die Daten der Einkaufswagen zu speichern. Sorgen Sie dafür, dass dieser neue Mikrodienst das Subsystem des Warenlagers aufrufen kann.
2. Erstellen Sie ein Skript, das die Daten der Einkaufswagen aus dem Legacy-Einkaufswagensubsystem extrahiert und in Firestore schreibt. Schreiben Sie das Skript so, dass Sie es so oft wie nötig ausführen können und dass nur die Einkaufswagen kopiert werden, deren Inhalt sich seit der letzten Ausführung geändert hat.
3. Erstellen Sie nun ein Skript, das dieselbe Aufgabe für die andere Richtung übernimmt: Es kopiert den Inhalt von Einkaufswagen aus Firestore in das Legacy-System. Dieses Skript verwenden Sie nur, wenn Sie für die Migration ein Rollback durchführen müssen.
4. Machen Sie die Einkaufswagen API mit Apigee verfügbar.
5. Nehmen Sie die nötigen Änderungen am Front-End und am Zahlungssubsystem vor und testen Sie diese, damit sichergestellt ist, dass Front-End und Subsystem den neuen Einkaufswagenmikrodienst aufrufen können.
6. Führen Sie das Skript zur Datenmigration aus, das Sie in Schritt 2 erstellt haben.
7. Versetzen Sie Ihre Website in den Wartungsmodus.
8. Führen Sie das Skript zur Datenmigration noch einmal aus.
9. Stellen Sie die Änderungen aus Schritt 5 für das Legacy-Produktionssystem bereit.
10. Deaktivieren Sie den Wartungsmodus für die Website.

Das Einkaufswagenfeature Ihrer Website ist jetzt ein in Google Cloud gehosteter Mikrodienst. Schritt 5 ist wahrscheinlich der schwierigste Schritt in diesem Prozess, da Sie darin das Legacy-System ändern müssen. Dieser Schritt wird jedoch einfacher, je mehr Features Sie zu Mikrodiensten migrieren, da dann immer mehr Abhängigkeiten bereits Mikrodienste darstellen. Als Mikrodienste sind sie loser aneinander gekoppelt als in einer monolithischen Anwendung und lassen sich leichter ändern und bereitstellen.

Alternativ könnten Sie es einrichten, dass der neue Mikrodienst ein Callback an die ursprüngliche Einkaufswagendatenbank durchführt und dann die Daten in Firestore migriert werden. Ziehen Sie Folgendes in Betracht, wenn Sie zwischen diesen beiden Migrationsmodellen wählen: die Latenzzeit zwischen dem Mikrodienst und der ursprünglichen Datenbank, die Komplexität der Schema-Refaktorierung und die Strategie für die Datenmigration, die Sie verfolgen möchten

Welche Features sollten Sie zuerst migrieren?

In diesem Abschnitt erhalten Sie Tipps, wie Sie die Features identifizieren, die zuerst migriert werden sollten, also die erste Migrationsmaßnahme. Ein Divide-and-Conquer-Ansatz (Teile-und-Herrsche) ist immer die beste Wahl, um die mit komplexen Migrationen verbundenen Risiken zu senken.

Wenn Sie die Migration planen, ist es verlockend, mit Features zu beginnen, die nur geringe Auswirkungen auf die Migration haben. Dies könnte zwar zu schnellen Erfolgen führen, aber Ihr Team wird daraus nicht viel lernen. Anstatt direkt mit der Migration zu beginnen, sollten Sie alle Features bewerten und Pläne für deren Migration erstellen.

Sie können folgende Auflistung von Bewertungsbereichen als Grundgerüst für die Analyse der einzelnen Features verwenden:

• Geschäftsprozesse
• Design und Entwicklung
• Laufender Betrieb
• Personen und Teams

Bewertung im Hinblick auf Geschäftsprozesse

Das Migrationsteam wird während der anfänglichen Migrationsmaßnahmen Prozesse lernen und entwickeln und wahrscheinlich Fehler machen. Darum sollten die ersten Migrationsmaßnahmen keine geschäftskritischen Systeme umfassen, um Auswirkungen auf den Hauptgeschäftszweig zu vermeiden. Sie sollten jedoch andere häufig genutzte Systeme darstellen, damit das Team eine Lernmöglichkeit hat. Berücksichtigen Sie beim Bewerten der Geschäftsprozesse auch Prozesse, die mit Compliance und Lizenzierung zusammenhängen, und nicht nur die Entwicklungsprozesse.

Bewertung im Hinblick auf Design und Entwicklung

Was Design und Entwicklung angeht, sollten idealerweise die Features als Erstes migriert werden, die die geringste Anzahl von Abhängigkeiten von anderen Features und Daten haben und bei Bedarf am einfachsten refaktoriert werden können.

Sie sollten jedes Features unter Berücksichtigung ihrer Abhängigkeiten und des für die Refaktorierung nötigen Aufwands analysieren. Beachten Sie für die Abhängigkeitsanalyse der einzelnen Features Folgendes:

• Die Art der Abhängigkeit – Abhängigkeiten von Daten oder anderen Features
• Der Umfang der Abhängigkeit – wie viele Features durch eine Änderung bei den Abhängigkeiten dieses Features möglicherweise betroffen sind

Das Migrieren eines Features mit umfassenden Datenabhängigkeiten ist aus den folgenden Gründen in der Regel keine triviale Aufgabe:

• Wenn Sie sich dafür entscheiden, zuerst die Features und erst später die zugehörigen Daten zu migrieren, müssen Sie die nach der ersten Migrationsmaßnahme erhöhte Netzwerklatenz zwischen den Diensterstellern, den Dienstnutzern und den Datenspeichern berücksichtigen.
• Während der Migrationsphase werden sich Herausforderungen in puncto Datenintegrität und Synchronisierung ergeben, da Sie möglicherweise vorübergehend Daten aus mehreren Speicherorten lesen und in mehrere Speicherorte schreiben.

Ein weiteres Bewertungskriterium ist, wie viel Refaktorierungsaufwand jedes Feature erfordert. Wie viel Refaktorierungsaufwand letztlich erforderlich ist, hängt sowohl vom aktuellen Design des Features als auch von ihrer zukünftigen Richtung ab. Berücksichtigen Sie bei der Bewertung, wie sich dieser Aufwand auf die betroffenen Geschäftsprozesse auswirken könnte.

Das sind die wichtigsten Fragen, die Sie im Rahmen dieses Bewertungsprozesses beantworten müssen:

• Welche Daten verwendet dieses Feature?
• Wie viele Daten verwendet dieses Feature?
• Benötigt dieses Feature andere Features, um korrekt zu funktionieren?
• Wie viele andere Features sind von einer Änderung dieses Features betroffen?
• Müssen für dieses Feature Netzwerk- oder Verbindungsanforderungen erfüllt sein?
• Wie wirkt sich das aktuelle Design dieses Feature auf die Refaktorierung aus?

Bewertung im Hinblick auf den laufenden Betrieb

Im Hinblick auf den laufenden Betrieb sollten Sie auch berücksichtigen, für welche Features die Ausfallzeit eines Umstellungsfensters hinnehmbar ist. Wenn Sie die Ausfallzeiten minimieren müssen, kann das Migrieren von Features, die eine hohe Verfügbarkeit erfordern, zusätzlichen Aufwand bedeuten.

Bewertung im Hinblick auf Personen und Teams

Wählen Sie vorzugsweise Teams mit klar definierten Prozessen aus, um die ersten Migrationsmaßnahmen umzusetzen. Darüber hinaus sollten diese Teams bereit sein, den Weg für die Migrationsmaßnahmen zu ebnen, und es sollte ihnen klar sein, dass sie dabei auf Herausforderungen stoßen werden, die sie bewältigen müssen.

Erste Migrationsmaßnahme bestimmen

Gemäß dieser Bewertungskriterien eignet sich für die erste Maßnahme am besten ein Feature, dessen Migration Ihr Team ausreichend fordert, um einen Lerneffekt zu generieren, aber dennoch nicht zu kompliziert ist, damit das Risiko des Scheiterns gering bleibt. Der erste Migrationsprozess sollte außerdem:

• wenig Refaktorierungsaufwand erfordern, sowohl hinsichtlich des Features selbst als auch der betroffenen Geschäftsprozesse.
• zustandslos sein, d. h. keine externen Datenanforderungen haben.
• wenige oder keine Abhängigkeiten haben

Beispiel für einen Migrationsplan

Die folgende Liste zeigt eine mögliche Migrationsreihenfolge:

1. Plattform-Front-End, also die Benutzeroberfläche
2. Zustandslose Features, z. B. ein Währungsumrechnungsdienst
3. Features mit unabhängigen Datasets (ohne Abhängigkeiten von anderen Datasets), z. B. ein Dienst zum Auflisten Ihrer Ladengeschäfte
4. Features mit freigegebenen Datasets, also die Geschäftslogik der E-Commerce-Plattform

Features des Plattform-Front-Ends und zustandslose Features

Features von Plattform-Front-Ends und zustandslose Features haben normalerweise wenige Abhängigkeiten. Beide Arten von Features eignen sich sehr gut für den ersten Schritt der Migrationsmaßnahme, da sie nichttriviale Komponenten der Architektur sind. Sie erfordern nur wenig Refaktorierungsaufwand, da die Back-End API in der Anfangsphase der Migration noch vom Legacy-Rechenzentrum oder der von einem anderen Cloudanbieter gehosteten Laufzeitumgebung bereitgestellt wird.

Konzentrieren Sie sich sowohl bei den Plattform-Front-End-Features als auch bei den zustandslosen Features auf die Pipeline für die Integration und die Bereitstellung. Da Ihre GKE-Arbeitslasten in Container verlagert werden müssen, müssen Sie möglicherweise mehr operative Arbeit verrichten.

Features mit unabhängigen Datasets

Bei den nächsten zu migrierenden Komponenten handelt es sich um Features, deren Datasets von anderen Datasets unabhängig sind. Diese unabhängigen Datasets lassen sich leichter aus Ihrem Legacy-System extrahieren als Datasets mit Abhängigkeiten. Im Vergleich zum Migrieren zustandsloser Features erfordert das Migrieren von Features mit unabhängigen Datasets natürlich zusätzlichen Aufwand, da nicht nur die Daten migriert, sondern auch ein neuer Datenspeicher erstellt und verwaltet werden müssen.

Wenn Sie die Datenmigration planen, können Sie zwischen verschiedenen Speichersystemen wählen. Da Sie Ihre Anwendungen modernisieren möchten, eignen sich folgende Systeme:

• Verwaltete Datenspeicherdienste wie Cloud Storage oder Filestore zum Speichern von Dateien
• Cloud SQL zum Migrieren von Daten aus einem RDBMS
• Firestore zum Migrieren von Daten aus einer NoSQL-Datenbank

Features mit freigegebenen Datasets

Features mit freigegebenen Datasets sind am schwierigsten zu migrieren. Dies liegt daran, dass hier die Migration von Daten aufgrund der Anforderungen hinsichtlich Konsistenz, Verteilung, Zugriff und Latenzzeit eine schwierige Aufgabe darstellt. Dies wird später noch ausführlicher beschrieben.

Strategien zur Datenmigration

Weitere Informationen zu Ansätzen zur Datenmigration finden Sie unter Ansätze zur Datenmigration.

Best Practices für Mikrodienste

Die folgenden Abschnitte enthalten eine Reihe von Best Practices, an die Sie sich beim Entwerfen, Schreiben und Bereitstellen von Mikrodiensten halten sollten.

Mikrodienste entwerfen

Folgen Sie beim Entwurf der Mikrodienste einem Designmuster, mit dem Sie den Kontext und die Grenze für jeden Mikrodienst korrekt ermitteln können. Dadurch wird eine unnötige Fragmentierung Ihrer Mikrodienstarbeitslasten verhindert. Außerdem können Sie damit einen genauen Kontext (oder eine Domain) definieren, in dem bzw. der die Mikrodienste gültig sind. Ein Beispiel für ein solches Designmuster ist DDD (Domain-driven Design).

API-Verträge

Jeder Mikrodienst sollte nur von einer Reihe von Schnittstellen aus aufgerufen werden. Jede Schnittstelle sollte wiederum klar durch einen Vertrag definiert werden, der mithilfe einer API-Definitionssprache wie der Spezifikation der OpenAPI-Initiative (zuvor Swagger bzw. RAML) implementiert werden kann. Wenn Sie klar definierte API-Verträge und -Schnittstellen haben, können Sie für diese API-Schnittstellen Tests als Hauptkomponente Ihrer Lösung entwickeln, z. B. durch Einsetzen der testbasierten Entwicklung.

Änderungen verwalten

Wenn Sie an Ihren API-Verträgen funktionsgefährdende Änderungen vornehmen müssen, sollten Sie den Refaktorierungsaufwand durch rechtzeitige Vorbereitungen gering halten, der erforderlich ist, damit Clients die Änderungen bewältigen können. Sie können die Thematik auf zwei Arten angehen:

• Versionsverwaltung
• Neuen Mikrodienst implementieren

Versionsverwaltung

Damit Sie bei der Verwaltung von Updates, von denen die Funktion vorhandener Clients möglicherweise gefährdet wird, flexibler sind, sollten Sie ein Versionsverwaltungsschema für Ihre Mikrodienste implementieren. Mit der Versionsverwaltung können Sie aktualisierte Versionen eines Mikrodients bereitstellen, ohne dass dies Auswirkungen auf die Clients hat, die dessen vorhandene Version verwenden. Wenn Sie die Versionsverwaltung verwenden, müssen Sie bei jeder vorgenommenen Änderung, mit der gegen einen Teil eines vorhandenen Vertrags verstoßen wird, eine neue Version erstellen, selbst wenn die Änderung minimal ist.

Sie können ein Versionsverwaltungsschema mithilfe der folgenden Schemas implementieren:

• Globale Versionsverwaltung
• Ressourcenversionsverwaltung

Wenn Sie ein globales Versionsverwaltungschema implementieren, wird impliziert, dass Sie die Versionsverwaltung für die gesamte API einführen. Eine mögliche Implementierung besteht darin, die Versionsinformationen so in die Ressourcen-URIs einzubinden:

/api/v1/entities or api.v3.domain.tld/entities

Diese Art von Versionsverwaltungsschema ist einfach bereitzustellen, da die Versionsverwaltung an einem Ort vorgenommen wird. Sie ist jedoch nicht so flexibel wie ein Schema für die Ressourcenversionsverwaltung. Wenn Sie sich ein Beispiel für ein globales Versionsverwaltungsschema ansehen möchten, bietet sich das Kubernetes API-Versionsverwaltungsschema an.

Mit einem Versionsverwaltungsschema für Ressourcen können Sie die Versionen jeder von Ihrem Mikrodienst bereitgestellten Ressource einzeln verwalten. Für maximale Flexibilität können Sie die Versionen für eine Ressource sogar entsprechend dem Vorgang an dieser (beispielsweise dem HTTP-Verb) verwalten. Sie können dieses Versionsverwaltungsschema auf verschiedene Arten implementieren. Sie können dazu URIs oder benutzerdefinierte oder standardmäßige HTTP-Anfrageheader verwenden, wie im folgenden Beispiel:

Accept: application/tld.domain.entities.v2+json

Ein Versionsverwaltungsschema für Ressourcen kann schwieriger zu entwerfen sein als ein globales Versionsverwaltungsschema, da für alle Ihre Entitäten ein allgemeiner Ansatz erforderlich ist. Es bietet jedoch höhere Flexibilität, da Sie verschiedene und voneinander unabhängige Upgraderichtlinien für die Ressourcen implementieren können.

Neuen Mikrodienst implementieren

Ein weiterer Ansatz für den Umgang mit funktionsgefährdenden Änderungen ist das Implementieren eines neuen Mikrodiensts, für den ein neuer Vertrag vorliegt. Dies bietet sich an, wenn die neue Version eines Mikrodiensts so viele Änderungen erfordert, dass es sinnvoller ist, eine neue Version zu schreiben, als die vorhandene zu aktualisieren. Obwohl dieser Ansatz die größtmögliche Flexibilität bietet, birgt er auch die Gefahr, dass sich die Funktionen und Verträge von Mikrodiensten überschneiden. Nachdem Sie den neuen Mikrodienst implementiert haben, können Sie die Clients schrittweise so refaktorieren, dass sie diesen verwenden, und können eine Migration vom vorherigen Mikrodienst vornehmen.

Nächste Schritte

• Informationen zu GKE Enterprise
• Jetzt mit GKE starten
• Muster für das skalierbare Deployment von Kubernetes APIs mit Apigee
• Produktionsvorbereitung für den Black Friday
• Daten zwischen Cloud SQL und externen Servern migrieren
• Unsere Einzelhandelslösungen ansehen
• Referenzarchitekturen, Diagramme und Best Practices zu Google Cloud kennenlernen. Weitere Informationen zu Cloud Architecture Center