Jadi Anda ingin belajar tentang Service Fabric?

Azure Service Fabric adalah platform sistem terdistribusi yang mempermudah pengemasan, penyebaran, dan pengelolaan layanan mikro yang andal dan terukur. Service Fabric memiliki luas permukaan yang luas, namun, dan ada banyak hal yang harus dipelajari. Artikel ini menyediakan sinopsis Service Fabric dan menjelaskan konsep inti, model pemrograman, siklus hidup aplikasi, pengujian, kluster, dan pemantauan kesehatan. Baca Gambaran Umum dan Apa itu layanan mikro? untuk pengenalan dan bagaimana Service Fabric dapat digunakan untuk membuat layanan mikro. Artikel ini tidak berisi daftar konten yang komprehensif, tetapi tidak menautkan ke gambaran umum dan memulai artikel untuk setiap area Service Fabric.

Konsep inti

Terminologi Service Fabric, Model aplikasi, dan Model pemrograman yang didukung memberikan lebih banyak konsep dan deskripsi, tetapi berikut adalah dasar-dasarnya.

Waktu desain: jenis layanan, paket layanan dan manifes, jenis aplikasi, paket aplikasi dan manifes

Jenis layanan adalah nama/versi yang ditetapkan ke paket kode layanan, paket data, dan paket konfigurasi. Ini didefinisikan dalam file ServiceManifest.xml ini. Jenis layanan terdiri dari kode executable dan pengaturan konfigurasi layanan, yang dimuat pada waktu proses, dan data statis yang dikonsumsi oleh layanan.

Paket layanan adalah direktori disk yang berisi file ServiceManifest.xml layanan, yang mereferensikan kode, data statis, dan paket konfigurasi untuk jenis layanan. Misalnya, paket layanan dapat merujuk ke kode, data statis, dan paket konfigurasi yang membentuk layanan database.

Jenis aplikasi adalah nama/versi yang ditetapkan ke kumpulan jenis layanan. Ini didefinisikan dalam file ApplicationManifest.xml ini.

Jenis aplikasi dan jenis layanan Service Fabric

Paket aplikasi adalah direktori disk yang berisi file ApplicationManifest.xml aplikasi, yang mereferensikan paket layanan untuk setiap jenis layanan yang membentuk jenis aplikasi. Misalnya, paket aplikasi untuk jenis aplikasi email dapat berisi referensi ke paket layanan antrean, paket layanan frontend, dan paket layanan database.

File dalam direktori paket aplikasi disalin ke penyimpanan gambar kluster Service Fabric. Anda kemudian dapat membuat aplikasi bernama dari jenis aplikasi ini, yang kemudian berjalan di dalam kluster. Setelah membuat aplikasi bernama, Anda dapat membuat layanan bernama dari salah satu jenis layanan jenis aplikasi.

Jalankan waktu: kluster dan node, aplikasi bernama, layanan bernama, partisi, dan replika

Kluster Service Fabric adalah set komputer virtual yang tersambung dengan jaringan tempat layanan mikro Anda disebarkan dan dikelola. Kluster dapat menskalakan hingga ribuan komputer.

Komputer atau VM yang merupakan bagian dari kluster disebut node. Setiap node diberi nama node (string). Node memiliki karakteristik, seperti properti penempatan. Setiap mesin atau VM memiliki layanan Windows auto-start, FabricHost.exe, yang mulai berjalan saat booting dan kemudian memulai dua executable: Fabric.exe dan FabricGateway.exe. Kedua executable ini membentuk node. Untuk pengembangan atau skenario pengujian, Anda dapat menghosting beberapa node pada satu komputer atau komputer virtual dengan menjalankan beberapa instans Fabric.exe dan FabricGateway.exe.

Aplikasi bernama adalah kumpulan layanan bernama yang melakukan fungsi atau fungsi tertentu. Suatu layanan melakukan fungsi yang lengkap dan standalone (dapat memulai dan berjalan secara terpisah dari layanan lain) dan terdiri dari kode, konfigurasi, dan data. Setelah paket aplikasi disalin ke penyimpanan gambar, Anda membuat contoh aplikasi dalam kluster dengan menentukan jenis aplikasi paket aplikasi (menggunakan nama/versinya). Setiap instans jenis aplikasi diberi nama URI yang terlihat seperti fabric:/MyNamedApp. Dalam kluster, Anda dapat membuat beberapa aplikasi bernama dari satu jenis aplikasi. Anda juga dapat membuat aplikasi bernama dari berbagai jenis aplikasi. Setiap aplikasi bernama dikelola dan di versi independen.

Setelah membuat aplikasi bernama, Anda dapat membuat contoh salah satu jenis layanannya (layanan bernama) dalam kluster dengan menentukan jenis layanan (menggunakan nama/versinya). Setiap instans jenis layanan diberi nama URI yang tercakup dalam URI aplikasi bernama. Misalnya, jika Anda membuat layanan bernama "MyDatabase" dalam aplikasi bernama "MyNamedApp", URI terlihat seperti: fabric:/MyNamedApp/MyDatabase. Dalam aplikasi bernama, Anda dapat membuat satu atau beberapa layanan bernama. Setiap layanan bernama dapat memiliki skema partisi sendiri dan jumlah instans/replika.

Ada dua jenis layanan: stateless dan stateful. Layanan stateless tidak menyimpan status dalam layanan. Layanan stateless tidak memiliki penyimpanan persisten sama sekali atau menyimpan status persisten di layanan penyimpanan eksternal seperti Azure Storage, Azure SQL Database, atau Azure Cosmos DB. Sebuah penyimpanan layanan yang canggih menyatakan dalam layanan dan menggunakan Reliable Collections atau model pemrograman Reliable Actor untuk mengelola status.

Saat membuat layanan bernama, Anda menentukan skema partisi. Layanan dengan sejumlah besar status membagi data di seluruh partisi. Setiap partisi bertanggung jawab atas sebagian dari status lengkap layanan, yang tersebar di node kluster.

Diagram berikut menunjukkan hubungan antara aplikasi dan instans layanan, partisi, dan replika.

Partisi dan replika dalam layanan

Partisi, penskalaan, dan ketersediaan

Partisi tidak unik untuk Service Fabric. Bentuk partisi yang terkenal adalah partisi data, juga dikenal sebagai sharding. Layanan stateful dengan sejumlah besar status membagi data di seluruh partisi. Setiap partisi bertanggung jawab atas sebagian dari status lengkap layanan.

Replika setiap partisi tersebar di node kluster, yang memungkinkan status layanan bernama Anda untuk diskalakan. Ketika kebutuhan data tumbuh, partisi tumbuh, dan Service Fabric menyeimbangkan partisi di seluruh node untuk membuat penggunaan sumber daya perangkat keras yang efisien. Jika Anda menambahkan node baru ke kluster, Service Fabric menyeimbangkan kembali replika partisi di seluruh jumlah node yang ditingkatkan. Kinerja aplikasi secara keseluruhan meningkat dan pertentangan untuk akses ke memori menurun. Jika node dalam kluster tidak digunakan secara efisien, Anda dapat mengurangi jumlah node dalam kluster. Service Fabric kembali menyeimbangkan replika partisi di seluruh penurunan jumlah node untuk memanfaatkan perangkat keras dengan lebih baik pada setiap node.

Dalam partisi, layanan bernama stateless memiliki instans sementara layanan bernama stateful memiliki replika. Biasanya, layanan bernama stateless hanya pernah memiliki satu partisi karena mereka tidak memiliki keadaan internal, meskipun ada pengecualian. Instans partisi menyediakan ketersediaan. Jika satu instans gagal, instans lain terus beroperasi secara normal dan kemudian Service Fabric membuat instans baru. Layanan bernama stateful mempertahankan keadaan mereka dalam replika dan setiap partisi memiliki replica set sendiri. Operasi baca dan tulis dilakukan pada satu replika (disebut Primer). Perubahan status dari operasi tulis direplikasi ke beberapa replika lain (disebut Active Secondaries). Jika replika gagal, Service Fabric membangun replika baru dari replika yang ada.

Layanan mikro stateless dan stateful untuk Service Fabric

Service Fabric memungkinkan Anda untuk membangun aplikasi yang terdiri dari layanan mikro atau kontainer. Layanan mikro stateless (seperti gateway protokol dan proksi web) tidak mempertahankan status yang dapat disenyapkan di luar permintaan dan tanggapannya dari layanan. Peran pekerja Azure Cloud Services adalah contoh layanan tanpa status. Layanan mikro yang kuat (seperti akun pengguna, database, perangkat, keranjang belanja, dan antrean) mempertahankan keadaan yang stabil dan berwibawa di luar permintaan dan responsnya. Aplikasi skala Internet saat ini terdiri dari kombinasi layanan mikro stateless dan stateful.

Pembeda utama Service Fabric adalah dukungan kuat untuk membangun layanan stateful, baik dengan model pemrograman bawaan Service Fabric atau layanan stateful kontainer. Skenario aplikasi menggambarkan skenario di mana layanan stateful digunakan.

Mengapa memiliki layanan mikro yang kuat bersama dengan yang stateless? Dua alasan utamanya adalah:

  • Anda dapat membangun layanan pemrosesan transaksi online (OLTP) dengan throughput tinggi, latensi rendah, toleran terhadap kegagalan dengan menjaga kode dan data tetap dekat pada komputer yang sama. Beberapa contohnya adalah etalase interaktif, pencarian, sistem Internet of Things (IoT), sistem perdagangan, sistem pemrosesan kartu kredit dan deteksi penipuan, dan manajemen catatan pribadi.
  • Anda dapat menyederhanakan desain aplikasi. Layanan mikro yang stateful menghapus kebutuhan akan antrean dan cache tambahan, yang secara tradisional diperlukan untuk memenuhi persyaratan ketersediaan dan latensi dari aplikasi stateless murni. Layanan stateful secara alami ketersediaan tinggi dan latensi rendah, yang mengurangi jumlah bagian bergerak untuk dikelola dalam aplikasi Anda secara keseluruhan.

Model pemrograman yang didukung

Service Fabric menawarkan berbagai cara untuk menulis dan mengelola layanan Anda. Layanan dapat menggunakan API Service Fabric untuk memanfaatkan sepenuhnya fitur platform dan kerangka kerja aplikasi. Layanan juga dapat menjadi program executable yang dikompilasi yang ditulis dalam bahasa apa pun dan dihosting pada kluster Service Fabric. Untuk informasi selengkapnya, lihat Model pemrograman yang didukung.

Kontainer

Secara default, Service Fabric menyebarkan dan mengaktifkan layanan sebagai proses. Service Fabric juga dapat menyebarkan layanan dalam kontainer. Dan yang sanagt penting, Anda dapat mencampur layanan dalam proses, dan layanan dalam kontainer, pada aplikasi yang sama. Service Fabric mendukung penyebaran kontainer Linux dan kontainer Windows di Windows Server 2016. Anda dapat menerapkan aplikasi, layanan stateless, atau layanan stateful yang ada dalam kontainer.

Reliable Service

Reliable Services adalah kerangka kerja ringan untuk menulis layanan yang terintegrasi dengan platform Service Fabric dan mendapatkan manfaat dari serangkaian fitur platform lengkap. Reliable Service dapat stateless (mirip dengan sebagian besar platform layanan, seperti server web atau Peran Pekerja di Azure Cloud Services), di mana status tetap dalam solusi eksternal, seperti Azure DB atau Penyimpanan Tabel Azure. Reliable Service juga dapat dinyatakan, dengan status bertahan langsung dalam layanan itu sendiri menggunakan Reliable Collection. Status dibuat sangat tersedia melalui replikasi dan didistribusikan melalui partisi, semua dikelola secara otomatis oleh Service Fabric.

Reliable Actor

Dibangun di atas Reliable Service, kerangka Kerja Reliable Actor adalah kerangka kerja aplikasi yang mengimplementasikan pola Aktor Virtual, berdasarkan pola desain aktor. Kerangka Kerja Reliable Actor menggunakan unit independen komputasi dan negara dengan eksekusi berulir tunggal yang disebut aktor. Kerangka Kerja Reliable Actor menyediakan komunikasi bawaan untuk aktor dan kegigihan status yang telah ditetapkan dan konfigurasi perluasan skala.

Inti ASP.NET

Service Fabric terintegrasi dengan ASP.NET Core sebagai model pemrograman kelas satu untuk membangun aplikasi web dan API. ASP.NET Core dapat digunakan dalam dua cara berbeda dalam Service Fabric:

  • Dihosting sebagai executable tamu. Ini terutama digunakan untuk menjalankan aplikasi ASP.NET Core yang ada pada Service Fabric tanpa perubahan kode.
  • Jalankan di dalam Reliable Service. Ini memungkinkan integrasi yang lebih baik dengan runtime Service Fabric dan memungkinkan layanan ASP.NET Core stateful.

File executable

Executable tamu adalah executable sewenang-wenang yang ada (ditulis dalam bahasa apa pun) yang dihosting pada kluster Service Fabric bersama layanan lainnya. Executable tamu tidak berintegrasi langsung dengan API Service Fabric. Namun, executable masih mendapat manfaat dari fitur yang ditawarkan platform, seperti kesehatan kustom dan pelaporan beban dan kemudahan layanan untuk ditemukan dengan memanggil API REST. Executable juga memiliki dukungan siklus hidup aplikasi penuh.

Siklus hidup aplikasi

Seperti platform lain, aplikasi pada Service Fabric biasanya melalui fase berikut: desain, pengembangan, pengujian, penyebaran, peningkatan, pemeliharaan, dan penghapusan. Service Fabric memberikan dukungan kelas satu untuk siklus hidup aplikasi cloud penuh, dari pengembangan melalui penyebaran, manajemen harian, dan pemeliharaan hingga penonaktifan akhir. Model layanan memungkinkan beberapa peran berbeda untuk berpartisipasi secara independen dalam siklus hidup aplikasi. Siklus hidup aplikasi Service Fabric memberikan gambaran umum tentang API dan bagaimana mereka digunakan oleh berbagai peran sepanjang fase siklus hidup aplikasi Service Fabric.

Seluruh siklus hidup aplikasi dapat dikelola menggunakan cmdlet PowerShell, perintah CLI, C# API, Java API, dan REST API. Anda juga dapat menyiapkan alur integrasi berkelanjutan/penerapan berkelanjutan menggunakan alat seperti Azure Pipelines atau Jenkins.

Periksa link ini untuk video pelatihan yang menjelaskan cara mengelola siklus hidup aplikasi Anda:

Menguji aplikasi dan layanan

Untuk menciptakan layanan skala cloud yang sesungguhnya, sangat penting untuk memverifikasi bahwa aplikasi dan layanan Anda dapat menahan kegagalan dunia nyata. Fault Analysis Service dirancang untuk menguji layanan yang dibuat di Service Fabric. Dengan Fault Analysis Service, memungkinkan Anda menyebabkan kesalahan yang berarti dan menjalankan skenario pengujian lengkap terhadap aplikasi. Kesalahan dan skenario ini melatih dan memvalidasi berbagai status dan transisi yang akan dialami layanan sepanjang masa, layanan ini berjalan secara terkontrol, aman, dan konsisten.

Tindakan menargetkan layanan untuk pengujian menggunakan kesalahan individual. Pengembang layanan dapat menggunakan layanan ini sebagai blok penyusun untuk menulis skenario yang rumit. Contoh kesalahan yang disimulasikan adalah:

  • Mulai ulang node untuk menyimulasikan sejumlah situasi saat mesin atau VM di-boot ulang.
  • Pindahkan replika layanan stateful untuk menyimulasikan load balancing, failover, atau peningkatan aplikasi.
  • Meminta kuorum yang hilang pada layanan stateful untuk membuat situasi di mana operasi tulis tidak dapat dilanjutkan karena replika "cadangan" atau "sekunder" tidak cukup untuk menerima data baru.
  • Meminta data yang hilang pada layanan berstatus untuk membuat situasi di mana semua status dalam memori benar-benar terhapus.

Skenario adalah operasi kompleks yang terdiri dari satu atau lebih tindakan. Fault Analysis Service menyediakan dua skenario lengkap bawaan:

  • Skenario kekacauan- mensimulasikan kesalahan terus menerus dan saling berselang (baik ringan maupun berat) di seluruh kluster selama jangka waktu yang lama.
  • Skenario failover- versi skenario uji kekacauan yang menargetkan partisi layanan tertentu sambil membiarkan layanan lain tidak terpengaruh.

Kluster

Kluster Service Fabric adalah set komputer virtual yang tersambung dengan jaringan tempat layanan mikro Anda disebarkan dan dikelola. Kluster dapat menskalakan hingga ribuan komputer. Komputer atau komputer virtual yang merupakan bagian dari kluster disebut node kluster. Setiap node diberi nama node (string). Node memiliki karakteristik, seperti properti penempatan. Setiap mesin atau VM memiliki layanan auto-start, FabricHost.exe, yang mulai berjalan saat booting dan kemudian memulai dua executable: Fabric.exe dan FabricGateway.exe. Kedua executable ini membentuk node. Untuk skenario pengujian, Anda dapat menghosting beberapa node pada satu komputer atau komputer virtual dengan menjalankan beberapa instans Fabric.exe dan FabricGateway.exe.

Kluster Service Fabric dapat dibuat pada komputer virtual atau fisik yang menjalankan Windows Server atau Linux. Anda dapat menyebarkan dan menjalankan aplikasi Service Fabric di lingkungan mana pun tempat Anda memiliki seperangkat komputer Windows Server atau Linux yang saling terhubung: lokal, di Microsoft Azure, atau di penyedia cloud apa pun.

Periksa link ini untuk video pelatihan yang menjelaskan arsitektur Service Fabric, konsep intinya, dan banyak fitur service fabric lainnya

Kluster di Azure

Menjalankan kluster Service Fabric di Azure menyediakan integrasi dengan fitur dan layanan Azure lainnya, yang membuat operasi dan manajemen kluster lebih mudah dan andal. Kluster adalah sumber daya Azure Resource Manager, sehingga Anda bisa mencontoh kluster seperti sumber daya lainnya di Azure. Resource Manager juga menyediakan manajemen yang mudah dari semua sumber daya yang digunakan oleh kluster sebagai satu unit. Kluster di Azure terintegrasi dengan diagnostik Azure dan log Azure Monitor. Jenis node kluster adalah set skala komputer virtual, sehingga fungsionalitas autoscaling tertanam.

Anda dapat membuat kluster di Azure melalui portal Microsoft Azure, dari templat, atau dari Visual Studio.

Service Fabric di Linux memungkinkan Anda untuk membangun, menyebarkan, dan mengelola aplikasi yang sangat tersedia dan sangat dapat diskalakan di Linux, seperti yang Anda lakukan di Windows. Kerangka kerja Service Fabric (Reliable Service dan Reliable Actor) tersedia di Java di Linux, selain C# (.NET Core). Anda juga dapat membangun layanan executablec tamu dengan bahasa atau kerangka kerja apa pun. Orkestrasi kontainer Docker juga didukung. Kontainer Docker dapat menjalankan executable tamu atau layanan Service Fabric native, yang menggunakan kerangka kerja Service Fabric. Untuk informasi lebih lanjut, baca tentang Service Fabric di Linux.

Ada beberapa fitur yang didukung di Windows, tetapi tidak di Linux. Untuk mempelajari selengkapnya, baca Perbedaan antara Service Fabric di Linux dan Windows.

Kluster standalone

Service Fabric menyediakan paket penginstalan bagi Anda untuk membuat kluster Service Fabric standalone lokal atau di penyedia cloud apa pun. Kluster standalone memberi Anda kebebasan untuk menghosting kluster di mana pun Anda inginkan. Jika data Anda tunduk pada kepatuhan atau kendala peraturan, atau Anda ingin menjaga data Anda tetap lokal, Anda dapat meng-host kluster dan aplikasi Anda sendiri. Aplikasi Service Fabric dapat berjalan di beberapa lingkungan hosting tanpa perubahan, sehingga pengetahuan Anda tentang membangun aplikasi membawa lebih dari satu lingkungan hosting ke lingkungan hosting lainnya.

Membuat kluster standalone Service Fabric pertama Anda

Kluster standalone Linux belum didukung.

Keamanan kluster

Kluster harus diamankan untuk mencegah pengguna yang tidak berwenang terhubung ke kluster Anda, terutama ketika memiliki beban kerja produksi yang berjalan di atasnya. Meskipun dimungkinkan untuk membuat kluster yang tidak aman, melakukannya memungkinkan pengguna anonim untuk terhubung ke sana jika titik akhir manajemen terpapar ke internet publik. Tidak dimungkinkan untuk kemudian mengaktifkan keamanan pada kluster yang tidak aman: keamanan kluster diaktifkan pada waktu pembuatan kluster.

Skenario keamanan kluster adalah:

  • Keamanan node-ke-node
  • Keamanan client-to-node
  • Kontrol akses berbasis peran Service Fabric

Untuk informasi selengkapnya, baca Mengamankan kluster.

Penskalaan

Jika Anda menambahkan node baru ke kluster, Service Fabric menyeimbangkan kembali replika dan instans partisi di seluruh jumlah node yang ditingkatkan. Kinerja aplikasi secara keseluruhan meningkat dan pertentangan untuk akses ke memori menurun. Jika node dalam kluster tidak digunakan secara efisien, Anda dapat mengurangi jumlah node dalam kluster. Service Fabric kembali menyeimbangkan replika partisi dan instans di seluruh penurunan jumlah node untuk memanfaatkan perangkat keras dengan lebih baik pada setiap node. Anda dapat menskalakan kluster di Azure baik secara manual maupun terprogram. Kluster standalone dapat diskalakan secara manual.

Peningkatan kluster

Secara berkala, versi baru runtime Service Fabric dirilis. Lakukan runtime, atau fabric, tingkatkan pada kluster Anda sehingga Anda selalu menjalankan versi yang didukung. Selain peningkatan fabric, Anda juga dapat memperbarui konfigurasi kluster seperti sertifikat atau port aplikasi.

Kluster Service Fabric adalah sumber daya yang Anda miliki, tetapi sebagian dikelola oleh Microsoft. Microsoft bertanggung jawab untuk patching OS yang mendasarinya dan melakukan peningkatan fabric pada kluster Anda. Anda dapat mengatur kluster Anda untuk menerima peningkatan fabric otomatis, ketika Microsoft merilis versi baru, atau memilih untuk memilih versi fabric yang didukung yang Anda inginkan. Peningkatan fabric dan konfigurasi dapat diatur melalui portal Microsoft Azure atau melalui Resource Manager. Untuk informasi selengkapnya, baca Meningkatkan kluster Service Fabric.

Kluster standalone adalah sumber daya yang sepenuhnya Anda miliki. Anda bertanggung jawab untuk menambal OS yang mendasarinya dan memulai peningkatan fabric. Jika kluster Anda dapat terhubung ke https://www.microsoft.com/download, Anda dapat mengatur kluster Anda untuk secara otomatis mengunduh dan menyediakan paket runtime Service Fabric baru. Anda kemudian akan memulai peningkatan. Jika kluster Anda tidak dapat mengakses https://www.microsoft.com/download, Anda dapat mengunduh paket runtime baru secara manual dari mesin yang terhubung ke internet dan kemudian memulai peningkatan. Untuk informasi selengkapnya, baca Meningkatkan kluster Service Fabric standalone.

Pemantauan kesehatan

Service Fabric memperkenalkan model kesehatan yang dirancang untuk menandai kluster dan kondisi aplikasi yang tidak sehat pada entitas tertentu (seperti node kluster dan replika layanan). Model kesehatan menggunakan reporter kesehatan (komponen sistem dan pengawas). Tujuannya adalah diagnosis dan perbaikan yang mudah dan cepat. Penulis layanan perlu berpikir di muka tentang kesehatan dan cara merancang pelaporan kesehatan. Kondisi apa pun yang dapat berdampak pada kesehatan harus dilaporkan, terutama jika dapat membantu menandai masalah yang dekat dengan akar. Informasi kesehatan dapat menghemat waktu dan upaya debugging dan investigasi setelah layanan aktif dan berjalan secara terskalakan dalam produksi.

Wartawan Service Fabric memantau kondisi yang diidentifikasi menarik. Mereka melaporkan kondisi tersebut berdasarkan pandangan lokal mereka. Penyimpanan kesehatan menggabungkan data kesehatan yang dikirim oleh semua wartawan untuk menentukan apakah entitas sehat secara global. Model ini dimaksudkan untuk menjadi kaya, fleksibel, dan mudah digunakan. Kualitas laporan kesehatan menentukan keakuratan pandangan kesehatan kluster. Positif palsu yang salah menunjukkan masalah yang tidak sehat dapat berdampak negatif pada peningkatan atau layanan lain yang menggunakan data kesehatan. Contoh layanan tersebut adalah layanan perbaikan dan mekanisme peringatan. Oleh karena itu, beberapa pemikiran diperlukan untuk memberikan laporan bahwa menangkap kondisi yang menarik dengan cara terbaik.

Pelaporan dapat dilakukan dari:

  • Replika atau instans layanan Service Fabric yang dipantau.
  • Pengawas internal yang digunakan sebagai layanan Service Fabric (misalnya, layanan stateless Service Fabric yang memantau kondisi dan mengeluarkan laporan). Pengawas dapat digunakan pada semua node atau dapat diafinitisasi ke layanan yang dipantau.
  • Pengawas internal yang berjalan pada node Service Fabric tetapi tidak diimplementasikan sebagai layanan Service Fabric.
  • Pengawas eksternal yang menyelidiki sumber daya dari luar kluster Service Fabric (misalnya, layanan pemantauan seperti Gomez).

Di luar kotak, komponen Service Fabric melaporkan kesehatan pada semua entitas dalam kluster. Laporan kesehatan sistem memberikan visibilitas ke dalam fungsi kluster dan aplikasi dan masalah bendera melalui kesehatan. Untuk aplikasi dan layanan, laporan kesehatan sistem memverifikasi bahwa entitas diimplementasikan dan berperilaku benar dari perspektif runtime Service Fabric. Laporan tidak memberikan pemantauan kesehatan terhadap logika bisnis layanan atau mendeteksi proses yang berhenti merespons. Untuk menambahkan informasi kesehatan khusus untuk logika layanan Anda, terapkan pelaporan kesehatan kustom di layanan Anda.

Service Fabric menyediakan beberapa cara untuk melihat laporan kesehatan yang dikumpulkan di penyimpanan kesehatan:

Periksa halaman ini untuk video pelatihan yang menjelaskan model kesehatan Service Fabric dan cara penggunaannya:

Pemantauan dan diagnostik

Pemantauan dan diagnostik sangat penting untuk mengembangkan, menguji, dan menerapkan aplikasi dan layanan di lingkungan apa pun. Solusi Service Fabric bekerja paling baik ketika Anda merencanakan dan menerapkan pemantauan dan diagnostik yang membantu memastikan aplikasi dan layanan bekerja seperti yang diharapkan dalam lingkungan pengembangan lokal atau dalam produksi.

Tujuan utama pemantauan dan diagnostik adalah untuk:

  • Mendeteksi dan mendiagnosis masalah perangkat keras dan infrastruktur
  • Mendeteksi masalah perangkat lunak dan aplikasi, mengurangi waktu henti layanan
  • Memahami konsumsi sumber daya dan membantu mendorong keputusan operasi
  • Mengoptimalkan kinerja aplikasi, layanan, dan infrastruktur
  • Menghasilkan wawasan bisnis dan identifikasi area peningkatan

Alur kerja keseluruhan pemantauan dan diagnostik terdiri dari tiga langkah:

  1. Pembuatan peristiwa: ini termasuk peristiwa (log, jejak, peristiwa kustom) di infrastruktur (kluster), platform, dan tingkat aplikasi/layanan
  2. Agregasi peristiwa: peristiwa yang dihasilkan harus dikumpulkan dan diagregasikan sebelum dapat ditampilkan
  3. Analisis: peristiwa perlu divisualisasikan dan dapat diakses dalam beberapa format, untuk memungkinkan analisis dan tampilan sesuai kebutuhan

Beberapa produk tersedia yang mencakup ketiga area ini, dan Anda bebas memilih teknologi yang berbeda untuk masing-masing. Untuk informasi selengkapnya, baca Pemantauan dan diagnostik untuk Azure Service Fabric.

Langkah berikutnya