Gambaran umum Reliable Service

  • Artikel

Azure Service Fabric menyederhanakan penulisan dan pengelolaan layanan tanpa status dan berstatus. Topik ini mencakup:

  • Model pemrograman Reliable Service untuk layanan tanpa status dan berstatus.
  • Pilihan yang harus Anda ambil saat menulis Reliable Service.
  • Beberapa skenario dan contoh kapan menggunakan Reliable Service dan bagaimana penulisannya.

Reliable Services adalah salah satu model pemrograman yang tersedia di Service Fabric. Selain itu ada model pemrograman Reliable Actor, yang menyediakan kerangka kerja aplikasi Virtual Actor di atas model Reliable Service. Untuk informasi lebih lanjut tentang Reliable Actor, lihat Pengenalan Reliable Actor Service Fabric.

Service Fabric mengelola masa pakai layanan, dari penyediaan dan penyebaran melalui peningkatan dan penghapusan, melalui manajemen aplikasi Service Fabric.

Apa itu Reliable Service

Reliable Service memberikan model pemrograman tingkat atas yang sederhana, kuat, untuk membantu mengekspresikan apa yang penting bagi aplikasi Anda. Dengan model pemrograman Reliable Service, Anda mendapatkan:

  • Akses ke API Service Fabric. Tidak seperti layanan Service Fabric yang dimodelkan sebagai Guest Executable, Reliable Service dapat menggunakan API Service Fabric secara langsung. Ini memungkinkan layanan untuk:
    • Mengkueri sistem
    • Melaporkan kesehatan tentang entitas dalam kluster
    • Menerima pemberitahuan tentang perubahan konfigurasi dan kode
    • Menemukan dan berkomunikasi dengan layanan lain,
    • Gunakan Reliable Collection
    • Akses banyak kemampuan lainnya, semuanya dari model pemrograman kelas satu dalam beberapa bahasa pemrograman.
  • Model sederhana untuk menjalankan kode Anda sendiri yang terasa seperti model pemrograman lainnya yang sudah tidak asing. Kode Anda memiliki titik masuk yang terdefinisi dengan baik dan siklus hidup yang dikelola dengan mudah.
  • Model komunikasi yang bisa disambungkan. Gunakan transportasi pilihan Anda, seperti HTTP dengan Web API, WebSocket, protokol TCP kustom, atau yang lainnya. Reliable Service menyediakan beberapa opsi luar biasa hebat yang dapat Anda gunakan, atau Anda dapat menyediakan sendiri.
  • Untuk layanan berstatus, model pemrograman Reliable Service memungkinkan Anda untuk secara konsisten dan andal menyimpan status Anda tepat di dalam layanan Anda menggunakan Reliable Collection. Reliable Collection adalah set kelas koleksi yang sangat tersedia dan dapat diandalkan yang nantinya tidak asing lagi bagi siapa saja yang menggunakan koleksi C#. Secara tradisional, layanan diperlukan sistem eksternal untuk manajemen status yang andal. Dengan Reliable Collection, Anda dapat menyimpan status di samping komputasi dengan ketersediaan dan keandalan tinggi yang sama dengan yang Anda harapkan dari penyimpanan eksternal dengan ketersediaan tinggi. Model ini juga meningkatkan latensi karena Anda turut menemukan kondisi dan status yang diperlukan agar berfungsi.

Apa yang membuat Reliable Service berbeda

Reliable Service berbeda dari layanan yang mungkin telah Anda tulis sebelumnya, karena Service Fabric menyediakan:

  • Keandalan - Layanan Anda tetap terjaga bahkan di lingkungan yang tidak dapat diandalkan di mana komputer Anda gagal atau mengalami masalah jaringan, atau dalam kasus di mana layanan itu sendiri mengalami kesalahan dan crash atau gagal. Untuk layanan berstatus, status Anda dipertahankan bahkan saat adanya kegagalan jaringan atau lainnya.
  • Ketersediaan - Layanan Anda dapat dijangkau dan responsif. Service Fabric mempertahankan jumlah salinan yang Anda inginkan.
  • Skalabilitas - Layanan yang dipisahkan dari perangkat keras tertentu, dan bisa tumbuh atau menyusut sesuai kebutuhan melalui penambahan atau penghapusan perangkat keras atau sumber daya lainnya. Layanan mudah dipartisi (terutama dalam kasus berstatus) untuk memastikan bahwa layanan dapat menskalakan dan menangani kegagalan parsial. Layanan dapat dibuat dan dihapus secara dinamis melalui kode, memungkinkan lebih banyak instans untuk dipintal sesuai kebutuhan, misalnya sebagai tanggapan terhadap permintaan pelanggan. Terakhir, Service Fabric mendorong layanan menjadi ringan. Service Fabric memungkinkan ribuan layanan untuk disediakan dalam satu proses, dibandingkan mengharuskan atau mendedikasikan seluruh instans OS atau proses untuk satu contoh layanan.
  • Konsistensi - Setiap informasi yang disimpan dalam Reliable Service dapat dijamin konsisten. Ini berlaku bahkan di beberapa Reliable Collection dalam layanan. Perubahan di seluruh koleksi dalam layanan dapat dilakukan dengan cara transaksi atomik.

Periksa halaman ini untuk video pelatihan guna mempelajari tentang model pemrograman layanan andal Service Fabric dan cara aplikasi Anda dapat berintegrasi lebih erat dengan runtime Service Fabric dengan model pemrograman .NET ini:

Siklus hidup layanan

Baik layanan Anda berstatus atau tanpa status, Reliable Service menyediakan siklus hidup sederhana yang memungkinkan Anda dengan cepat menyambungkan kode dan memulai. Mendapatkan layanan baru dan berjalan mengharuskan Anda untuk menerapkan dua metode:

  • CreateServiceReplicaListeners/CreateServiceInstanceListeners - Metode ini adalah tempat layanan menentukan tumpukan komunikasi yang ingin digunakan. Tumpukan komunikasi, seperti Web API, menentukan titik akhir mendengarkan atau titik akhir untuk layanan (cara klien menjangkau layanan). Ini juga menjelaskan bagaimana pesan yang muncul berinteraksi dengan sisa kode layanan.
  • RunAsync - Metode ini adalah tempat layanan Anda menjalankan logika bisnisnya, dan tempat memulai tugas latar belakang apa pun yang harus dijalankan seumur hidup layanan. Token pembatalan yang disediakan adalah sinyal kapan pekerjaan itu harus dihentikan. Misalnya, jika layanan perlu menarik pesan dari Reliable Queue dan memrosesnya, di sinilah pekerjaan itu dilakukan.

Jika Anda belajar tentang Reliable Service untuk pertama kalinya, lanjutkan membaca! Jika Anda mencari panduan terperinci tentang siklus hidup Reliable Service, lihat gambaran umum siklus hidup Reliable Service.

Contoh layanan

Mari kita lihat lebih dekat bagaimana model Reliable Service bekerja dengan layanan berstatus dan tanpa status.

Reliable Service Tanpa Status

Layanan tanpa status adalah layanan yang tidak memiliki status yang pelihara dalam panggilan seluruh layanan. Keadaan yang ada sepenuhnya bersifat sekali pakai dan tidak memerlukan sinkronisasi, replikasi, kegigihan, atau ketersediaan tinggi.

Misalnya, anggap kalkulator yang tidak memiliki memori dan menerima semua syarat dan operasi untuk dilakukan sekaligus.

Dalam hal ini, RunAsync() (C#) atau runAsync() (Java) layanan boleh kosong, karena tidak ada pemrosesan tugas latar belakang yang perlu dilakukan layanan. Saat layanan kalkulator dibuat, maka kembali sebagai ICommunicationListener (C#) atau CommunicationListener (Java) (misalnya Web API) yang membuka titik akhir mendengarkan pada beberapa port. Titik akhir mendengarkan ini terhubung ke metode perhitungan yang berbeda (misalnya: "Add(n1, n2)") yang menentukan API publik kalkulator.

Ketika panggilan dilakukan dari klien, metode yang sesuai dipanggil, dan layanan kalkulator melakukan operasi pada data yang disediakan dan mengembalikan hasilnya. Ini tidak menyimpan status apa pun.

Tidak menyimpan status internal menjadikan contoh kalkulator ini sederhana. Tetapi sebagian besar layanan tidak benar-benar tanpa status. Sebaliknya, mereka eksternalisasi status mereka ke beberapa penyimpanan lain. (Misalnya, aplikasi web apa pun yang bergantung pada menjaga status sesi pada penyimpanan pendukung atau cache tidak tanpa status.)

Contoh umum tentang bagaimana layanan tanpa status digunakan dalam Service Fabric adalah sebagai front-end yang mengekspos API yang menghadap publik untuk aplikasi web. Layanan front-end kemudian berbicara dengan layanan berstatus untuk menyelesaikan permintaan pengguna. Dalam hal ini, panggilan dari klien diarahkan ke port yang dikenal, seperti 80, di mana layanan tanpa status mendengarkan. Layanan tanpa status ini menerima panggilan dan menentukan apakah panggilan itu berasal dari pihak tepercaya dan layanan mana yang diperuntukkan. Kemudian, layanan tanpa status meneruskan panggilan ke partisi yang tepat dari layanan berstatus dan menunggu tanggapan. Ketika layanan tanpa status menerima respons, layanan akan membalas klien asli. Contoh untuk layanan semacam ini adalah sampel Memulai Service Fabric (C# / Java), di antara sampel Service Fabric dalam repositori.

Reliable Service Berstatus

Layanan Berstatus adalah layanan yang harus memiliki beberapa porsi status yang terus konsisten dan ada agar layanan berfungsi. Pertimbangkan layanan yang terus-menerus melakukan komputasi rata-rata bergulir dari beberapa nilai berdasarkan pembaruan yang diterima. Untuk melakukan ini, maka harus memiliki set terbaru permintaan masuk yang perlu diproses dan rata-rata saat ini. Layanan apa pun yang mengambil, memproses, dan menyimpan informasi di penyimpanan eksternal (seperti blob Azure atau penyimpanan tabel saat ini) berstatus. Itu hanya menjaga statusnya di penyimpanan status eksternal.

Sebagian besar layanan saat ini menyimpan status mereka secara eksternal, karena penyimpanan eksternal yang memberikan keandalan, ketersediaan, skalabilitas, dan konsistensi untuk status tersebut. Dalam Service Fabric, layanan tidak diperlukan untuk menyimpan statusnya secara eksternal. Service Fabric mengurus persyaratan ini untuk kode layanan dan status layanan.

Katakanlah kita ingin menulis layanan yang memproses gambar. Untuk melakukannya, layanan mengambil gambar dan rangkaian konversi untuk dilakukan pada gambar tersebut. Layanan ini mengembalikan pendengar komunikasi (misalnya webAPI) yang mengekspos API seperti ConvertImage(Image i, IList<Conversion> conversions). Ketika menerima permintaan, layanan menyimpannya dalam IReliableQueue, lalu mengembalikan beberapa ID ke klien agar bisa melacak permintaan.

Dalam layanan ini, RunAsync() mungkin lebih kompleks. Layanan ini memiliki perulangan di dalam RunAsync() yang menarik permintaan IReliableQueue keluar dan melakukan konversi yang diminta. Hasilnya disimpan dalam IReliableDictionary sehingga saat klien datang kembali, gambarnya sudah dikonversi. Untuk memastikan bahwa gambar tidak hilang bahkan jika terjadi kegagalan, Reliable Service ini akan menarik keluar dari antrean, melakukan konversi, dan menyimpan semua hasilnya dalam satu transaksi. Dalam hal ini, pesan dihapus dari antrean dan hasilnya disimpan dalam kamus hasil hanya saat konversi selesai. Atau, layanan dapat menarik gambar keluar dari antrean dan segera menyimpannya di penyimpanan jarak jauh. Ini mengurangi jumlah status yang harus dikelola layanan, tetapi meningkatkan kompleksitas karena layanan harus menjaga metadata yang diperlukan untuk mengelola penyimpanan jarak jauh. Dengan pendekatan apa pun, jika dalam prosesnya terjadi kegagalan, permintaan tetap dalam antrean menunggu untuk diproses.

Meskipun layanan ini terdengar layanan .NET biasa, perbedaannya adalah struktur data yang digunakan (IReliableQueue dan IReliableDictionary) yang disediakan oleh Service Fabric, dan sangat dapat diandalkan, tersedia, dan konsisten.

Waktu untuk menggunakan API Reliable Service

Pertimbangkan API Reliable Service jika:

  • Anda ingin kode layanan Anda (dan secara opsional status) sangat dapat diandalkan dan tersedia.
  • Anda memerlukan jaminan transaksi di beberapa unit status (misalnya, pesanan dan item baris pesanan).
  • Status aplikasi Anda dapat dimodelkan secara alami sebagai Kamus dan Reliable Collection.
  • Kode atau status aplikasi Anda harus memiliki ketersediaan tinggi dengan pembacaan dan penulisan latensi rendah.
  • Aplikasi Anda perlu mengontrol konkurensi atau granularitas operasi yang ditransaksikan pada satu atau beberapa Reliable Collection.
  • Anda ingin mengelola komunikasi atau mengontrol skema partisi untuk layanan Anda.
  • Kode Anda memerlukan lingkungan runtime dirangkai bebas.
  • Aplikasi Anda perlu membuat atau menghancurkan Reliable Dictionary atau Antrean atau seluruh Layanan saat runtime.
  • Anda perlu mengontrol pencadangan yang disediakan Service Fabric secara terprogram dan memulihkan fitur untuk status layanan Anda.
  • Aplikasi Anda perlu mempertahankan riwayat perubahan untuk unit statusnya.
  • Anda ingin mengembangkan atau menggunakan penyedia status kustom yang dikembangkan pihak ketiga.

Langkah berikutnya