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
- Memahami cara membuat dan memberi nama lingkungan pengembangan, pengujian, qa, staging, dan produksi dengan microservice di App Engine.
- Pelajari praktik terbaik untuk mendesain API agar dapat berkomunikasi antar-microservice.
- Pelajari praktik terbaik untuk performa microservice.
- Pelajari cara Memigrasikan aplikasi monolitik yang sudah ada ke aplikasi yang memiliki microservice.
- Pahami apakah microservice ideal untuk situasi Anda. Di blog pribadinya, Arsitek Solusi Google Preston Holmes telah memublikasikan postingan tentang beberapa kelemahan yang dia lihat dalam microservice.