Migra a microservicios desde una aplicación monolítica
Organiza tus páginas con colecciones
Guarda y categoriza el contenido según tus preferencias.
Cuando comienzas con una aplicación monolítica heredada, debes encontrar partes que se puedan extraer y mover a microservicios separados. A menudo, una aplicación monolítica bien estructurada tendrá divisiones muy naturales, y una clase de servicio ya funcionará como interfaz para una capa de almacenamiento de datos y lógica empresarial.
Estas clases son el lugar ideal para conectar las llamadas de clientes con el microservicio.
Cómo separar la funcionalidad en una aplicación monolítica
Para separar tu aplicación, puedes adoptar los siguientes enfoques:
- Busca la lógica empresarial de tu aplicación que puede separarse.
- Encuentra un código que esté aislado de manera natural, por ejemplo, mediante herramientas de análisis de código estático para identificar las secciones.
- Examina tu aplicación para encontrar lógica que te pueda favorecer a partir de la configuración de escalamiento o requisitos de memoria distintos a los del resto de tu aplicación. Esto puede reducir costos y generar una mejor utilización de los recursos.
Es posible que debas refactorizar tu código para quitar dependencias no naturales. Recomendamos que realices la refactorización de tu código heredado y lo implementes en producción antes de intentar separar la aplicación en servicios independientes.
A continuación, se detallan las áreas comunes de microservicios:
- Información del usuario o de la cuenta
- Administración de autorización y de sesión
- Preferencias o ajustes de configuración
- Servicios de notificaciones y de comunicaciones
- Fotografías y recursos multimedia, en especial, metadatos
- Trabajadores de la lista de tareas en cola
Pasos para migrar una aplicación
Después de identificar un conjunto de clases como candidato para convertirse en un microservicio, sigue los pasos que se indican a continuación:
- Deja el código existente implementado y operativo en la aplicación heredada para facilitar la reversión.
- Crea un repositorio de código nuevo, o al menos un subdirectorio en tu repositorio existente.
- Copia las clases en la ubicación nueva.
- Escribe una capa de vista que proporcione los hooks de API HTTP y le de formato a los documentos de respuesta de la manera adecuada.
- Formula el código nuevo como una aplicación separada (crea un
app.yaml).
- Implementa tu microservicio nuevo como un servicio o como un proyecto separado.
- Prueba el código para garantizar que funciona correctamente.
- Migra los datos desde la aplicación heredada hacia el microservicio nuevo. Consulta a continuación un debate al respecto.
- Modifica tu aplicación heredada existente para usar la nueva aplicación de microservicios.
- Implementa la aplicación heredada modificada.
- Verifica que todo funcione según lo esperado y que no necesites revertir a la aplicación heredada.
- Quita cualquier código no alcanzado de la aplicación heredada.
Cómo migrar datos en una aplicación activa
La migración de datos en una aplicación activa puede ser complicada y depender mucho de tu situación.
. A menudo, para facilitar el avance y la reversión, tendrás que escribir un código que propague las entidades de Cloud Datastore antiguas y nuevas, quizás mediante una API temporal en el microservicio, y, luego, escribir un código que migre el conjunto de datos existente, como un MapReduce, por ejemplo. Este proceso suele implicar cierta cantidad de código temporal y datos redundantes. Según las características específicas de tu situación, es posible que también tengas que ejecutar una migración de datos compensatoria después de actualizar. Ten cuidado de no reemplazar datos nuevos con datos antiguos.
Aunque esto parece mucho trabajo, es una situación común y es importante permitir el avance y la reversión en caso de que la transición al nuevo microservicio no tenga éxito. Solo puedes quitar tu código temporal y borrar los datos de la ubicación de almacenamiento antigua cuando hayas verificado que todo se haya migrado correctamente y funcione según lo esperado. Asegúrate de hacer copias de seguridad durante el proceso.
¿Qué sigue?
Salvo que se indique lo contrario, el contenido de esta página está sujeto a la licencia Atribución 4.0 de Creative Commons, y los ejemplos de código están sujetos a la licencia Apache 2.0. Para obtener más información, consulta las políticas del sitio de Google Developers. Java es una marca registrada de Oracle o sus afiliados.
Última actualización: 2025-09-04 (UTC)
[[["Fácil de comprender","easyToUnderstand","thumb-up"],["Resolvió mi problema","solvedMyProblem","thumb-up"],["Otro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Información o código de muestra incorrectos","incorrectInformationOrSampleCode","thumb-down"],["Faltan la información o los ejemplos que necesito","missingTheInformationSamplesINeed","thumb-down"],["Problema de traducción","translationIssue","thumb-down"],["Otro","otherDown","thumb-down"]],["Última actualización: 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)."]]
