Python 2.7 telah mencapai akhir dukungan
dan akan
dihentikan penggunaannya
pada 31 Januari 2026. Setelah penghentian penggunaan, Anda tidak akan dapat men-deploy aplikasi Python 2.7, meskipun organisasi Anda sebelumnya menggunakan kebijakan organisasi untuk mengaktifkan kembali deployment runtime lama. Aplikasi Python 2.7 yang ada akan terus berjalan dan menerima traffic setelah
tanggal penghentiannya. Sebaiknya Anda
bermigrasi ke versi Python terbaru yang didukung.
Arsitektur microservice di Google App Engine
Tetap teratur dengan koleksi
Simpan dan kategorikan konten berdasarkan preferensi Anda.
Microservice mengacu pada gaya arsitektur untuk mengembangkan aplikasi. Microservice memungkinkan aplikasi berukuran besar untuk didekomposisi menjadi bagian-bagian konstituen independen, dengan setiap bagian memiliki area tanggung jawabnya sendiri. Untuk melayani satu pengguna atau permintaan API, aplikasi berbasis microservice dapat memanggil banyak microservice internal untuk membuat responsnya.
Aplikasi berbasis microservice yang diterapkan dengan benar dapat mencapai sasaran berikut:
- Menentukan kontrak yang kuat antara berbagai microservice.
- Mengizinkan siklus deployment independen, termasuk rollback.
- Memfasilitasi pengujian rilis A/B merilis secara serentak pada subsistem.
- Meminimalkan otomatisasi pengujian dan overhead jaminan kualitas.
- Meningkatkan kejelasan logging dan pemantauan.
- Memberikan perhitungan biaya yang terperinci.
- Meningkatkan skalabilitas dan keandalan aplikasi secara keseluruhan.
Google App Engine memiliki sejumlah fitur yang sangat cocok untuk aplikasi berbasis microservice. Halaman ini menjelaskan praktik terbaik yang dapat digunakan saat men-deploy aplikasi sebagai aplikasi berbasis microservice di Google App Engine.
Layanan App Engine sebagai microservice
Dalam project App Engine, Anda dapat men-deploy beberapa microservice sebagai layanan terpisah, yang sebelumnya dikenal sebagai modul di App Engine. Layanan ini memiliki isolasi kode sepenuhnya; satu-satunya cara untuk mengeksekusi kode dalam layanan ini adalah melalui pemanggilan HTTP, seperti permintaan pengguna atau panggilan RESTful API. Kode di satu layanan tidak dapat langsung memanggil kode di layanan lain. Kode dapat di-deploy ke layanan secara independen, dan berbagai layanan dapat ditulis dalam berbagai bahasa, seperti Python, Java, Go, dan PHP. Jenis instance mesin, load balancing, dan penskalaan otomatis akan dikelola secara independen untuk layanan.

Versi dalam layanan
Selain itu, setiap layanan dapat memiliki beberapa versi yang di-deploy secara bersamaan.
Untuk setiap layanan, salah satu versi ini adalah versi penyaluran default, meskipun Anda dapat langsung mengakses versi layanan yang di-deploy karena setiap versi memiliki alamatnya sendiri. Struktur ini membuka banyak kemungkinan, termasuk smoke testing terhadap versi baru, pengujian A/B antara versi yang berbeda, serta operasi roll-forward dan rollback yang disederhanakan. Framework App Engine menyediakan mekanisme untuk membantu sebagian besar item ini. Kita akan membahas mekanisme ini secara lebih mendetail di bagian mendatang.

Isolasi layanan
Meskipun sebagian besar terisolasi, layanan berbagi beberapa resource App Engine. Misalnya, Cloud Datastore, Memcache, dan Task Queue adalah resource bersama antara layanan dalam sebuah project App Engine. Meskipun pembagian ini memiliki beberapa keunggulan, penting bagi aplikasi berbasis microservice untuk mempertahankan isolasi kode dan data antara microservice. Ada pola arsitektur yang membantu mengurangi aktivitas berbagi yang tidak diinginkan. Kami akan menjelaskan pola ini nanti dalam artikel ini.

Isolasi project
Jika tidak ingin mengandalkan pola ini untuk menerapkan isolasi dan menginginkan penerapan pemisahan yang lebih formal, Anda dapat menggunakan beberapa project App Engine.
Ada pro dan kontra dalam menggunakan project dan bukan layanan, dan Anda harus menyeimbangkannya, tergantung pada situasi Anda. Kecuali Anda memiliki kebutuhan khusus untuk salah satu keuntungan yang ditawarkan penggunaan beberapa project, sebaiknya mulai dengan menggunakan beberapa layanan dalam satu project karena performanya akan lebih baik dan overhead administratif akan diminimalkan. Tentu saja, Anda juga dapat memilih campuran dari dua pendekatan tersebut.
Perbandingan isolasi layanan dan isolasi project
Tabel berikut menunjukkan perbandingan antara penggunaan beberapa layanan dan beberapa project dalam arsitektur microservice:
|
Beberapa layanan
|
Beberapa project
|
Isolasi kode
|
Kode yang di-deploy sepenuhnya independen antara layanan dan versi.
|
Kode yang di-deploy sepenuhnya independen antara project, serta antara layanan dan versi setiap project.
|
Isolasi data
|
Cloud Datastore dan Memcache digunakan bersama antara layanan dan versi, tetapi namespace dapat digunakan sebagai pola developer untuk mengisolasi data.
Untuk isolasi Task Queue, konvensi developer nama antrean dapat digunakan, seperti user-service-queue-1 .
|
Cloud Datastore, Memcache, dan Task Queue sepenuhnya independen di antara project.
|
Isolasi log
|
Setiap layanan (dan versi) memiliki log independen, meskipun dapat dilihat bersama.
|
Setiap project (dan layanan serta versi setiap project) memiliki log independen, meskipun semua log untuk project tertentu dapat dilihat bersama.
Log di beberapa project tidak dapat dilihat bersamaan.
|
Overhead performa
|
Layanan dari project yang sama di-deploy di pusat data yang sama, sehingga latensi dalam memanggil satu layanan dari layanan lainnya dengan menggunakan HTTP sangat rendah.
|
Project mungkin di-deploy di pusat data yang berbeda, sehingga latensi HTTP bisa lebih tinggi, meskipun masih cukup rendah karena jaringan Google adalah jaringan kelas dunia.
|
Akuntansi biaya
|
Biaya untuk jam kerja instance (CPU dan memori untuk menjalankan kode Anda) tidak dipisahkan untuk layanan; semua jam kerja instance untuk seluruh project akan disatukan.
|
Biaya untuk berbagai project dipecah, sehingga memudahkan Anda untuk mengetahui biaya microservice yang berbeda.
|
Izin operator
|
Operator memiliki kemampuan untuk men-deploy kode, melakukan roll forward dan roll back versi, serta melihat log untuk semua layanan dalam sebuah project.
Tidak ada cara untuk membatasi akses ke layanan tertentu.
|
Akses operator dapat dikontrol secara terpisah pada project terpisah.
|
Tracing permintaan
|
Dengan Google Cloud Trace, Anda dapat melihat permintaan dan permintaan microservice yang dihasilkan untuk layanan dalam project yang sama sebagai trace tunggal yang tersusun. Fitur ini dapat membantu mempermudah penyesuaian performa.
|
Panggilan Cloud Trace dapat divisualisasikan di seluruh project GCP jika berada dalam Organisasi yang sama.
|
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-09-04 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-09-04 UTC."],[[["\u003cp\u003eMicroservices architecture allows large applications to be broken down into independent parts, each with specific responsibilities, which communicate to fulfill user or API requests.\u003c/p\u003e\n"],["\u003cp\u003eApp Engine supports microservices through separate services, enabling code isolation, independent deployment cycles, and the use of different programming languages.\u003c/p\u003e\n"],["\u003cp\u003eWithin each service, multiple versions can exist concurrently, facilitating A/B testing, rollbacks, and simplified deployments.\u003c/p\u003e\n"],["\u003cp\u003eWhile services within an App Engine project share resources like Cloud Datastore and Memcache, developers can use namespaces and naming conventions to maintain data isolation, or use separate App Engine projects for more enforced isolation.\u003c/p\u003e\n"],["\u003cp\u003eUsing multiple projects offers strong separation of resources, cost accounting and operator permissions, but using multiple services in the same project is recommended for better performance and lower overhead, unless project specific isolation is required.\u003c/p\u003e\n"]]],[],null,["# Microservices Architecture on Google App Engine\n\n*Microservices* refers to an architectural style for\ndeveloping applications. Microservices allow a large application to be\ndecomposed into independent constituent parts, with each part having its own\nrealm of responsibility. To serve a single user or API request,\na microservices-based application can call many internal microservices\nto compose its response.\n\nA properly implemented microservices-based application can achieve the\nfollowing goals:\n\n- Define strong contracts between the various microservices.\n- Allow for independent deployment cycles, including rollback.\n- Facilitate concurrent, A/B release testing on subsystems.\n- Minimize test automation and quality-assurance overhead.\n- Improve clarity of logging and monitoring.\n- Provide fine-grained cost accounting.\n- Increase overall application scalability and reliability.\n\nGoogle App Engine has a number of features that are well-suited for a\nmicroservices-based application. This page outlines best practices to use\nwhen deploying your application as a microservices-based application on Google\nApp Engine.\n\nApp Engine Services as microservices\n------------------------------------\n\nIn an App Engine project, you can deploy multiple microservices as separate\n*[services](/appengine/docs/legacy/standard/python/an-overview-of-app-engine)* , previously known as\n*modules* in App Engine. These services have full isolation of code; the only\nway to execute code in these services is through an HTTP invocation, such as a\nuser request or a RESTful API call. Code in one service can't directly call code\nin another service. Code can be deployed to services independently, and\ndifferent services can be written in different languages, such as Python, Java,\nGo, and PHP. Autoscaling, load balancing, and machine instance types are all\nmanaged independently for services.\n\nVersions within services\n------------------------\n\nFurthermore, each service can have multiple *versions* deployed simultaneously.\nFor each service, one of these versions is the default serving version, though\nit is possible to directly access any deployed version of a service as each\nversion of each service has its own address. This structure opens up myriad\npossibilities, including smoke testing a new version, A/B testing between\ndifferent versions, and simplified roll-forward and rollback operations. The App\nEngine framework provides mechanisms to assist with most of these items. We'll\ncover these mechanisms in more detail in upcoming sections.\n\nService isolation\n-----------------\n\nThough mostly isolated, services share some App Engine resources. For example,\nCloud Datastore, Memcache, and Task Queues are all shared resources between services\nin an App Engine project. While this sharing has some advantages,\nit's important for a microservices-based application to maintain code- and\ndata-isolation between microservices. There are architecture patterns that help\nmitigate unwanted sharing. We'll describe these patterns later in this article.\n\nProject isolation\n-----------------\n\nIf you don't want to rely on these patterns to achieve isolation and you want a\nmore formal enforcement of separation, you can use multiple App Engine projects.\nThere are pros and cons to using projects instead of services, and you must\nbalance the tradeoffs depending on your situation. Unless you have a specific\nneed for one of the advantages offered by using multiple projects, it's best to\nstart with using multiple services within a single project because performance\nwill be better and the administrative overhead will be minimized. Of course, you\ncan also choose some hybrid of the two approaches.\n\nComparison of service isolation and project isolation\n-----------------------------------------------------\n\nThe following table provides a comparison between using multiple services and\nmultiple projects in a microservices architecture:\n\nWhat's next\n-----------\n\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).\n- Learn how to [Migrate an existing monolithic application to one with microservices](/appengine/docs/legacy/standard/python/microservice-migration).\n- Understand if microservices are ideal for your situation. On his personal blog, Google Solution Architect Preston Holmes has [published a post about some of the drawbacks](http://www.ptone.com/dablog/2015/07/microservices-may-be-the-new-premature-optimization/) he sees in microservices."]]