Skenario kemampuan pengujian Service Fabric: Komunikasi layanan
Layanan mikro dan gaya arsitektur berorientasi layanan muncul secara alami di Azure Service Fabric. Dalam jenis arsitektur terdistribusi ini, aplikasi layanan mikro komponen biasanya terdiri dari beberapa layanan yang perlu berkomunikasi satu sama lain. Bahkan, dalam kasus yang paling sederhana, Anda umumnya memiliki setidaknya layanan web stateless dan layanan penyimpanan data yang stateful yang perlu berkomunikasi.
Komunikasi service-to-service adalah titik integrasi penting dari aplikasi, karena setiap layanan mengekspos API jarak jauh ke layanan lain. Bekerja dengan serangkaian batas API yang melibatkan I/O umumnya memerlukan perhatian, dengan jumlah pengujian dan validasi yang memadai.
Ada banyak pertimbangan yang harus dibuat ketika batas-batas layanan ini disatukan dalam sistem terdistribusi:
- Protokol 7ransportasi. Apakah Anda akan menggunakan HTTP untuk meningkatkan interoperabilitas, atau protokol biner kustom untuk throughput maksimum?
- Penanganan kesalahan. Bagaimana kesalahan permanen dan sementara akan ditangani? Apa yang akan terjadi ketika layanan pindah ke node yang berbeda?
- Waktu habis dan latensi. Dalam aplikasi multitingkat, bagaimana setiap lapisan layanan menangani latensi melalui tumpukan dan kepada pengguna?
Baik menggunakan salah satu komponen komunikasi layanan bawaan yang disediakan oleh Service Fabric atau membangun sendiri, menguji interaksi antar layanan sangat penting untuk memastikan ketahanan dalam aplikasi Anda.
Siapkan untuk layanan untuk pindah
Instans layanan dapat berpindah-pindah dari waktu ke waktu. Ini terutama berlaku ketika instan dikonfigurasi dengan metrik beban untuk penyeimbangan sumber daya optimal yang disesuaikan secara khusus. Service Fabric memindahkan instans layanan Anda untuk memaksimalkan ketersediaannya bahkan selama peningkatan, failover, scale-out, dan situasi lain yang terjadi selama masa guna sistem terdistribusi.
Ketika layanan berpindah di sekitar kluster, klien Anda dan layanan lain harus siap untuk menangani dua skenario ketika klien berinteraksi dengan layanan:
- Instans layanan atau replika partisi telah bergerak sejak terakhir kali Anda berinteraksi dengannya. Ini adalah bagian normal dari siklus hidup layanan, dan ini seharusnya terjadi selama masa guna aplikasi Anda.
- Instans layanan atau replika partisi sedang dalam proses perpindahan. Meskipun kegagalan layanan dari satu node ke node lain terjadi sangat cepat di Service Fabric, mungkin ada keterlambatan ketersediaan jika komponen komunikasi layanan Anda lambat untuk memulai.
Menangani skenario ini dengan lancar penting untuk sistem yang berjalan lancar. Untuk melakukannya, perlu diingat bahwa:
- Setiap layanan yang dapat disambungkan memiliki alamat yang didengarkannya (misalnya, HTTP atau WebSocket). Saat instans layanan atau partisi berpindah, titik akhir alamatnya berubah. (Hal tersebut pindah ke node yang berbeda dengan alamat IP yang berbeda.) Jika Anda menggunakan komponen komunikasi bawaan, komponen tersebut akan menangani penyelesaian ulang alamat layanan untuk Anda.
- Mungkin ada peningkatan sementara dalam latensi layanan saat instans layanan memulai listener-nya lagi. Ini bergantung pada seberapa cepat layanan membuka listener setelah instans layanan berpindah.
- Koneksi yang ada harus ditutup dan dibuka kembali setelah layanan terbuka pada node baru. Shutdown atau restart node yang lancar memungkinkan waktu untuk koneksi yang ada untuk dinonaktifkan dengan lancar.
Mengujinya: Memindahkan instans layanan
Dengan menggunakan alat uji Coba Service Fabric, Anda dapat menulis skenario pengujian untuk menguji situasi ini dengan cara yang berbeda:
Pindahkan replika utama layanan yang stateful.
Replika utama partisi layanan stateful dapat berpindah karena sejumlah alasan. Gunakan ini untuk menargetkan replika utama partisi tertentu untuk melihat tanggapan layanan Anda terhadap perpindahan dengan cara yang sangat terkontrol.
PS > Move-ServiceFabricPrimaryReplica -PartitionId 6faa4ffa-521a-44e9-8351-dfca0f7e0466 -ServiceName fabric:/MyApplication/MyServiceMenghentikan sebuah node.
Ketika node dihentikan, Service Fabric memindahkan semua instans layanan atau partisi yang ada di node tersebut ke salah satu node lain yang tersedia di kluster. Gunakan ini untuk menguji situasi saat node hilang dari kluster Anda dan semua instans layanan dan replika pada node tersebut harus berpindah.
Anda dapat menghentikan node dengan menggunakan cmdlet Stop-ServiceFabricNode PowerShell:
PS > Stop-ServiceFabricNode -NodeName Node_1
Mempertahankan ketersediaan layanan
Sebagai platform, Service Fabric dirancang untuk memberikan ketersediaan tinggi pada layanan Anda. Tetapi dalam kasus ekstrem, masalah infrastruktur yang mendasarinya masih dapat menyebabkan ketidaktersediaan. Skenario ini harus diuji juga.
Layanan stateful menggunakan sistem berbasis kuorum untuk mereplikasi status untuk ketersediaan tinggi. Ini berarti bahwa kuorum replika perlu tersedia untuk melakukan operasi penulisan. Dalam kasus yang jarang terjadi, seperti kegagalan perangkat keras yang meluas, kuorum replika mungkin tidak tersedia. Dalam kasus ini, Anda tidak akan dapat melakukan operasi tulis, tetapi Anda tetap dapat melakukan operasi pembacaan.
Uji: Operasi penulisan tidak tersedia
Dengan menggunakan alat uji dalam Service Fabric, Anda dapat menginjeksi kesalahan yang mendorong kehilangan kuorum sebagai pengujian. Meskipun skenario tersebut jarang terjadi, klien dan layanan yang bergantung pada layanan stateful harus disiapkan untuk menangani situasi saat mereka tidak dapat membuat permintaan tulis untuk itu. Layanan stateful itu sendiri harus menyadari kemungkinan ini dan dapat dengan lancar mengomunikasikannya kepada pemanggil.
Anda dapat mendorong kehilangan kuorum menggunakan cmdlet PowerShell Invoke-ServiceFabricPartitionQuorumLoss:
PS > Invoke-ServiceFabricPartitionQuorumLoss -ServiceName fabric:/Myapplication/MyService -QuorumLossMode QuorumReplicas -QuorumLossDurationInSeconds 20
Dalam contoh ini, kita menetapkan QuorumLossMode ke QuorumReplicas untuk menunjukkan bahwa kami ingin mendorong kehilangan kuorum tanpa menarik semua replika. Dengan cara ini, operasi baca masih memungkinkan. Untuk menguji skenario saat seluruh partisi tidak tersedia, Anda dapat mengatur switch ini ke AllReplicas.