Como migrar de um aplicativo monolítico para microsserviços
Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
Ao começar com um aplicativo monolítico legado, é preciso encontrar partes que podem ser esculpidas e movidas para microsserviços separados. Muitas vezes, um aplicativo monolítico bem estruturado terá divisões muito naturais, e uma classe de serviço já funcionará como interface para uma camada de armazenamento de dados e lógica de negócios.
Essas classes são o local ideal para conectar as chamadas de cliente ao microsserviço.
Como separar a funcionalidade em um aplicativo monolítico
Você poderia adotar algumas abordagens sobre como separar o aplicativo:
- Procurar uma lógica de negócios no aplicativo que possa ser separada.
- Encontrar um código naturalmente isolado, por exemplo, usando ferramentas de análise de código estático para identificar as seções.
- Examinar o aplicativo em busca de uma lógica que possa proporcionar diferentes configurações de escalonamento ou requisitos de memória. Isso poderia acarretar economia de custos e, consequentemente, uma melhor utilização dos recursos.
Talvez seja necessário refatorar o código para remover dependências não naturais. Recomendamos efetuar a refatoração dentro do código legado e implantá-lo na produção antes de tentar separar o aplicativo em serviços separados.
As áreas comuns de microsserviços incluem:
- informações de usuário ou conta;
- gerenciamento de autorização e sessão;
- preferências ou ajustes de configurações;
- notificações e serviços de comunicações;
- fotos e mídia, especialmente metadados;
- trabalhadores da fila de tarefas.
Etapas para migrar um aplicativo
Depois que um conjunto de classes é identificado como candidato para se tornar um microsserviço, as próximas etapas incluem:
- deixar o código existente em funcionamento no aplicativo legado para facilitar a reversão;
- criar um novo repositório de código ou pelo menos um subdiretório no repositório existente;
- copiar as classes para o novo local;
- escrever uma camada de visualização que forneça os hooks da API HTTP e formate os documentos de resposta da maneira correta;
- formular o novo código como um aplicativo separado (criar um
app.yaml);
- implantar o novo microsserviço como um serviço ou projeto separado;
- testar o código para garantir que ele esteja funcionando corretamente;
- migrar os dados do aplicativo legado para o novo microsserviço. Veja a seguir uma discussão sobre esse assunto;
- alterar o aplicativo legado existente para usar o novo aplicativo de microsserviços;
- implantar o aplicativo legado alterado;
- verificar se tudo funciona conforme esperado e se não é preciso reverter para o aplicativo legado;
- remover qualquer código inoperante do aplicativo legado.
Como migrar dados em um aplicativo ativo
A migração de dados em um aplicativo ativo pode ser complicada, dependendo muito da situação. Muitas vezes, para facilitar o avanço e o rollback, será preciso escrever um código que preencha as entidades antigas e novas do Cloud Datastore, possivelmente usando uma API temporária no microsserviço e, em seguida, escrever um código que migre o conjunto de dados existente, por exemplo, como um MapReduce. Esse processo geralmente envolve alguma quantidade de código temporário e dados redundantes. Dependendo das especificidades da situação, você também pode precisar executar uma migração de dados de recuperação depois do lançamento. Tenha cuidado para não substituir dados mais recentes por dados mais antigos.
Pode parecer muito trabalho, mas isso é corriqueiro. É importante se preparar para a possibilidade de avançar e reverter no caso de insucesso no cutover para o novo microsserviço. Você só pode remover o código temporário e excluir os dados do antigo local de armazenamento depois de verificar que tudo foi migrado corretamente e está funcionando conforme o esperado. Certifique-se de fazer backups ao longo do processo.
A seguir
Exceto em caso de indicação contrária, o conteúdo desta página é licenciado de acordo com a Licença de atribuição 4.0 do Creative Commons, e as amostras de código são licenciadas de acordo com a Licença Apache 2.0. Para mais detalhes, consulte as políticas do site do Google Developers. Java é uma marca registrada da Oracle e/ou afiliadas.
Última atualização 2025-08-19 UTC.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Informações incorretas ou exemplo de código","incorrectInformationOrSampleCode","thumb-down"],["Não contém as informações/amostras de que eu preciso","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 2025-08-19 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 data, authorization, preferences, notifications, media, and task queues, as these often represent independent functionalities.\u003c/p\u003e\n"],["\u003cp\u003eThe microservice migration process involves leaving existing code operational, creating a new code repository, developing an HTTP API layer, and subsequently testing and deploying the microservice.\u003c/p\u003e\n"],["\u003cp\u003eMigrating data in a live environment requires populating both old and new data storage simultaneously, often with temporary code and data redundancy, to enable both roll-forward and rollback capabilities.\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/php/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/php/creating-separate-dev-environments).\n- Learn the [best practices for designing APIs to communicate between microservices](/appengine/docs/legacy/standard/php/designing-microservice-api).\n- Learn the [best practices for microservice performance](/appengine/docs/legacy/standard/php/microservice-performance)."]]
