PHP 5 telah mencapai akhir dukungan dan akan
dihentikan penggunaannya
pada 31 Januari 2026. Setelah penghentian penggunaan, Anda tidak akan dapat men-deploy aplikasi PHP 5, meskipun organisasi Anda sebelumnya menggunakan kebijakan organisasi untuk mengaktifkan kembali deployment runtime lama. Aplikasi PHP 5 yang sudah ada akan terus berjalan dan menerima traffic setelah
tanggal penghentiannya. Sebaiknya Anda
bermigrasi ke versi PHP terbaru yang didukung.
Bermigrasi ke Microservice dari Aplikasi Monolit
Tetap teratur dengan koleksi
Simpan dan kategorikan konten berdasarkan preferensi Anda.
Saat memulai dengan aplikasi monolit lama, Anda harus menemukan bagian yang dapat dikurangi dan dipindahkan ke microservice terpisah. Sering kali, aplikasi monolit yang terstruktur dengan baik akan memiliki pembagian yang sangat alami, dan class layanan sudah berfungsi sebagai antarmuka ke lapisan penyimpanan data dan logika bisnis.
Class tersebut merupakan tempat yang ideal untuk menghubungkan panggilan klien ke microservice.
Memisahkan fungsi dalam aplikasi monolit
Anda dapat melakukan beberapa pendekatan untuk memisahkan aplikasi:
- Cari logika bisnis dalam aplikasi Anda yang dapat dipisahkan.
- Temukan kode yang terisolasi secara alami, misalnya dengan menggunakan alat analisis kode statis untuk mengidentifikasi bagian.
- Periksa logika aplikasi yang mungkin dapat Anda manfaatkan dari setelan konfigurasi penskalaan atau persyaratan memori yang berbeda dengan bagian lain aplikasi Anda. Hal ini dapat menghemat biaya, yang mungkin menghasilkan pemanfaatan resource yang lebih baik.
Anda mungkin perlu memfaktorkan ulang kode untuk menghapus dependensi yang tidak wajar. Sebaiknya lakukan pemfaktoran ulang dalam kode lama dan men-deploy-nya ke produksi sebelum mencoba memisahkan aplikasi menjadi layanan yang terpisah.
Area umum untuk microservice mencakup hal berikut:
- Informasi pengguna atau akun
- Pengelolaan sesi dan otorisasi
- Setelan preferensi atau konfigurasi
- Layanan komunikasi dan notifikasi
- Foto dan media, terutama metadata
- Worker task queue
Langkah-Langkah untuk Memigrasikan Aplikasi
Setelah serangkaian class diidentifikasi sebagai kandidat untuk menjadi microservice, langkah-langkah selanjutnya meliputi:
- Membiarkan kode yang ada diterapkan dan beroperasi dalam aplikasi lama untuk memfasilitasi rollback.
- Membuat repositori kode baru, atau setidaknya sub-direktori di repositori yang ada.
- Menyalin class ke lokasi baru.
- Menulis lapisan tampilan yang menyediakan hook API HTTP dan memformat dokumen respons dengan cara yang benar.
- Merumuskan kode baru sebagai aplikasi terpisah (membuat
app.yaml
).
- Men-deploy microservice baru Anda sebagai layanan atau project terpisah.
- Menguji kode untuk memastikan kode berfungsi dengan benar.
- Memigrasikan data dari aplikasi lama ke microservice baru. Lihat di bawah untuk melihat diskusi.
- Mengubah aplikasi lama yang sudah ada untuk menggunakan aplikasi microservice baru.
- Men-deploy aplikasi lama yang diubah
- Memverifikasi bahwa semuanya berfungsi seperti yang diharapkan dan Anda tidak perlu melakukan roll back ke aplikasi lama.
- Menghapus kode yang mati dari aplikasi lama.
Memigrasikan data pada aplikasi aktif
Migrasi data pada aplikasi aktif dapat menjadi rumit dan sangat bergantung pada situasi Anda. Sering kali, untuk memfasilitasi roll-forward dan rollback, Anda perlu menulis kode yang mengisi entity Cloud Datastore lama dan baru, kemungkinan dengan menggunakan API sementara pada microservice, lalu menulis kode yang memigrasikan set data yang ada, misalnya sebagai MapReduce. Proses ini biasanya akan melibatkan sejumlah kode sementara dan data redundan. Bergantung pada detail situasi Anda, Anda mungkin juga perlu menjalankan migrasi data pengejaran setelah rilis. Berhati-hatilah agar tidak menimpa data yang lebih baru dengan data yang lebih lama.
Meskipun tampak rumit, hal ini umum terjadi serta penting untuk memungkinkan roll forward dan roll back jika migrasi sistem ke microservice baru tidak berhasil. Anda dapat menghapus kode sementara dan menghapus data dari lokasi penyimpanan lama hanya setelah Anda memastikan bahwa semuanya telah dimigrasikan dengan benar dan semuanya beroperasi seperti yang diharapkan. Pastikan untuk membuat cadangan selama proses berlangsung.
Langkah berikutnya
Kecuali dinyatakan lain, konten di halaman ini dilisensikan berdasarkan Lisensi Creative Commons Attribution 4.0, sedangkan contoh kode dilisensikan berdasarkan Lisensi Apache 2.0. Untuk mengetahui informasi selengkapnya, lihat Kebijakan Situs Google Developers. Java adalah merek dagang terdaftar dari Oracle dan/atau afiliasinya.
Terakhir diperbarui pada 2025-08-19 UTC.
[[["Mudah dipahami","easyToUnderstand","thumb-up"],["Memecahkan masalah saya","solvedMyProblem","thumb-up"],["Lainnya","otherUp","thumb-up"]],[["Sulit dipahami","hardToUnderstand","thumb-down"],["Informasi atau kode contoh salah","incorrectInformationOrSampleCode","thumb-down"],["Informasi/contoh yang saya butuhkan tidak ada","missingTheInformationSamplesINeed","thumb-down"],["Masalah terjemahan","translationIssue","thumb-down"],["Lainnya","otherDown","thumb-down"]],["Terakhir diperbarui pada 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)."]]