Praktik Terbaik Layanan Kanonis

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

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

• Mencadangkan layanan unik [namespace, name] di seluruh mesh.
• Tentukan satu aplikasi software per Layanan Kanonis.
  • Jangan mengelompokkan Layanan Kanonis di berbagai lingkungan (misalnya, prod/stage/dev).
  • Gunakan dasbor Cloud Monitoring untuk tampilan tingkat yang lebih tinggi dari beberapa layanan.
• Merencanakan agar Layanan Kanonis bertahan lama dalam produksi.

Mencadangkan 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 seperti yang di-deploy di cluster atau region lain, Cloud Service Mesh mengasumsikan bahwa layanan tersebut adalah layanan logis yang sama.

Perilaku ini konsisten dengan prinsip lengkap "kesamaan", yang menyatakan bahwa namespace harus memiliki arti yang sama dan merepresentasikan entitas yang sama di seluruh fleet.

Penting: Pastikan layanan yang berbeda secara logis (misalnya, Payment Accounting API dan Payment Transaction API) tidak menggunakan pasangan [namespace, name] yang sama (misalnya, "payments/api") karena mereka secara tidak sengaja bergabung ke satu Dasbor Layanan. Perhatikan bahwa penggabungan konseptual ini terjadi bahkan di seluruh batas wilayah. Selain itu, fungsi layanan dapat terdampak.

Satu aplikasi software per Layanan Kanonis

Layanan Kanonis dimaksudkan untuk mewakili satu layanan logis atau microservice. Class tersebut 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, Dasbor Layanan tidak akan memberikan nilai penuhnya.Dasbor Layanan akan menampilkan agregasi komponen yang berbeda, yang masing-masing mungkin memiliki performa dan konfigurasi yang sangat berbeda. Akan sulit atau bahkan tidak mungkin untuk memahami kondisi, performa, dan konfigurasi secara keseluruhan.

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

• Terdapat traffic jaringan antara berbagai workload dalam satu Layanan Kanonis.
• Layanan Kanonis terdiri dari beberapa workload yang di-deploy pada jadwal rilis yang berbeda.
• Tim yang berbeda dalam organisasi Anda bertanggung jawab untuk mengoperasikan berbagai bagian 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 dev, test, staging, prod, atau subset.

Meskipun Anda men-deploy layanan konseptual yang sama di masing-masing lingkungan yang beragam, membuat layanan tersebut menjadi satu Layanan Kanonis adalah praktik yang buruk. Layanan ini tidak sama dan tidak mewakili tingkat masalah operasional atau fokus yang sama untuk organisasi Anda.

Misalnya, kegagalan pada layanan produksi penting dapat menyebabkan halaman pukul 03.00 dan pemadam kebakaran. Anda tidak ingin memberi tahu siapa pun jika deployment "dev" gagal pada 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.

Mulai dari yang paling mudah tetapi paling tidak ketat, hingga yang paling mudah tetapi paling efektif, ada tiga cara untuk memisahkan layanan ke dalam lingkungan yang berbeda:

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.

Pilih dasbor kustom Cloud Monitoring untuk agregasi arbitrer

Daripada membengkak secara artifisial Layanan Kanonis ke dalam cakupan yang lebih besar untuk data gabungan, gunakan dasbor Cloud Monitoring untuk membuat tampilan tingkat lebih tinggi dari beberapa layanan logis sekaligus.

Layanan Kanonis dimaksudkan untuk berumur panjang

Di luar kasus penggunaan pengembangan, eksplorasi, dan pengujian, Layanan Kanonis harus merepresentasikan layanan logis global tingkat tinggi. Layanan ini lambat berubah dan cenderung berumur panjang. Usia ini termasuk tidak mengubah nama layanan. Meskipun Anda dapat mengubah namanya, tindakan ini 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, sementara Layanan Kanonis yang dihentikan sering kali mewakili penghentian layanan. Kemampuan Anda untuk melihat histori performa layanan, paket, dan kapasitas project bergantung pada upaya untuk mempertahankan satu konsep layanan tersebut di Cloud Service Mesh selama masa pakainya.

Perlu diperhatikan bahwa hal ini berbeda dengan resource tingkat rendah seperti instance VM, Pod Kubernetes/Deployment, dan bahkan seluruh cluster, yang sering kali datang dan hilang sebagai bagian dari update dan pemeliharaan sistem produksi.

Langkah selanjutnya

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