PHP 5 ha raggiunto la fine del supporto e verrà
ritirato
il 31 gennaio 2026. Dopo il ritiro, non potrai eseguire il deployment di applicazioni PHP 5, anche se la tua organizzazione ha utilizzato in precedenza un criterio dell'organizzazione per riattivare i deployment di runtime legacy. Le tue applicazioni PHP
5 esistenti continueranno a essere eseguite e a ricevere traffico dopo la
data di ritiro. Ti consigliamo di
eseguire la migrazione all'ultima versione supportata di PHP.
Migrazione ai microservizi da un'app monolitica
Mantieni tutto organizzato con le raccolte
Salva e classifica i contenuti in base alle tue preferenze.
Quando parti da un'applicazione monolitica legacy, devi trovare le parti che possono essere isolate e spostate in microservizi separati. Spesso un'app monolitica ben strutturata avrà suddivisioni molto naturali e una classe di servizio fungerà già da interfaccia per un livello di archiviazione dei dati e logica aziendale.
Questi tipi di classi sono il luogo ideale per collegare le chiamate del client al
microservizio.
Separazione delle funzionalità in un'app monolitica
Puoi adottare due approcci per separare l'app:
- Cerca nella tua applicazione la logica di business che può essere separata.
- Trova il codice isolato naturalmente, ad esempio utilizzando strumenti di analisi del codice statico per identificare le sezioni.
- Esamina la logica della tua applicazione per individuare eventuali requisiti di memoria o impostazioni di configurazione di scalabilità diversi rispetto al resto dell'applicazione. Ciò potrebbe comportare un risparmio sui costi che potrebbe portare a un migliore utilizzo delle risorse.
Potresti dover eseguire il refactoring del codice per rimuovere le dipendenze non naturali. Ti consigliamo di eseguire il refactoring del codice precedente e di eseguirlo in produzione prima di tentare di separare l'app in servizi distinti.
Le aree comuni per i microservizi includono:
- Dati dell'utente o dell'account
- Autorizzazione e gestione delle sessioni
- Preferenze o impostazioni di configurazione
- Servizi di notifiche e comunicazioni
- Foto e contenuti multimediali, in particolare i metadati
- Worker delle code di attività
Passaggi per eseguire la migrazione di un'app
Dopo che è stato identificato un insieme di classi come candidato a diventare un microservice, i passaggi successivi includono:
- Lasciare il codice esistente in posizione e operativo nell'applicazione precedente per facilitare il rollback.
- Creare un nuovo repository di codice o almeno una sottodirectory nel repository esistente.
- Copiare i corsi nella nuova posizione.
- Scrittura di un livello di visualizzazione che fornisca i hook dell'API HTTP e formatta i documenti di risposta nel modo corretto.
- Formulare il nuovo codice come applicazione separata (crea un
app.yaml).
- Esegui il deployment del nuovo microservizio come servizio o progetto separato.
- Testare il codice per assicurarsi che funzioni correttamente.
- Esegui la migrazione dei dati dall'app precedente al nuovo microservizio. Di seguito è riportata una discussione.
- Modifica dell'applicazione legacy esistente per utilizzare la nuova applicazione basata su microservizi.
- Deployment dell'applicazione legacy modificata
- Verificare che tutto funzioni come previsto e che non sia necessario eseguire il rollback all'applicazione precedente.
- Rimuovere il codice inutilizzato dall'applicazione precedente.
Eseguire la migrazione dei dati in un'applicazione in produzione
La migrazione dei dati in un'applicazione in produzione può essere complessa e dipendere molto dalla tua situazione. Spesso, per facilitare il rollforward e il rollback, devi scrivere codice che completi sia le entità Cloud Datastore precedenti che quelle nuove, eventualmente utilizzando un'API temporanea sul microservizio, e poi scrivere codice che esegui la migrazione del set di dati esistente, ad esempio come MapReduce. In genere, questa procedura comporta una certa quantità di codice temporaneo e dati ridondanti. A seconda delle specifiche della tua situazione, potrebbe essere necessario eseguire anche una migrazione dei dati per recuperare quelli mancanti dopo il rilascio. Fai attenzione a non sovrascrivere i dati più recenti con quelli meno recenti.
Sembra un sacco di lavoro, ma è un'operazione comune ed è importante consentire il roll forward e il roll back nel caso in cui il passaggio al nuovo microservizio non vada a buon fine. Puoi rimuovere il codice temporaneo ed eliminare i dati dalla posizione di archiviazione precedente solo dopo aver verificato che la migrazione sia stata eseguita correttamente e che tutto funzioni come previsto. Assicurati di eseguire i backup durante l'operazione.
Passaggi successivi
Salvo quando diversamente specificato, i contenuti di questa pagina sono concessi in base alla licenza Creative Commons Attribution 4.0, mentre gli esempi di codice sono concessi in base alla licenza Apache 2.0. Per ulteriori dettagli, consulta le norme del sito di Google Developers. Java è un marchio registrato di Oracle e/o delle sue consociate.
Ultimo aggiornamento 2025-09-04 UTC.
[[["Facile da capire","easyToUnderstand","thumb-up"],["Il problema è stato risolto","solvedMyProblem","thumb-up"],["Altra","otherUp","thumb-up"]],[["Difficile da capire","hardToUnderstand","thumb-down"],["Informazioni o codice di esempio errati","incorrectInformationOrSampleCode","thumb-down"],["Mancano le informazioni o gli esempi di cui ho bisogno","missingTheInformationSamplesINeed","thumb-down"],["Problema di traduzione","translationIssue","thumb-down"],["Altra","otherDown","thumb-down"]],["Ultimo aggiornamento 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 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)."]]
