Praktik Terbaik Layanan Kanonis

Catatan: Layanan Kanonis didukung secara otomatis di Anthos Service Mesh versi 1.6.8 dan yang lebih baru.

Layanan Kanonis memungkinkan Anda membuka berbagai konfigurasi yang berbeda. Untuk mendapatkan pengalaman terbaik dengan Dasbor Layanan Anthos Service Mesh, pertimbangkan praktik standar berikut saat menyiapkan layanan Anda:

• Pesan layanan unik [namespace, name] di seluruh mesh.
• Menentukan satu aplikasi software per Layanan Kanonis.
  • Jangan mengelompokkan Layanan Kanonis di seluruh lingkungan (misalnya, prod/stage/dev).
  • Gunakan dasbor Cloud Monitoring untuk tampilan tingkat yang lebih tinggi dari beberapa layanan.
• Rencanakan Layanan Kanonis untuk jangka panjang dalam produksi.

Pesan layanan unik [namespace, name] di seluruh mesh

Jika Layanan Kanonis yang di-deploy di satu cluster atau region memiliki namespace Kubernetes dan nama Layanan Kanonis yang sama dengan yang di-deploy di cluster atau region lain, Anthos Service Mesh mengasumsikan bahwa layanan tersebut adalah layanan logis yang sama.

Perilaku ini konsisten dengan prinsip armada "kesamaan", yang menyatakan bahwa namespace harus memiliki makna yang sama dan mewakili entity yang sama di seluruh fleet.

Penting: Pastikan layanan yang berbeda secara logis (misalnya, API akuntansi pembayaran dan API transaksi pembayaran) tidak menggunakan pasangan [namespace, name] yang sama (misalnya, "payments/api") karena keduanya secara tidak sengaja bergabung ke satu Dasbor Layanan. Perlu diperhatikan bahwa penggabungan konseptual ini terjadi bahkan di seluruh batas regional. Selain itu, fungsi layanan mungkin juga terpengaruh.

Satu aplikasi software per Layanan Kanonis

Layanan Kanonis dimaksudkan untuk mewakili satu layanan logis atau microservice. Pengujian ini dimaksudkan untuk mencakup biner/beban kerja homogen yang mewakili aplikasi software dan fungsi bisnis yang sama.

Meskipun Anda dapat menentukan Layanan Kanonis untuk mengelompokkan beberapa microservice yang berbeda secara konseptual secara bersamaan, Dasbor Layanan tidak akan memberikan nilai penuhnya.Dasbor Layanan akan menampilkan agregasi komponen yang berbeda yang masing-masing dapat berperforma dan dikonfigurasi dengan sangat berbeda. Akan sulit atau bahkan tidak mungkin untuk memahami respons, performa, dan konfigurasi keseluruhan.

Berikut ini bukan praktik yang buruk, tetapi Layanan Kanonis Anda mungkin terlalu besar jika:

• Ada traffic jaringan antara workload yang berbeda dalam satu Layanan Kanonis.
• Layanan Kanonis terdiri dari beberapa workload yang di-deploy pada jadwal rilis yang berbeda.
• Beberapa tim dalam organisasi Anda bertanggung jawab untuk mengoperasikan berbagai bagian yang berbeda dari satu Layanan Kanonis.

Jangan mengelompokkan Layanan Kanonis di seluruh lingkungan

Banyak organisasi teknologi menggunakan beberapa lingkungan deployment untuk memastikan kualitas software dan membatasi risiko. Lingkungan ini paling sering mencakup pengembangan, pengujian, staging, prod, atau beberapa subset.

Meskipun Anda men-deploy layanan konseptual yang sama di setiap berbagai lingkungan, merupakan praktik yang buruk untuk menjadikannya satu Layanan Kanonis. Layanan ini berbeda dan tidak merepresentasikan tingkat masalah atau fokus operasional yang sama untuk organisasi Anda.

Misalnya, kegagalan pada layanan produksi penting dapat menyebabkan halaman jam 3 dini hari dan baku tembak. Anda tidak ingin memberi tahu siapa pun jika deployment "dev" gagal di tengah malam. Hal yang sama berlaku untuk memahami performa, kapasitas, dan keamanan rilis.

Penting: Sebaiknya Anda memisahkan layanan di berbagai lingkungan menjadi Layanan Kanonis terpisah. Anda dapat melakukannya dengan salah satu dari tiga cara berikut.

Ada tiga cara untuk memisahkan layanan ke lingkungan yang berbeda, mulai dari yang paling mudah tetapi paling tidak ketat hingga upaya tertinggi tetapi paling andal:

1. Pisahkan menggunakan beberapa nama layanan, misalnya, payments-prod dan payments-test.
2. Pisahkan menggunakan beberapa namespace, misalnya billing-team dan billing-team-test.
3. Pisahkan menggunakan beberapa fleet, satu untuk setiap lingkungan.

Memilih dasbor kustom Cloud Monitoring untuk agregasi arbitrer

Daripada membengkakkan Layanan Kanonis secara artifisial menjadi cakupan yang lebih besar untuk data gabungan, gunakan dasbor Cloud Monitoring untuk membuat tampilan tingkat lebih tinggi dari beberapa layanan logika sekaligus.

Layanan Kanonis dimaksudkan untuk berumur panjang

Di luar kasus penggunaan pengembangan, eksplorasi, dan pengujian, Layanan Kanonis harus mewakili layanan logika tingkat tinggi secara global. Layanan ini berubah lambat dan cenderung berumur panjang. Masa pakai ini termasuk tidak mengubah nama layanan. Meskipun Anda dapat mengubah namanya, tindakan tersebut akan memengaruhi metrik, SLO, dan log. Namun, Anda dapat menyesuaikan kolom Display name dengan bebas tanpa gangguan.

Layanan Kanonis baru sering kali mewakili software baru atau yang diupdate, sedangkan Layanan Kanonis yang dihentikan penggunaannya sering kali mewakili penghentian layanan. Kemampuan Anda untuk melihat histori performa dari layanan, paket, dan kapasitas project Anda bergantung pada cara mempertahankan satu gagasan tentang layanan tersebut di Anthos Service Mesh selama masa pakainya.

Perhatikan bahwa hal ini berbeda dengan resource level lebih rendah seperti instance VM, Pod/Deployment Kubernetes, dan bahkan seluruh cluster, yang sering kali tersedia dan digunakan sebagai bagian dari update dan pemeliharaan sistem produksi.

Langkah selanjutnya

• Pelajari Layanan Kanonis lebih lanjut.
• Pelajari cara menentukan Layanan Kanonis.