Bagikan melalui

Praktik terbaik desain aplikasi Azure Service Fabric

  • Artikel

Artikel ini menyediakan panduan praktik terbaik untuk membangun aplikasi dan layanan di Azure Service Fabric.

Kenali Service Fabric

Panduan desain aplikasi

Pahami dengan baik arsitektur umum dan pertimbangan desain aplikasi Service Fabric.

Pilih gateway API

Gunakan layanan gateway API yang berkomunikasi dengan layanan back-end yang kemudian dapat diskalakan. Layanan gateway API yang paling umum digunakan adalah:

Layanan stateless

Kami sarankan agar Anda selalu mulai dengan membangun layanan stateless dengan menggunakan Reliable Services dan menyimpan status dalam database Azure, Azure Cosmos DB, atau Azure Storage. Status eksternalisasi adalah pendekatan yang lebih umum bagi sebagian besar pengembang. Pendekatan ini juga memungkinkan Anda untuk memanfaatkan kapabilitas kueri di penyimpanan.

Kapan menggunakan layanan stateful

Pertimbangkan layanan stateful saat Anda memiliki skenario latensi rendah dan perlu menyimpan data di dekat komputasi. Beberapa skenario contoh termasuk perangkat kembar digital IoT, status permainan, keadaan sesi, data cache dari database, dan alur kerja yang berjalan lama untuk melacak panggilan ke layanan lain.

Tentukan kerangka waktu retensi data:

  • Data Cache Gunakan cache saat latensi ke penyimpanan eksternal menjadi masalah. Gunakan layanan stateful sebagai cache data Anda sendiri, atau pertimbangkan untuk menggunakan Cache Terdistribusi Service Fabric SoCreate open-source. Dalam skenario ini, Anda tidak perlu khawatir jika Anda kehilangan semua data dalam cache.
  • Data terikat waktu. Dalam skenario ini, Anda perlu menyimpan data mendekati komputasi selama jangka waktu tertentu untuk latensi, tetapi Anda dapat kehilangan data dalam bencana. Misalnya, dalam banyak solusi IoT, data harus mendekati komputasi, seperti ketika suhu rata-rata selama beberapa hari terakhir sedang dihitung, tetapi jika data ini hilang, titik data spesifik yang dicatat tidak terlalu penting. Selain itu, dalam skenario ini Anda biasanya tidak peduli tentang mencadangkan titik data individual. Anda hanya mencadangkan nilai rata-rata komputasi yang secara berkala ditulis ke penyimpanan eksternal.
  • Data jangka panjang. Koleksi yang andal dapat menyimpan data Anda secara permanen. Tetapi dalam hal ini Anda perlu mempersiapkan pemulihan bencana, termasuk mengonfigurasi kebijakan cadangan berkala untuk klaster Anda. Akibatnya, Anda akan mengonfigurasi apa yang terjadi jika klaster Anda dihancurkan dalam bencana. Di mana Anda perlu membuat klaster baru, cara menerapkan instans aplikasi baru dan memulihkan dari cadangan terbaru.

Hemat biaya dan tingkatkan ketersediaan:

  • Anda dapat mengurangi biaya dengan menggunakan layanan stateful karena Anda tidak dikenakan akses data dan biaya transaksi dari penyimpanan jarak jauh, dan karena Anda tidak perlu menggunakan layanan lain, seperti Azure Cache for Redis.
  • Menggunakan layanan stateful terutama untuk penyimpanan dan bukan untuk komputasi itu mahal, dan kami tidak merekomendasikannya. Pikirkan layanan stateful sebagai komputasi dengan penyimpanan lokal yang murah.
  • Dengan menghapus dependensi pada layanan lain, Anda dapat meningkatkan ketersediaan layanan Anda. Mengelola status dengan ketersediaan tinggi di klaster akan mengisolasi Anda dari downtime layanan atau masalah latensi lainnya.

Cara bekerja dengan Reliable Services

Service Fabric Reliable Services memungkinkan Anda untuk dengan mudah membuat layanan stateless dan stateful. Untuk informasi selengkapnya, lihat pengenalan Reliable Services.

  • Selalu hormati token pembatalan dalam RunAsync() metode untuk layanan stateless dan stateful dan ChangeRole() metode untuk layanan stateful. Jika tidak, Service Fabric tidak tahu apakah layanan Anda dapat ditutup. Misalnya, jika Anda tidak menghormati token pembatalan, waktu peningkatan aplikasi yang lebih lama dapat terjadi.
  • Buka dan tutup pendengar komunikasi secara tepat waktu, dan hormati token pembatalan.
  • Jangan pernah mencampur kode sinkronisasi dengan kode asinkron. Misalnya, jangan gunakan .GetAwaiter().GetResult() dalam panggilan asinkron Anda. Gunakan asinkron sepanjang jalan melalui tumpukan panggilan.

Cara bekerja dengan Reliable Actors

Service Fabric Reliable Actors memungkinkan Anda untuk dengan mudah membuat aktor virtual yang stateful. Untuk informasi selengkapnya, lihat pengenalan Reliable Actors.

  • Pertimbangkan dengan serius untuk menggunakan olahpesan pub/sub antara aktor Anda untuk menskalakan aplikasi Anda. Alat yang menyediakan layanan ini termasuk SoCreate Service Fabric Pub/Sub sumber terbuka dan Azure Service Bus.
  • Jadikan status aktor sebagai granular mungkin.
  • Mengelola siklus hidup aktor. Hapus aktor jika Anda tidak akan menggunakannya lagi. Menghapus aktor yang tidak diperlukan sangat penting ketika Anda menggunakan penyedia status volatile, karena semua status disimpan dalam memori.
  • Karena konkurensi berbasis giliran mereka, aktor paling baik digunakan sebagai objek independen. Jangan membuat grafik panggilan metode multi-aktor dan sinkron (masing-masing kemungkinan besar menjadi panggilan jaringan terpisah) atau membuat permintaan aktor melingkar. Ini akan secara signifikan mempengaruhi performa dan skala.
  • Jangan mencampur kode sinkronisasi dengan kode asinkron. Gunakan asinkron secara konsisten untuk mencegah masalah performa.
  • Jangan membuat panggilan jangka panjang dalam aktor. Panggilan jangka panjang akan memblokir panggilan lain ke aktor yang sama, karena konkurensi berbasis giliran.
  • Jika Anda berkomunikasi dengan layanan lain dengan menggunakan Service Fabric remoting dan Anda membuat ServiceProxyFactory, buat pabrik di tingkat layanan aktor dan bukan di tingkat aktor.

Diagnostik aplikasi

Teliti tentang menambahkan pengelogan aplikasi dalam panggilan layanan. Aktivitas Ini akan membantu Anda mendiagnosis skenario di mana layanan saling memanggil. Misalnya, ketika A memanggil B memanggil C memanggil D, panggilan bisa gagal di mana saja. Jika Anda tidak memiliki cukup pengelogan, kegagalan sulit didiagnosis. Jika layanan terlalu banyak log karena volume panggilan, pastikan setidaknya kesalahan log dan peringatan.

Panduan desain di Azure