Migrer vers des microservices à partir d'une application monolithique
Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
Pour démarrer avec une ancienne application monolithique, vous devez identifier les parties pouvant être dissociées et transférées vers des microservices distincts. Une application monolithique bien structurée présente généralement des divisions très naturelles. Une classe de service fonctionne déjà comme une interface vers une couche de stockage de données et de logique métier.
Elle représente la solution idéale pour connecter les appels de clients au microservice.
Séparer les fonctionnalités d'une application monolithique
Vous pouvez adopter plusieurs approches pour séparer les fonctionnalités de votre application :
- Rechercher dans votre application une logique métier pouvant être séparée.
- Identifier le code isolé naturellement, par exemple en utilisant des outils d'analyse de code statique permettant d'identifier les sections.
- Examiner votre application afin de déceler une logique vous permettant de définir des paramètres de configuration du scaling ou des besoins en mémoire distincts de ceux du reste de l'application. Vous pourrez ainsi éventuellement réduire les coûts, ce qui peut contribuer à une meilleure utilisation des ressources.
Vous aurez peut-être besoin de refactoriser votre code pour supprimer les dépendances non naturelles. Nous vous recommandons de refactoriser l'ancien code et de le déployer en production avant de diviser l'application en services distincts.
Les microservices sont le plus souvent employés dans les domaines suivants :
- Informations de compte ou d'utilisateur
- Gestion des autorisations et des sessions
- Préférences ou paramètres de configuration
- Notifications et services de communication
- Photos et contenus multimédias, en particulier les métadonnées
- Nœuds de file d'attente de tâches
Étapes de la migration d'une application
Voici les étapes à suivre après avoir identifié un ensemble de classes pouvant devenir un microservice :
- Le code existant doit être conservé et opérationnel dans l'ancienne application de façon à faciliter le rollback.
- Créez un dépôt de code ou au moins un sous-répertoire dans le dépôt existant.
- Copiez les classes dans le nouvel emplacement.
- Créez une couche d'affichage qui fournit les hooks d'API HTTP et met en forme les documents de réponse de manière appropriée.
- Formulez le nouveau code sous la forme d'une application distincte (créer un
app.yaml).
- Déployez votre nouveau microservice en tant que service ou projet séparé.
- Testez le code pour vous assurer qu'il fonctionne correctement.
- Effectuez la migration des données de l'ancienne application vers le nouveau microservice (reportez-vous à la section ci-après pour en savoir plus).
- Modifiez l'ancienne application afin d'utiliser la nouvelle application de microservices.
- Déployez l'ancienne application modifiée.
- Vérifiez que tout fonctionne comme prévu et qu'il n'est pas nécessaire de rétablir l'ancienne application.
- Supprimez tout le code mort de l'ancienne application.
Migrer les données d'une application en live
La migration des données d'une application en live peut s'avérer délicate et dépend fortement de votre situation. Pour faciliter le déploiement et le rollback, il convient généralement d'écrire du code qui est inséré à la fois dans les anciennes et les nouvelles entités Cloud Datastore, éventuellement à l'aide d'une API temporaire sur le microservice. Il faut ensuite créer du code qui migre l'ensemble de données existant, par exemple dans le cadre d'une opération MapReduce. Ce processus implique généralement l'utilisation de code temporaire et de données redondantes. En fonction de votre situation, vous devrez peut-être également exécuter une migration de données de rattrapage après le lancement. Veillez à ne pas écraser les données récentes avec les données anciennes.
Même si ces tâches semblent nécessiter beaucoup de travail, elles sont courantes. Il faut pouvoir procéder au déploiement et au rollback dans le cas où la transition vers le nouveau microservice échoue. Vous ne pouvez vous débarrasser du code temporaire et supprimer les données de l'ancien emplacement de stockage qu'après avoir vérifié que tous les éléments ont été migrés correctement et que tout fonctionne comme prévu. Veillez à effectuer des sauvegardes tout au long du processus.
Étapes suivantes
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/09/04 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Difficile à comprendre","hardToUnderstand","thumb-down"],["Informations ou exemple de code incorrects","incorrectInformationOrSampleCode","thumb-down"],["Il n'y a pas l'information/les exemples dont j'ai besoin","missingTheInformationSamplesINeed","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 2025/09/04 (UTC)."],[[["\u003cp\u003eIdentifying well-structured service classes within a monolithic application is the ideal starting point for transitioning to microservices, as they often naturally interface with data storage and business logic.\u003c/p\u003e\n"],["\u003cp\u003eSeparating a monolithic application into microservices involves analyzing business logic, isolating code, and considering scaling needs, with refactoring recommended before the separation.\u003c/p\u003e\n"],["\u003cp\u003eCommon areas suitable for microservices include user information, authorization, settings, notifications, media, and task queues.\u003c/p\u003e\n"],["\u003cp\u003eMigrating to a microservice involves creating a new repository, copying classes, building an HTTP API layer, deploying as a separate app, testing, migrating data, and updating the legacy app.\u003c/p\u003e\n"],["\u003cp\u003eData migration in live applications often requires populating both old and new storage systems to ensure seamless roll-forward and rollback, involving temporary code and redundant data.\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/python/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/python/creating-separate-dev-environments).\n- Learn the [best practices for designing APIs to communicate between microservices](/appengine/docs/legacy/standard/python/designing-microservice-api).\n- Learn the [best practices for microservice performance](/appengine/docs/legacy/standard/python/microservice-performance)."]]
