Praktik Terbaik Layanan Kanonik

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

Layanan Kanonik memungkinkan Anda menjelajahi banyak konfigurasi yang berbeda. Untuk mendapatkan pengalaman terbaik dengan Dasbor Layanan Cloud Service Mesh, pertimbangkan praktik standar berikut saat menyiapkan layanan Anda:

  • Menyiapkan layanan unik [namespace, name] di seluruh mesh.
  • Tentukan satu aplikasi software per Layanan Kanonik.
    • 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 agar Layanan Kanonik memiliki masa aktif yang lama dalam produksi.

Menyiapkan layanan unik [namespace, name] di seluruh mesh

Jika Layanan Kanonik yang di-deploy di satu cluster atau region memiliki namespace Kubernetes dan nama Layanan Kanonik yang sama dengan yang di-deploy di cluster atau region lain, Cloud Service Mesh akan menganggapnya sebagai layanan logis yang sama.

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

Satu aplikasi software per Canonical Service

Layanan Kanonis dimaksudkan untuk mewakili satu layanan logika atau microservice. Fungsi ini dimaksudkan untuk menjangkau biner/beban kerja homogen yang mewakili aplikasi software dan fungsi bisnis yang sama.

Meskipun Anda dapat menentukan Layanan Kanonik untuk mengelompokkan beberapa microservice yang berbeda secara konsep, Dasbor Layanan tidak akan memberikan nilai penuhnya.Dasbor Layanan akan menampilkan agregasi komponen yang tidak sama yang mungkin secara individual berperforma dan dikonfigurasi dengan sangat berbeda. Akan sulit atau bahkan tidak mungkin untuk memahami kondisi, performa, dan konfigurasi secara keseluruhan.

Hal berikut tidak selalu merupakan praktik yang buruk, tetapi Layanan Kanonik Anda mungkin terlalu besar jika:

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

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, pengujian, staging, produksi, atau beberapa subset.

Meskipun Anda men-deploy layanan konseptual yang sama di setiap lingkungan, merupakan praktik yang buruk untuk menjadikannya sebagai satu Layanan Kanonik. Layanan ini tidak sama dan tidak mewakili tingkat perhatian atau fokus operasional yang sama untuk organisasi Anda.

Misalnya, kegagalan pada layanan produksi penting dapat menyebabkan halaman 3AM dan perang api. 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.

Dari yang paling mudah tetapi paling tidak ketat, hingga yang paling sulit tetapi paling canggih, 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 namespaces, misalnya billing-team dan billing-team-test.
  3. Pisahkan menggunakan beberapa armada, satu untuk setiap lingkungan.

Memilih dasbor kustom Cloud Monitoring untuk agregasi arbitrer

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

Layanan Kanonik dimaksudkan untuk aktif dalam waktu lama

Di luar kasus penggunaan pengembangan, eksplorasi, dan pengujian, Layanan Kanonik harus mewakili layanan logis tingkat tinggi global. Layanan ini berubah lambat dan cenderung berumur panjang. Kelangsungan ini mencakup 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 Kanonik baru sering kali mewakili software baru atau yang telah diupdate, sedangkan Layanan Kanonik yang dihentikan sering kali mewakili penghentian layanan. Kemampuan Anda untuk melihat histori performa layanan, paket, dan kapasitas project bergantung pada pemeliharaan satu konsep layanan tersebut di Cloud Service Mesh selama masa aktifnya.

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

Langkah selanjutnya