Von einer monolithischen Anwendung auf Mikrodienste migrieren
Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
Wenn Sie von einer monolithischen Legacy-Anwendung ausgehen, müssen Sie Komponenten finden, die sich isolieren und in separate Mikrodienste verschieben lassen. Eine gut strukturierte monolithische Anwendung zeichnet sich in der Regel bereits durch eine gewisse Unterteilung aus. Außerdem sollte sie eine Dienstklasse haben, die als Schnittstelle für eine Datenspeicherebene und als Geschäftslogik fungiert.
Diese Klassen sind ideal geeignet, um Clientaufrufe mit dem Mikrodienst zu verbinden.
Funktionalität in einer monolithischen Anwendung trennen
Es gibt verschiedene Methoden, um Ihre Anwendung zu unterteilen:
- Sie suchen in der Anwendung nach einer Geschäftslogik, die ausgegliedert werden kann.
- Sie suchen nach Code, der schon isoliert ist, z. B. mithilfe statischer Codeanalysetools, um die einzelnen Abschnitte zu identifizieren.
- Sie durchsuchen die Anwendung nach Logik, die anders als der Rest der Anwendung von anderen Skalierungseinstellungen oder Speicheranforderungen profitieren könnte. Das könnte zu Kosteneinsparungen und einer besseren Ressourcennutzung führen.
Möglicherweise müssen Sie den Code refaktorieren, um künstliche Abhängigkeiten zu entfernen. Wir empfehlen, eine Refaktorierung innerhalb des Legacy-Codes durchzuführen und diesen in der Produktion zu implementieren, bevor Sie versuchen, die Anwendung in separate Dienste zu unterteilen.
Typische Anwendungsbereiche für Mikrodienste:
- Nutzer- oder Kontoinformationen
- Autorisierung und Sitzungsverwaltung
- Einstellungen oder Konfigurationseinstellungen
- Benachrichtigungs- und Kommunikationsdienste
- Fotos und Medien, insbesondere Metadaten
- Aufgabenwarteschlangen-Worker
Schritte zum Migrieren einer Anwendung
Nachdem Sie einige Klassen ermittelt haben, die sich als Mikrodienst eignen würden, sind folgende Schritte erforderlich:
- Den bestehenden Code funktionsfähig an Ort und Stelle in der alten Anwendung belassen, um ein späteres Rollback zu ermöglichen.
- Ein neues Code-Repository oder zumindest ein Unterverzeichnis im bestehenden Repository erstellen.
- Die Klassen an den neuen Speicherort kopieren.
- Eine Ansichtsebene programmieren, die HTTP API-Hooks bereitstellt und die Antwortdokumente ordnungsgemäß formatiert.
- Den neuen Code für die separate Anwendung schreiben (
app.yaml-Datei erstellen).
- Den neuen Mikrodienst als Dienst oder eigenes Projekt bereitstellen
- Den Code auf korrekte Funktion testen
- Die Daten aus der Legacy-Anwendung zum neuen Mikrodienst migrieren. Weitere Informationen finden Sie weiter unten.
- Die Legacy-Anwendung so abändern, dass der neue Mikrodienst verwendet wird.
- Die geänderte Legacy-Anwendung bereitstellen.
- Die korrekte Funktionsweise der Anwendung überprüfen, um ein späteres Rollback auf die Legacy-Anwendung auszuschließen.
- Nicht mehr benötigten Code aus der Legacy-Anwendung entfernen.
Daten in eine Live-Anwendung migrieren
Daten in eine Live-Anwendung zu migrieren, kann schwierig sein und hängt stark von der Situation ab. Um Rollforward- und Rollback-Prozesse zu vereinfachen, benötigen Sie meistens Code, der sowohl die alten als auch die neuen Cloud Datastore-Entitäten ausfüllt. Dazu müssen Sie möglicherweise eine temporäre API für den Mikrodienst verwenden und anschließend Code schreiben, der die vorhandenen Daten migriert, zum Beispiel als MapReduce. Dieser Prozess beinhaltet in der Regel eine gewisse Menge an temporärem Code und redundanten Daten. Je nach Situation müssen Sie nach der Veröffentlichung auch die Datenmigration noch einmal wiederholen. Achten Sie dabei darauf, neuere Daten nicht mit älteren zu überschreiben.
Das Prozedere ist zwar aufwendig, aber erforderlich, um ein reibungsloses Rollforward bzw. Rollback zu ermöglichen, falls der neue Mikrodienst nicht wie erwartet funktionieren sollte. Wenn Sie überprüft haben, dass die Migration ordnungsgemäß verlaufen ist und der Mikrodienst wie erwartet funktioniert, können Sie den temporären Code entfernen und die Daten am alten Speicherort löschen. Legen Sie während der Migration unbedingt Sicherungen an.
Weitere Informationen
Sofern nicht anders angegeben, sind die Inhalte dieser Seite unter der Creative Commons Attribution 4.0 License und Codebeispiele unter der Apache 2.0 License lizenziert. Weitere Informationen finden Sie in den Websiterichtlinien von Google Developers. Java ist eine eingetragene Marke von Oracle und/oder seinen Partnern.
Zuletzt aktualisiert: 2025-09-04 (UTC).
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Schwer verständlich","hardToUnderstand","thumb-down"],["Informationen oder Beispielcode falsch","incorrectInformationOrSampleCode","thumb-down"],["Benötigte Informationen/Beispiele nicht gefunden","missingTheInformationSamplesINeed","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 2025-09-04 (UTC)."],[[["\u003cp\u003eWhen transitioning from a monolithic application to microservices, identify and separate logical business units, naturally isolated code, or parts that require different scaling configurations.\u003c/p\u003e\n"],["\u003cp\u003eRefactor legacy code within the monolithic application and deploy those changes before extracting it into microservices to ensure a smoother transition.\u003c/p\u003e\n"],["\u003cp\u003eCommon microservice candidates include user information, authorization, preferences, notifications, media, and task queue workers.\u003c/p\u003e\n"],["\u003cp\u003eMigrating to microservices involves leaving original code operational, creating new code repositories, formulating a separate application, deploying, testing, migrating data, and updating the legacy app to use the new microservice.\u003c/p\u003e\n"],["\u003cp\u003eData migration for live applications often requires temporarily populating both old and new data stores to facilitate rollback, along with potential catch-up migrations, and ensuring backups are made during the transition.\u003c/p\u003e\n"]]],[],null,["# Migrating to Microservices from a Monolithic App\n\nWhen starting with a legacy, monolithic application, you must find parts that\ncan be carved off and moved to separate microservices. Often, a well-structured\nmonolithic app will have very natural divisions, and a service class will\nalready function as an interface to a layer of data storage and business logic.\nSuch classes are the ideal place to connect the client calls to the\nmicroservice.\n\nSeparating functionality in a monolithic app\n--------------------------------------------\n\nYou could take a couple approaches for how you separate your app:\n\n- Look for business logic in your application that can be separated.\n- Find code that is naturally isolated, such as by using static code analysis tools to identify the sections.\n- Examine your application for logic that you might benefit from different scaling configuration settings or memory requirements than the rest of your application. This could possibly result in cost savings that might lead to better resource utilization.\n\nYou might need to refactor your code to remove unnatural dependencies. We\nrecommend that you perform refactoring within your legacy code and deploy it to\nproduction before attempting to separate the app into separate services.\n\nCommon areas for microservices include the following:\n\n- User or account information\n- Authorization and session management\n- Preferences or configuration settings\n- Notifications and communications services\n- Photos and media, especially metadata\n- Task queue workers\n\nSteps for Migrating an App\n--------------------------\n\nAfter a set of classes has been identified as a candidate to become a\nmicroservice, the next steps include:\n\n- Leaving the existing code in place and operational in the legacy application to facilitate rollback.\n- Creating a new code repository, or at least a sub-directory in your existing repository.\n- Copying the classes into the new location.\n- Writing a view layer that provides the HTTP API hooks and formats the response documents in the correct manner.\n- Formulating the new code as a separate application (create an `app.yaml`).\n- Deploying your new microservice as a service or separate project.\n- Testing the code to ensure that it is functioning correctly.\n- Migrating the data from the legacy app to the new microservice. See below for a discussion.\n- Altering your existing legacy application to use the new microservices application.\n- Deploying the altered legacy application\n- Verifying that everything works as expected and that you don't need to roll back to the legacy application.\n- Removing any dead code from the legacy application.\n\nMigrating data on a live application\n------------------------------------\n\nData migration on a live application can be tricky and highly dependent on your\nsituation. Often, to facilitate roll-forward and rollback, you will need to\nwrite code that populates both the old and new Cloud Datastore entities,\npossibly by using a temporary API on the microservice, and then write code that\nmigrates\nthe existing set of data, for example as a MapReduce. This process will usually\ninvolve some amount of temporary code and redundant data. Depending on the\nspecifics of your situation, you may also need to execute a catch-up data\nmigration after you release. Be careful not to overwrite newer data with older\ndata.\n\nWhile this seems like a lot of work, it's a common occurrence and is important\nto allow for rolling forward and rolling back in the event that the cutover to\nthe new microservice does not succeed. You can remove your temporary code and\ndelete the data from the old storage location only after you have verified that\neverything is migrated correctly and everything is operating as expected. Be\nsure to make backups along the way.\n\nWhat's next\n-----------\n\n- Get an overview of [microservice architecture on App Engine](/appengine/docs/legacy/standard/java/microservices-on-app-engine).\n- Understand how to [create and name dev, test, qa, staging, and production environments with microservices in App Engine](/appengine/docs/legacy/standard/java/creating-separate-dev-environments).\n- Learn the [best practices for designing APIs to communicate between microservices](/appengine/docs/legacy/standard/java/designing-microservice-api).\n- Learn the [best practices for microservice performance](/appengine/docs/legacy/standard/java/microservice-performance)."]]
