Arsitektur microservice di Google App Engine

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.

Project App Engine mencapai pemisahan dengan menggunakan layanan.

Versi dalam layanan

Selain itu, setiap layanan dapat memiliki beberapa versions 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.

Sebuah project App Engine dapat memiliki beberapa layanan dan versi.

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.

Project App Engine berbagi layanan.

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 selanjutnya