In diesem Dokument wird eine Architektur gezeigt, die ein Istio-Service-Mesh verwendet, um eine Migration von einer Legacy-Umgebung, wie einem lokalen Rechenzentrum, in dem Anwendungen auf virtuellen Maschinen ausgeführt werden, zu Google Kubernetes Engine (GKE) durchzuführen. Die Verwendung eines Service Mesh kann die Komplexität der Migration und der Refaktorierung reduzieren, da es Netzwerkfunktionen von Dienstfunktionen entkoppelt.
In diesem Dokument werden die Grundprinzipien und grundlegenden Phasen der Migration erläutert. Sie können diese Architektur verwenden, um eine Migration in einem einzigen Vorgang (manchmal auch als Big-Bang-Migration bezeichnet) oder eine graduelle Feature-für-Feature-Migration durchzuführen. Das zugehörige Bereitstellungsdokument führt Sie durch eine Beispielmigration.
Diese Architektur und ihr Bereitstellungsleitfaden richten sich an IT-Fachleute, die eine komplexe Infrastruktur verwalten, die sie schrittweise migrieren und modernisieren möchten, wobei sie gleichzeitig Folgendes minimieren:
- Ausfallzeiten
- Refaktorierungsaufwand
- Operative Komplexität des eigenen Netzwerks
Die erläuterten Konzepte gelten für jede beliebige Cloud. Es wird daher davon ausgegangen, dass Sie mit Cloud-Technologien, Containern und Mikrodiensten vertraut sind.
Wie unter Zu Google Cloud migrieren: Erste Schritte beschrieben, gibt es mehrere Muster für die Migration in die Cloud. Die Architektur in diesem Dokument verwendet ein Refaktorierungsmuster (manchmal auch Move-and-Improve genannt), bei dem das Muster auf jedes Feature der Anwendung statt auf die Anwendung als Ganzes angewendet wird.
Während der Migration hat die Anwendung eine Hybridarchitektur, bei der sich einige Features in Google Cloud und andere noch in der Legacy-Umgebung befinden. Nach abgeschlossener Migration wird die gesamte Anwendung in Google Cloud gehostet.
Architektur
Das folgende Diagramm zeigt, wie Sie ein Service Mesh verwenden können, um Traffic entweder an Mikrodienste in der Quellumgebung oder an Google Cloud weiterzuleiten:
Die Architektur umfasst die folgenden Komponenten:
Eine Quellumgebung, in diesem Fall eine Compute Engine-Instanz, die die zu migrierende Beispielarbeitslast hostet. Die Quellumgebung kann auch lokal oder auf anderen Cloud-Plattformen gehostet werden.
Ein Service Mesh, in diesem Fall Istio Gateway, das verschiedene Dienste miteinander verknüpft. Das Service Mesh bietet wichtige Netzwerkfeatures wie Diensterkennung, sichere Kommunikation, Load Balancing, Traffic-Verwaltung und Beobachtbarkeit.
Bei einer typischen Implementierung eines Service Mesh werden die einzelnen Dienste mit einem Proxy gekoppelt, der diese Features bereitstellt. Der Dienstproxy wird meist als Sidecar bezeichnet. Die Rolle des Sidecars besteht darin, die mit ihm verknüpfte Anwendung zu erweitern und zu verbessern, oft ohne sich der Anwendung bewusst zu sein. Im zugehörigen Bereitstellungsleitfaden verwenden Sie Envoy als Sidecar-Proxy.
Eine Arbeitslast, die eine aus Mikrodiensten bestehende Anwendung enthält. Ein Mikrodienst ist eine eigenständige Komponente, die für die Implementierung eines Anwendungsfeatures entwickelt wurde. In dieser Architektur besteht die Anwendung aus verschiedenen Mikrodiensten, die für Nutzer nicht zu unterscheiden sind. Beispielsweise ist eine Komponente, die Buchrezensionen verarbeitet, ein Mikrodienst.
Anwendungen, die in Form von Mikrodiensten entwickelt wurden, bestehen aus mehreren Mikrodiensten, die jeweils einem bestimmten Zweck dienen. Zum Beispiel könnte ein Mikrodienst für Buchbewertungen zuständig sein und ein anderer für Buchrezensionen. 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 (wie in mehrsprachigen Anwendungen) und unterschiedliche Lebenszyklen haben.
Ein Container, der die Grenzen der einzelnen Mikrodienste weiter definiert. Da die Zielumgebung in dieser Architektur mit Kubernetes orchestriert wird, empfehlen wir Ihnen, die Mikrodienste mit den folgenden Tools zu containerisieren:
- Docker ist ein Tool, mit dem sich Programme im Userspace auf Betriebssystemebene isolieren lassen. Das Tool führt Pakete aus, die als Container bezeichnet werden.
- Kubernetes ist die führende Orchestrierungslösung für containerisierte Arbeitslasten. Es bietet Features wie Service Discovery, Load Balancing, Pods und Knoten mit Selbstreparatur sowie Verwaltung von Secrets und Konfigurationen.
- GKE ist eine verwaltete, produktionsbereite Kubernetes-Umgebung, die Teil von Google Cloud ist.
Informationen zum Containerisieren dieser Mikrodienste finden Sie unter Best Practices für die Containererstellung und Best Practices für den Betrieb von Containern.
Für eine Migration mit einem Service Mesh durchlaufen Sie die folgenden Phasen:
- Legacy-Umgebung bewerten: Erfassen Sie Informationen und legen Sie eine Reihe von Anforderungen für die Zielumgebung und eine Referenz für Tests und Validierung fest.
- Grundlage in der Zielumgebung erstellen: Stellen Sie Ihre Zielumgebung bereit und wenden Sie eine Infrastruktur-als-Code-Methode an, damit Ihre Infrastruktur prüfbar, wiederholbar und automatisch bereitgestellbar ist.
- Dienste bereitstellen und Traffic an die Zielumgebung weiterleiten: Führen Sie einen einzelnen Vorgang aus, um alle Mikrodienstinstanzen gleichzeitig bereitzustellen, oder führen Sie eine schrittweise Bereitstellung aus, um die Mikrodienste einzeln bereitzustellen.
- Weiterleitung des Traffics zur Legacy-Umgebung beenden: Richten Sie die Weiterleitungsregeln ein, um den Traffic nur an Dienste weiterzuleiten, die in der Zielumgebung ausgeführt werden.
- Legacy-Umgebung deaktivieren: Aktualisieren Sie Ihre DNS-Einträge so, dass sie auf den Load Balancer verweisen, den Sie in der Bereitstellungsphase der Zielumgebung eingerichtet haben.
In diesem Dokument werden einige Designaspekte für diesen Migrationstyp beschrieben. Der zugehörige Bereitstellungsleitfaden enthält detaillierte Schritte zum Abschließen der Migration.
Überlegungen zum Design
Dieser Abschnitt enthält eine Anleitung zum Entwickeln einer Architektur, die Ihren spezifischen Anforderungen an Zuverlässigkeit, operative Effizienz, Kosten und Leistungsoptimierung entspricht.
Zuverlässigkeit
In den folgenden Abschnitten werden Überlegungen zur Zuverlässigkeit Ihrer Migration beschrieben.
Schrittweise Migrationsstrategie verwenden
Diese Architektur kann zwar für eine Migration in einem einzigen Vorgang verwendet werden, wir empfehlen jedoch eine graduelle Migrationsstrategie. Die Migration in einem einzigen Vorgang kann aufgrund der Herausforderungen und Risiken, die bei der Migration einer oder mehrerer Anwendungen gleichzeitig bestehen, schwierig sein. Wenn Zeit und Budget knapp bemessen sind und Sie sich ganz auf eine Migration in einem einzigen Vorgang konzentrieren, bleibt nicht viel Kapazität, um an neuen Anwendungsfeatures zu arbeiten.
Im Gegensatz dazu ist die Komplexität einer graduellen Feature-für-Feature-Migration insgesamt geringer, da die jeweils zu migrierende Arbeitslast kleiner ist: Ein einzelnes Feature ist im Vergleich zu einer kompletten Anwendung schlanker strukturiert. Bei einer graduellen Migration lässt sich das Risiko auf kleinere Migrationsereignisse verteilen, sodass es nicht auf einem einzigen risikobehafteten Vorgang lastet. Außerdem kann das Migrationsteam bei einer graduellen Migration mehrere Migrationsstrategien planen, entwerfen und entwickeln, um unterschiedlichen Arten von Features Rechnung zu tragen.
Informationen dazu, welche Features zuerst migriert werden sollten und wie zustandsorientierte Features zu migrieren sind, finden Sie unter Anwendungen auswählen, die zuerst migriert werden sollen in „Zu Google Cloud migrieren: Arbeitslasten bewerten und erkennen“.
Compliance-Testsuite verwenden
Wir empfehlen Ihnen die Verwendung einer Compliance-Testsuite, um die Migration zu erleichtern. Eine Compliance-Testsuite besteht aus einer Reihe von Tests, die Sie für eine Umgebung ausführen können. So lässt sich überprüfen, ob die Umgebung bestimmten Anforderungen genügt. Wenn die Umgebung gültig ist, erfüllt sie die Anforderungen. Beispielsweise lässt sich validieren, ob die Antwort auf eine Testanfrage korrekt ist oder die Abhängigkeiten der Anwendung installiert sind.
Sie können zuerst eine manuelle Validierung mit Monitoring-, Tracing- und Service-Mesh-Visualisierungstools ausführen. Anschließend können Sie die Testsuite so implementieren und im Laufe der Zeit so weiterentwickeln:
- Lasttest: Zum Weiterentwickeln der Testsuite können Sie automatisch Test-Traffic an die Umgebung senden und die Ergebnisse auswerten.
- Compliance-Testtool: Sie können eine Testsuite mit einem dedizierten Tool entwerfen und entwickeln.
Führen Sie die Compliance-Testsuite für die Legacy-Umgebung aus, um eine Referenz zu haben. Anschließend führen Sie die Suite auch für die Zielumgebung aus, und zwar während und nach der Migration.
Zur Validierung während der Migration sollte der Schwerpunkt Ihrer Testsuite auf folgenden Aspekten liegen:
- Bereitstellung: Stellen Sie die in Ihrer Umgebung benötigten Ressourcen bereit, bevor Sie sie konfigurieren.
- Konfiguration: Nachdem Sie Ressourcen in der Umgebung bereitgestellt haben, konfigurieren Sie sie entsprechend den Anforderungen Ihrer Anwendung. Mit einer Konfigurations-Testsuite können Sie gewährleisten, dass die Umgebung zum Hosten Ihrer Anwendung bereit ist.
- Geschäftslogik: Nachdem Sie die Bereitstellung und die Konfiguration der Umgebung validiert haben, validieren Sie die Geschäftslogik Ihrer Anwendung. Beispielsweise können Sie die Antworten auf Anfragen validieren.
Chef InSpec, RSpec und Serverspec sind Tools zum Entwickeln automatisierter Compliance-Testsuites. Sie funktionieren auf jeder Plattform und sind erweiterbar, sodass Sie die integrierten Kontrollen um Ihre eigenen ergänzen können.
Wenn Sie die Zielumgebung bereitstellen, können Sie sie mit der Compliance-Testsuite validieren. Möglicherweise müssen Sie die Testsuite aktualisieren, um eventuelle Unterschiede zwischen der Legacy- und der Zielumgebung, z. B. in Bezug auf Hardware und Netzwerktopologie, zu berücksichtigen. Bedenken Sie, dass die Umstellung von einer lokalen Umgebung, in der Sie die volle Kontrolle haben, auf eine öffentliche Cloud-Umgebung erfolgt, in der Sie normalerweise keinen Vollzugriff auf den gesamten Stack haben.
Bevor Sie Traffic von der Load-Balancing-Ebene der Legacy-Umgebung an die Zielumgebung weiterleiten, sollten Sie die für die Geschäftslogik vorgesehene Compliance-Testsuite für die Mikrodienste ausführen, die in der Zielumgebung verfügbar gemacht werden. Die Testsuite kann dafür sorgen, dass die Mikrodienste wie erwartet funktionieren. Beispielsweise können Sie die Antworten validieren, die von Diensten zurückgegeben werden, die das Service Mesh bereitstellt. Sie können die ursprüngliche Route als Sicherungsoption beibehalten, falls Sie die Änderungen rückgängig machen und zur Legacy-Umgebung zurückkehren müssen. Wenn Sie einen kleinen Teil des Produktions-Traffics an Instanzen der Mikrodienste weiterleiten, die in der Zielumgebung ausgeführt werden, können Sie Vertrauen in die Zielumgebung aufbauen und den Traffic im Laufe der Zeit erhöhen.
Umgebungsübergreifende Anfragen nicht zulassen
Während der Compliance-Testphase sollten Sie die Weiterleitungsregeln so optimieren, dass umgebungsübergreifende Anfragen nicht zugelassen werden. Wenn also eine Clientanfrage in einer Umgebung (Legacy- oder Zielumgebung) eingeht, verbleibt sie in dieser Umgebung. Durch das Ablehnen umgebungsübergreifender Anfragen wird sichergestellt, dass Tests die Zielumgebung richtig validieren. Wenn Sie diese Anfragen zulassen, meldet ein Test möglicherweise ohne Ihre Kenntnis den Erfolg in der Quellumgebung statt in der Zielumgebung.
Legacy-Umgebung deaktivieren
Bevor Sie die Legacy-Umgebung deaktivieren, prüfen Sie, ob alle folgenden Bedingungen erfüllt sind:
- Es wird kein Traffic an Mikrodienstinstanzen weitergeleitet, die in der Legacy-Umgebung ausgeführt werden.
- Über die Schnittstellen der Legacy-Umgebung geht kein Traffic ein.
- Die Zielumgebung wurde vollständig validiert.
Wenn diese Bedingungen erfüllt sind, können Sie Ihre DNS-Einträge so aktualisieren, dass sie auf den Load-Balancer verweisen, den Sie in der Bereitstellungsphase der Zielumgebung eingerichtet haben. Deaktivieren Sie die Legacy-Umgebung nur, wenn Sie sich sicher sind, dass die Zielumgebung validiert wurde. Beschränken Sie die Validierung nicht nur auf die Geschäftslogik, sondern berücksichtigen Sie auch andere nicht funktionale Anforderungen wie Leistung und Skalierbarkeit.
Operative Effizienz
In den folgenden Abschnitten werden Überlegungen zur operativen Effizienz der Migration beschrieben.
Legacy-Umgebung bewerten
Bevor Sie einen Migrationsplan entwerfen oder implementieren, sollten Sie die Legacy-Umgebung bewerten, um Informationen zu erfassen und eine Reihe von Anforderungen für die Zielumgebung sowie eine Referenz für Tests und Validierung festzulegen. Zuerst erstellen Sie einen Katalog mit allen zu migrierenden Anwendungsfeatures. Für jedes Feature sollten Sie die Fragen in der folgenden (unvollständigen) Liste beantworten können:
- Welche Anforderungen werden an die Laufzeitumgebung und Leistung gestellt?
- Gibt es Abhängigkeiten von anderen Features?
- Ist dieses Feature geschäftskritisch?
- Ist dieses Feature zustandslos oder zustandsorientiert?
- Wie groß ist der voraussichtliche Refaktorierungsaufwand für dessen Migration?
- Ist ein Umstellungsfenster für dieses Feature tragbar?
Weitere Informationen finden Sie unter Zu Google Cloud migrieren: Arbeitslasten bewerten und erkennen.
Zustandslose Ressourcen im Vergleich zu zustandsorientierten Ressourcen
Die Architektur verwendet ein Service Mesh, da sie Dienstfunktionen (d. h. die Implementierung der Geschäftslogik) von Netzwerkfunktionen (wie und wann Traffic an Dienstfunktionen weitergeleitet werden muss) entkoppelt. In der zugehörigen Bereitstellung verwenden Sie Istio als Service Mesh.
In der Legacy-Umgebung ist das Netzwerk an den meisten Dienstaufrufen nicht beteiligt, da diese auf einer monolithischen Plattform ausgeführt werden. In einer Microdienstarchitektur erfolgt die Kommunikation zwischen Diensten über ein Netzwerk und Dienste müssen dieses andere Modell verarbeiten. Ein Service Mesh übernimmt die Funktionen zur Verarbeitung der Netzwerkkommunikation, sodass Sie diese nicht in jeder Anwendung implementieren müssen. Außerdem reduziert ein Service Mesh die operative Komplexität des Netzwerks, da es Features für sichere Kommunikationskanäle, Load Balancing, Traffic-Verwaltung und Beobachtbarkeit bietet, die keine Konfiguration erfordern.
Durch die Bereitstellung und Konfiguration eines Service Mesh können Sie Traffic entweder an die Legacy-Umgebung oder die Zielumgebung dynamisch weiterleiten. Sie brauchen die Konfiguration der Anwendung für Ihre Migration nicht zu ändern, da die Dienste im Mesh von der Trafficverwaltung unberührt bleiben.
Dieser Ansatz eignet sich gut für zustandslose Features. Die Migration von Features, die zustandsorientiert, latenzempfindlich oder mit anderen Features stark gekoppelt sind, erfordert jedoch zusätzliche Planung und Refaktorierung:
- Zustandsorientiert: Wenn Sie zustandsorientierte Features migrieren, müssen Sie auch Daten migrieren, um Ausfallzeiten zu minimieren und Synchronisierungs- und Integritätsprobleme während der Migration zu mindern. Weitere Informationen zu Datenmigrationsstrategien finden Sie im Abschnitt Ansätze zur Datenmigration bewerten von "Migration zu Google Cloud: Große Datasets übertragen".
- Latenzempfindlich: Wenn ein Feature bei der Kommunikation mit anderen Features latenzempfindlich ist, müssen Sie während des Migrationsprozesses unter Umständen zusätzliche Komponenten bereitstellen. Zur Verringerung dieser Empfindlichkeit werden häufig Proxys, die Daten vorab abrufen, oder Caching-Ebenen verwendet.
- Stark mit anderen Features gekoppelt: Wenn zwei oder mehr Features stark miteinander gekoppelt sind, müssen Sie sie möglicherweise gleichzeitig migrieren. Dieser Ansatz ist zwar einfacher als die Migration einer ganzen Anwendung, eventuell aber schwieriger als die Migration eines einzelnen Features.
Dienste beim Service Mesh registrieren
Da Ihre Legacy-Umgebung nicht direkt in das Service Mesh eingebunden ist, müssen Sie beim Konfigurieren der Migration alle Dienste, die in der Legacy-Umgebung ausgeführt werden, manuell beim Service Mesh registrieren. Wenn Ihre Umgebung bereits in Kubernetes ausgeführt wird, können Sie die Registrierung mithilfe der integrierten Einbindung in die Service Mesh APIs automatisieren.
Nachdem Sie die Legacy-Umgebung registriert haben, verwenden Sie das Service Mesh, um die Mikrodienste verfügbar zu machen, die in der Legacy-Umgebung ausgeführt werden. Anschließend können Sie den Traffic an Mikrodienste schrittweise von den Schnittstellen der Legacy-Umgebung zu die Schnittstellen der Zielumgebung weiterleiten.
Clients nehmen keine Dienstunterbrechung wahr, da sie über eine Load-Balancing-Schicht auf die Schnittstellen der beiden Umgebungen zugreifen. Die Traffic-Weiterleitung innerhalb des Service Mesh ist für Clients transparent, sodass Clients nicht wissen, dass die Weiterleitungskonfiguration geändert wurde.
Kostenoptimierung
In dieser Architektur werden die folgenden kostenpflichtigen Komponenten von Google Cloud verwendet:
Wenn Sie die Architektur bereitstellen, können Sie mit dem Preisrechner eine Kostenschätzung für Ihre voraussichtliche Nutzung erstellen.
Leistungsoptimierung
In dieser Architektur wird der Traffic nahezu gleichmäßig auf die in Compute Engine ausgeführten Dienste und die in GKE ausgeführten Dienste aufgeteilt. Das Service Mesh verteilt den Traffic zwischen den Instanzen eines ausgewählten Dienstes, unabhängig davon, ob sie im GKE-Cluster oder in den Compute Engine-Instanzen ausgeführt werden. Wenn der gesamte Traffic über das Service Mesh geleitet werden soll, müssen Sie die in Compute Engine ausgeführten Arbeitslasten so neu konfigurieren, dass sie auf die Dienste im Service Mesh verweisen, statt direkt eine Verbindung zu ihnen herzustellen. Sie können die Load-Balancing-Richtlinie für die Überarbeitungen der einzelnen Dienste mit der DestinationRule-Ressource konfigurieren.
Bereitstellung
Informationen zum Bereitstellen dieser Architektur finden Sie unter Migration mit Istio-Mesh-Netzwerkerweiterung bereitstellen.
Nächste Schritte
- Informationen über GKE
- Mehr über Istio erfahren
- Weitere Referenzarchitekturen, Diagramme und Best Practices finden Sie im Cloud-Architekturcenter.