Saat mendesain aplikasi web yang didasarkan pada arsitektur microservice, tentukan cara membagi fitur aplikasi menjadi beberapa microservice, dan cara memanggil microservice tersebut sebagai bagian dari aplikasi. Untuk layanan yang berjalan lama, Anda mungkin ingin menggunakan panggilan layanan asinkron. Arsitektur referensi ini membahas cara men-deploy aplikasi dalam container yang memanggil proses yang berjalan lama secara asinkron.
Dokumen arsitektur referensi ini ditujukan bagi developer dan arsitek yang ingin mengimplementasikan microservice secara asinkron menggunakan teknologi modern, termasuk Google Kubernetes Engine (GKE) dan Pub/Sub. Dokumen ini mengasumsikan bahwa Anda sudah memahami microservice secara umum, serta memahami Pub/Sub dan GKE di Google Cloud.
Arsitektur
Diagram berikut mengilustrasikan skenario contoh saat aplikasi menghasilkan image thumbnail. Membuat gambar thumbnail bisa menjadi tugas yang membutuhkan banyak resource dan karenanya bisa memakan waktu.
Gambar 1. Arsitektur asli untuk pemrosesan image yang didasarkan pada penggunaan VM.
Dalam diagram sebelumnya, aplikasi menerima file gambar dari klien lalu membuat thumbnail. Dalam arsitektur ini, aplikasi diimplementasikan menggunakan instance virtual machine (VM) di Compute Engine dan dengan menggunakan penyimpanan file backend di Cloud Storage. Aplikasi tersebut menyimpan metadata menggunakan Cloud Storage. Cloud Load Balancing mendistribusikan permintaan ke beberapa VM.
Untuk mengurangi overhead operasional guna mengelola VM, Anda perlu memigrasikan sistem ini ke arsitektur baru yang tidak menggunakan VM.
Diagram berikut menunjukkan cara penerapan alur ini menggunakan layanan terkelola yang menggunakan notifikasi dan microservice untuk menerapkan panggilan asinkron antar-komponen sistem.
Gambar 2. Arsitektur baru untuk pemrosesan image yang didasarkan pada penggunaan container dan pesan asinkron.
Dalam arsitektur baru, klien mengirimkan image ke aplikasi dan aplikasi menguploadnya ke Cloud Storage. Kemudian, notifikasi Pub/Sub akan menempatkan pesan dalam antrean pesan Pub/Sub. Pesan tersebut memanggil microservice yang berjalan di GKE. Microservice mengambil gambar dari Cloud Storage, membuat thumbnail, dan mengupload thumbnail ke Cloud Storage.
Pertimbangan desain
Panduan berikut dapat membantu Anda mengembangkan arsitektur yang memenuhi persyaratan organisasi Anda untuk performa dan efisiensi operasional.
Efisiensi operasional
Arsitektur baru ini memiliki keunggulan berikut:
Skalabilitas independen: Dalam arsitektur awal, aplikasi yang berjalan di Compute Engine menangani dua tugas inti. Salah satu tugasnya adalah menerima file, dan tugas lainnya adalah membuat thumbnail dari image asli. Menerima file yang diupload menghabiskan bandwidth jaringan, dan membuat thumbnail adalah tugas yang menguras CPU. Instance Compute Engine mungkin kehabisan resource CPU untuk menghasilkan image, tetapi masih memiliki resource jaringan yang cukup untuk menerima file. Dalam arsitektur baru, tugas-tugas ini digunakan bersama oleh Cloud Storage dan GKE, sehingga tugas-tugas ini dapat diskalakan secara independen.
Fungsi baru yang mudah ditambahkan: Dalam arsitektur awal, jika ingin menambahkan fungsionalitas, Anda harus men-deploy-nya pada instance Compute Engine yang sama. Dalam arsitektur baru ini, Anda dapat mengembangkan aplikasi dan menambahkannya secara independen—misalnya, Anda dapat menambahkan aplikasi pengirim email untuk memberi tahu Anda saat thumbnail baru dibuat. Pub/Sub dapat terhubung ke aplikasi pembuatan thumbnail dan aplikasi pengirim email secara asinkron tanpa mengubah kode asli yang berjalan di GKE.
Pengaitan yang dikurangi: Dalam arsitektur asli, masalah yang umum adalah pengaitan sementara. Jika server relai email tidak tersedia, notifikasi akan gagal saat aplikasi mencoba mengirim notifikasi. Proses tersebut terkait erat, dan klien mungkin tidak mendapatkan respons yang berhasil dari aplikasi. Dalam arsitektur baru, klien mendapatkan respons yang berhasil karena pembuatan thumbnail dan pengiriman notifikasi dikaitkan secara longgar.
Arsitektur baru ini memiliki kekurangan berikut:
Upaya tambahan untuk memodernisasi aplikasi: Memasukkan aplikasi ke dalam container memerlukan waktu dan upaya. Arsitektur baru ini menggunakan lebih banyak layanan dan memerlukan pendekatan yang berbeda untuk kemampuan observasi, yang mencakup perubahan pada pemantauan aplikasi, proses deployment, dan pengelolaan resource.
Persyaratan untuk menangani duplikasi di sisi aplikasi: Pub/Sub menjamin pengiriman pesan minimal satu kali, yang berarti bahwa pesan duplikat mungkin dikirim. Aplikasi Anda harus menangani kemungkinan ini.
Performa
Arsitektur baru ini dapat memberi Anda penggunaan resource yang efisien: Dalam arsitektur aslinya, penyebaran skala instance Compute Engine akan menghabiskan lebih banyak resource agar dapat menjalankan sistem operasi. Dengan GKE, Anda dapat secara efisien menggunakan resource server yang menjalankan beberapa container hanya pada beberapa server (bin packing). Anda dapat menskalakan container keluar dan masuk dengan cepat, sehingga arsitektur baru dapat menangani burst beban tinggi dan menurunkan skala dengan cepat saat tugas selesai.
Deployment
Untuk men-deploy aplikasi contoh yang mengimplementasikan arsitektur ini, lihat Men-deploy microservice yang menggunakan Pub/Sub dan GKE.
Langkah selanjutnya
- Baca DevOps, dan pelajari lebih lanjut kemampuan Arsitektur yang terkait dengan arsitektur referensi ini.
- Lakukan pemeriksaan cepat DevOps untuk memahami posisi Anda dibandingkan dengan industri lainnya.
- Untuk arsitektur referensi, diagram, dan praktik terbaik lainnya, jelajahi Pusat Arsitektur Cloud.