Edit

Bagikan melalui

Arsitektur layanan mikro di Azure Service Fabric

Azure API Management
Azure Key Vault
Azure Monitor
Azure Pipelines
Azure Service Fabric

Arsitektur referensi ini menunjukkan arsitektur layanan mikro yang diterapkan ke Azure Service Fabric. Ini menggambarkan konfigurasi dasar yang dapat menjadi titik awal untuk sebagian besar penyebaran.

Logo GitHub Implementasi referensi arsitektur ini tersedia di GitHub.

Sistem

Diagram yang memperlihatkan arsitektur referensi Service Fabric.

Unduh file Visio arsitektur ini.

Catatan

Artikel ini fokus pada Layanan Terpercaya model pemrograman untuk Service Fabric. Menggunakan Service Fabric untuk menyebarkan dan mengelola kontainer berada di luar cakupan artikel ini.

Alur kerja

Arsitektur ini terdiri dari komponen berikut. Untuk istilah lain, lihat Service Fabric gambaran umum terminologi.

  • Kluster Service Fabric. Kluster adalah sekumpulan komputer virtual (VM) yang terhubung dengan jaringan tempat Anda menyebarkan dan mengelola layanan mikro Anda.

  • Set skala mesin virtual. Set skala komputer virtual memungkinkan Anda membuat dan mengelola sekelompok VM yang identik, seimbang beban, dan penskalaan otomatis. Sumber daya komputasi ini juga menyediakan domain kesalahan dan peningkatan.

  • Simpul. Simpul adalah VM yang termasuk dalam kluster Service Fabric.

  • Jenis simpul. Jenis simpul mewakili set skala mesin virtual yang menyebarkan kumpulan simpul. Sebuah kluster Service Fabric memiliki setidaknya satu jenis simpul.

    Dalam kluster yang memiliki beberapa jenis node, satu harus dinyatakan sebagai jenis node utama. Jenis simpul utama di kluster berjalan pada sistem layanan Service Fabric. Layanan ini menyediakan kemampuan platform Service Fabric. Jenis node utama juga bertindak sebagai node seed, yang merupakan node yang mempertahankan ketersediaan kluster yang mendasar.

    Konfigurasikan jenis node tambahan untuk menjalankan layanan Anda.

  • Layanan. Layanan melakukan fungsi lengkap dan mandiri yang dapat memulai dan menjalankan layanan lain secara independen. Contoh layanan akan diterapkan ke simpul dan kluster. Ada dua varietas layanan dalam Service Fabric:

    • Layanan tanpa status. Layanan tanpa status tidak mempertahankan negara dalam layanan. Jika persistensi status diperlukan, maka status ditulis dan diambil dari toko eksternal, seperti Azure Cosmos DB.
    • Layanan stateful. Lyanan negara disimpan dalam layanan itu sendiri. Sebagian besar layanan stateful menerapkan ini melalui Reliable Collections di Service Fabric.

  • Explorer Service Fabric. Service Fabric Explorer (SFX) adalah alat sumber terbuka untuk memeriksa dan mengelola kluster Azure Service Fabric.

  • Azure Pipelines. Azure Pipelines adalah bagian dari Azure DevOps Services dan menjalankan build, pengujian, dan penyebaran otomatis. Anda juga dapat menggunakan solusi integrasi berkelanjutan dan pengiriman berkelanjutan (CI/CD) pihak ketiga seperti Jenkins.

  • Azure Monitor. Azure Monitormengumpulkan dan menyimpan metrik dan log, telemetri aplikasi, dan metrik platform untuk layanan Azure. Anda dapat menggunakan data ini untuk memantau aplikasi, menyiapkan peringatan dan dasbor, serta melakukan analisis akar penyebab kegagalan. Azure Monitor terintegrasi dengan Service Fabric untuk mengumpulkan metrik dari pengontrol, simpul, dan kontainer, bersama dengan log kontainer dan simpul.

  • Azure Key Vault. Gunakan Key Vault untuk menyimpan rahasia aplikasi apa pun yang digunakan layanan mikro, seperti string koneksi.

  • Azure API Management. Dalam arsitektur ini, API Management bertindak sebagai gateway API yang menerima permintaan dari klien dan merutekannya ke layanan Anda.

Pertimbangan

Pertimbangan ini mengimplementasikan pilar Azure Well-Architected Framework, yang merupakan serangkaian tenet panduan untuk meningkatkan kualitas beban kerja.

Pertimbangan Desain

Arsitektur referensi ini difokuskan pada arsitektur layanan mikro. Microservice adalah unit kode kecil yang versi independen. Ini dapat ditemukan melalui mekanisme penemuan layanan dan dapat berkomunikasi dengan layanan lain melalui API. Setiap layanan mandiri dan harus menerapkan kemampuan bisnis tunggal. Untuk informasi selengkapnya tentang cara menguraikan domain aplikasi Anda menjadi layanan mikro, lihat Menggunakan analisis domain untuk memodelkan layanan mikro.

Service Fabric menyediakan infrastruktur untuk membangun, menyebarkan, dan meningkatkan layanan mikro secara efisien. Ini juga menyediakan opsi untuk penskalaan otomatis, mengelola status, memantau kesehatan, dan memulai ulang layanan jika terjadi kegagalan.

Service Fabric mengikuti model aplikasi di mana aplikasi adalah kumpulan layanan mikro. Aplikasi ini dijelaskan dalam file manifes aplikasi. File ini mendefinisikan jenis layanan yang dikandung aplikasi, bersama dengan pointer ke paket layanan independen.

Paket aplikasi juga biasanya berisi parameter yang berfungsi sebagai penimpaan untuk pengaturan tertentu yang digunakan layanan. Setiap paket layanan memiliki file manifes yang menjelaskan file fisik dan folder yang diperlukan untuk menjalankan layanan tersebut, termasuk biner, file konfigurasi, dan data baca-saja. Layanan dan aplikasi versi independen dan dapat diupgrade.

Secara opsional, manifes aplikasi dapat menjelaskan layanan yang secara otomatis disediakan ketika instance aplikasi dibuat. Ini disebut layanan default. Dalam hal ini, manifes aplikasi juga menjelaskan bagaimana layanan ini harus dibuat. Informasi tersebut mencakup nama layanan, jumlah instans, kebijakan keamanan atau isolasi, dan batasan penempatan.

Catatan

Hindari menggunakan layanan default jika Anda ingin mengontrol masa pakai layanan Anda. Layanan default dibuat saat aplikasi dibuat, dan berjalan selama aplikasi berjalan.

Untuk informasi selengkapnya, lihat Jadi Anda ingin mempelajari tentang Service Fabric?.

Model pengemasan aplikasi ke layanan

Prinsip layanan mikro adalah bahwa setiap layanan dapat digunakan secara independen. Di Service Fabric, jika Anda mengelompokkan semua layanan Anda ke dalam satu paket aplikasi, dan satu layanan gagal ditingkatkan, seluruh peningkatan aplikasi akan digulung balik. Putar kembali itu mencegah layanan lain ditingkatkan.

Oleh karena itu, dalam arsitektur layanan mikro, kami sarankan menggunakan beberapa paket aplikasi. Masukkan satu atau lebih jenis layanan yang terkait erat ke dalam satu jenis aplikasi. Misalnya, letakkan jenis layanan dalam jenis aplikasi yang sama jika tim Anda bertanggung jawab atas serangkaian layanan yang memiliki salah satu atribut ini:

  • Mereka berjalan selama durasi yang sama dan perlu diperbarui pada saat yang sama.
  • Mereka memiliki siklus hidup yang sama.
  • Mereka berbagi sumber daya seperti dependensi atau konfigurasi.

Model Pemrograman Service Fabric

Ketika Anda menambahkan layanan mikro ke aplikasi Service Fabric, putuskan apakah ia memiliki status atau data yang perlu dibuat sangat tersedia dan dapat diandalkan. Jika demikian, dapatkah menyimpan data secara eksternal atau data yang terkandung sebagai bagian dari layanan? Pilih layanan stateless jika Anda tidak perlu menyimpan data atau Anda ingin menyimpan data di penyimpanan eksternal. Pertimbangkan untuk memilih layanan stateful jika salah satu pernyataan ini berlaku:

  • Anda ingin mempertahankan status atau data sebagai bagian dari layanan. Misalnya, Anda memerlukan data tersebut untuk berada dalam memori yang dekat dengan kode.
  • Anda tidak dapat mentolerir dependensi pada penyimpanan eksternal.

Jika Anda memiliki kode yang ada yang ingin Anda jalankan di Service Fabric, Anda dapat menjalankannya sebagai executable tamu: executable arbitrer yang berjalan sebagai layanan. Atau, Anda dapat mengemas executable dalam kontainer yang memiliki semua dependensi yang Anda butuhkan untuk penyebaran.

Model Service Fabric baik kontainer dan executable tamu sebagai layanan tanpa status. Untuk panduan tentang memilih model, lihat Gambaran umum model pemrograman Service Fabric.

Anda bertanggung jawab untuk mempertahankan lingkungan tempat tamu dapat dieksekusi berjalan. Misalnya, misalkan executable tamu memerlukan Python. Jika executable tidak mandiri, Anda perlu memastikan bahwa versi Python yang diperlukan sudah diinstal sebelumnya di lingkungan. Service Fabric tidak mengelola lingkungan. Azure menawarkan beberapa mekanisme untuk mengatur lingkungan, termasuk gambar dan ekstensi mesin virtual khusus.

Untuk mengakses executable tamu melalui proksi terbalik, pastikan Anda telah menambahkan UriScheme atribut ke Endpoint elemen dalam manifes layanan guest executable.

    <Endpoints>
      <Endpoint Name="MyGuestExeTypeEndpoint" Port="8090" Protocol="http" UriScheme="http" PathSuffix="api" Type="Input"/>
    </Endpoints>

Jika layanan memiliki rute tambahan, tentukan rute dalam PathSuffix nilai . Nilai tidak boleh diawali atau diakhiri dengan garis miring (/). Cara lain adalah dengan menambahkan rute dalam nama layanan.

    <Endpoints>
      <Endpoint Name="MyGuestExeTypeEndpoint" Port="8090" Protocol="http" PathSuffix="api" Type="Input"/>
    </Endpoints>

Untuk informasi selengkapnya, lihat:

Gateway API

Gateway API berada di antara klien eksternal dan layanan mikro. Ini berfungsi sebagai proksi terbalik, merutekan permintaan dari klien ke layanan mikro. Ini mungkin juga melakukan tugas lintas pemotongan seperti autentikasi, penghentian SSL, dan pembatasan tarif.

Kami merekomendasikan Azure API Management untuk sebagian besar skenario, tetapi Traefik adalah alternatif sumber terbuka yang populer. Kedua pilihan teknologi terintegrasi dengan Service Fabric.

  • API Management. Mengekspos alamat IP publik dan merutekan lalu lintas ke layanan Anda. Ini berjalan di subnet khusus di jaringan virtual yang sama dengan kluster Service Fabric.

    API Management dapat mengakses layanan dalam jenis node yang diekspos melalui load balancer dengan alamat IP privat. Opsi ini hanya tersedia di tingkat Premium dan Pengembang API Management. Gunakan tingkat Premium untuk beban kerja produksi. Informasi harga dijelaskan dalam harga API Management.

    Untuk informasi selengkapnya, lihat Service Fabric dengan gambaran umum Azure API Management.

  • Traefik. Mendukung fitur seperti perutean, pelacakan, log, dan metrik. Traefik berjalan sebagai layanan tanpa status di kluster Service Fabric. Versi layanan dapat didukung melalui perutean.

    Untuk informasi tentang cara menyiapkan Traefik untuk masuk layanan dan sebagai proksi terbalik dalam kluster, lihat Penyedia Azure Service Fabric di situs web Traefik. Untuk informasi selengkapnya tentang menggunakan Traefik dengan Service Fabric, lihat posting blog Perutean cerdas di Service Fabric dengan Traefik.

Traefik, tidak seperti Azure API Management, tidak memiliki fungsionalitas untuk menyelesaikan partisi layanan stateful (dengan lebih dari satu partisi) di mana permintaan dialihkan. Untuk informasi selengkapnya, lihat Menambahkan matcher untuk layanan partisi.

Opsi manajemen API lainnya termasuk Azure Application Gateway dan Azure Front Door. Anda dapat menggunakan layanan ini bersama dengan API Management untuk melakukan tugas seperti perutean, penghentian SSL, dan firewall.

Komunikasi antarlayanan

Untuk memfasilitasi komunikasi layanan ke layanan, pertimbangkan rekomendasi berikut:

  • Protokol komunikasi. Dalam arsitektur layanan mikro, layanan perlu berkomunikasi satu sama lain dengan kopling minimum saat runtime. Untuk mengaktifkan komunikasi bahasa-agnostik, HTTP adalah standar industri dengan berbagai alat dan server HTTP yang tersedia dalam berbagai bahasa. Service Fabric mendukung semua alat dan server tersebut.

    Untuk sebagian besar beban kerja, kami sarankan Anda menggunakan HTTP alih-alih jarak jauh layanan yang dibangun ke Service Fabric.

  • Penemuan layanan. Untuk berkomunikasi dengan layanan lain dalam satu kluster, layanan klien perlu menyelesaikan lokasi layanan target saat ini. Di Service Fabric, layanan dapat berpindah antar simpul dan menyebabkan titik akhir layanan berubah secara dinamis.

    Untuk menghindari koneksi ke titik akhir kedaluarsa, Anda dapat menggunakan layanan penamaan di Service Fabric untuk mengambil informasi titik akhir yang diperbarui. Namun, Service Fabric juga menyediakan layanan reverse proxy built-in yang mengabstraksi layanan penamaan. Kami merekomendasikan opsi ini untuk penemuan layanan sebagai garis besar untuk sebagian besar skenario, karena lebih mudah digunakan dan menghasilkan kode yang lebih sederhana.

Opsi lain untuk komunikasi antar layanan meliputi:

  • Traefik untuk routing tngkat lanjutan.
  • DNS untuk skenario kompatibilitas di mana layanan mengharapkan untuk menggunakan DNS.
  • Kelas ServicePartitionClient<TCommunicationClient> , yang menyimpan titik akhir layanan. Ini dapat memungkinkan performa yang lebih baik, karena panggilan langsung di antara layanan tanpa perantara atau protokol kustom.

Skalabilitas

Service Fabric mendukung penskalaan entitas kluster ini:

  • Menskalakan jumlah simpul untuk setiap jenis node
  • Layanan penskalaan

Bagian ini difokuskan pada autoscaling. Anda dapat memilih untuk menskalakan secara manual dalam situasi yang sesuai. Misalnya, intervensi manual mungkin diperlukan untuk mengatur jumlah instans.

Konfigurasi klaster awal untuk skalabilitas

Saat Anda membuat kluster Service Fabric, sediakan jenis simpul berdasarkan kebutuhan keamanan dan skalabilitas Anda. Setiap jenis simpul dipetakan ke set skala mesin virtual dan dapat diskalakan secara independen.

  • Buat jenis simpul untuk setiap kelompok layanan yang memiliki skalabilitas atau persyaratan sumber daya yang berbeda. Mulailah dengan menyediakan jenis node (yang menjadi jenis node utama) untuk layanan sistem Service Fabric. Buat jenis node terpisah untuk menjalankan layanan publik atau front-end Anda. Buat jenis node lain seperlunya untuk back end dan layanan privat atau terisolasi Anda. Tentukan batasan penempatan sehingga layanan hanya disebarkan ke jenis node yang dimaksudkan.
  • Tentukan tingkat durabilitas untuk setiap jenis node. Tingkat durabilitas mewakili kemampuan Service Fabric untuk memengaruhi pembaruan dan operasi pemeliharaan dalam set skala komputer virtual. Untuk beban kerja produksi, pilih tingkat durabilitas Silver atau yang lebih tinggi. Untuk informasi tentang setiap tingkatan, lihat Karakteristik durabilitas kluster.
  • Jika Anda menggunakan tingkat durabilitas Perunggu, operasi tertentu memerlukan langkah manual. Jenis node dengan tingkat durabilitas Perunggu memerlukan langkah tambahan selama penskalaan. Untuk informasi selengkapnya tentang operasi penskalaan, lihat panduan ini.

Penskalaan simpul

Service Fabric mendukung penskalaan otomatis untuk penskalaan dan peluasan skala. Anda dapat mengonfigurasi setiap jenis node untuk penskalaan otomatis secara independen.

Setiap jenis simpul dapat memiliki maksimum 100 simpul. Mulailah dengan sekumpulan simpul yang lebih kecil, dan tambahkan lebih banyak simpul tergantung pada beban Anda. Jika Anda memerlukan lebih dari 100 simpul dalam jenis node, Anda harus menambahkan lebih banyak jenis node. Pertimbangan perencanaan kapasitas untuk kluster Service Fabric. Set timbangan mesin virtual tidak berskala instan, jadi pertimbangkan faktor itu saat Anda mengatur aturan skala otomatis.

Untuk mendukung skala otomatis, konfigurasikan jenis simpul agar memiliki tingkat daya tahan Silver atau Gold. Konfigurasi ini memastikan bahwa penskalaan ditunda hingga Service Fabric selesai memindahkan layanan. Ini juga memastikan bahwa set skala komputer virtual memberi tahu Service Fabric bahwa VM dihapus, bukan hanya untuk sementara.

Untuk informasi selengkapnya tentang penskalaan di tingkat node atau kluster, lihat Menskalakan kluster Azure Service Fabric.

Layanan penskalaan

Layanan tanpa status dan stateful menerapkan pendekatan yang berbeda untuk penskalaan.

Untuk layanan stateless (penskalaan otomatis):

  • Gunakan pemicu beban partisi rata-rata. Pemicu ini menentukan kapan layanan diskalakan masuk atau keluar, berdasarkan nilai ambang beban yang ditentukan dalam kebijakan penskalakan. Anda juga dapat mengatur seberapa sering pemicu diperiksa. Pemicu beban partisi rata-rata dengan penskalaan berbasis instans. Pendekatan ini memungkinkan Anda untuk meningkatkan ke jumlah simpul yang tersedia.
  • Atur InstanceCount ke -1 dalam manifes layanan, yang memberi tahu Service Fabric untuk menjalankan instans layanan pada setiap simpul. Pendekatan ini memungkinkan layanan untuk skala dinamis sebagai skala kluster. Karena jumlah simpul dalam kluster berubah, Service Fabric secara otomatis membuat dan menghapus instans layanan agar sesuai.

Catatan

Dalam beberapa kasus, Anda mungkin ingin menskalakan layanan Anda secara manual. Misalnya, jika Anda memiliki layanan yang berbunyi dari Azure Event Hubs, Anda mungkin ingin instans khusus membaca dari setiap partisi hub peristiwa. Dengan demikian, Anda dapat menghindari akses bersamaan ke partisi.

Untuk layanan stateful, penskalaan dikontrol oleh jumlah partisi, ukuran setiap partisi, dan jumlah partisi atau replika yang berjalan pada komputer:

  • Jika Anda membuat layanan yang dipartisi, pastikan setiap simpul mendapatkan replika yang memadai untuk distribusi beban kerja yang merata tanpa menyebabkan ketidakcocokan sumber daya. Jika Anda menambahkan lebih banyak simpul, Service Fabric mendistribusikan beban kerja ke komputer baru secara default. Misalnya, jika ada 5 simpul dan 10 partisi, Service Fabric akan menempatkan dua replika utama pada setiap simpul secara default. Jika Anda meluaskan skala simpul, Anda dapat mencapai performa yang lebih besar karena pekerjaan didistribusikan secara merata di lebih banyak sumber daya.

    Untuk informasi tentang skenario yang memanfaatkan strategi ini, lihat Penskalaan di Service Fabric.

  • Menambahkan atau menghapus partisi tidak didukung dengan baik. Opsi lain yang umumnya digunakan untuk menskalakan adalah membuat atau menghapus layanan atau seluruh instans aplikasi secara dinamis. Contoh pola tersebut dijelaskan dalam Penskalaan dengan membuat atau menghapus layanan bernama baru.

Untuk informasi selengkapnya, lihat:

Menggunakan metrik untuk menyeimbangkan beban

Tergantung pada bagaimana Anda mendesain partisi, Anda mungkin memiliki simpul dengan replika yang mendapatkan lebih banyak lalu lintas daripada yang lain. Untuk menghindari situasi ini, partisi status layanan sehingga didistribusikan di semua partisi. Gunakan skema partisi rentang dengan algoritma hash yang baik. Mulai dengan pemartisian.

Service Fabric menggunakan metrik untuk mengetahui cara menempatkan dan menyeimbangkan layanan dalam satu kluster. Anda dapat menentukan beban default untuk setiap metrik yang terkait dengan sebuah layanan saat layanan tersebut dibuat. Service Fabric kemudian memperhitungkan beban itu saat menempatkan layanan, atau setiap kali layanan perlu dipindahkan (misalnya, selama peningkatan), untuk menyeimbangkan node di kluster.

Beban default yang ditentukan sebelumnya untuk layanan tidak akan berubah selama masa pakai layanan. Untuk menangkap metrik yang berubah untuk layanan, kami sarankan Anda memantau layanan Anda lalu melaporkan beban secara dinamis. Pendekatan ini memungkinkan Service Fabric untuk menyesuaikan alokasi berdasarkan beban yang dilaporkan pada waktu tertentu. Gunakan metode IServicePartition.ReportLoad untuk melaporkan metrik kustom. Untuk informasi selengkapnya, lihat kemasan dinamis.

Ketersediaan

Tempatkan layanan Anda dalam jenis simpul selain tipe simpul utama. Layanan sistem Service Fabric selalu digunakan ke tipe simpul utama. Jika layanan Anda disebarkan ke jenis node utama, mereka mungkin bersaing dengan (dan mengganggu) layanan sistem untuk sumber daya. Jika jenis node diharapkan untuk menghosting layanan stateful, pastikan bahwa setidaknya ada lima instans node dan Anda memilih tingkat durabilitas Silver atau Gold.

Pertimbangkan untuk membatasi sumber daya layanan Anda. Mekanisme tata kelola sumber daya.

Berikut adalah pertimbangan umum:

  • Jangan mencampur layanan yang diatur sumber daya dan layanan yang tidak diatur sumber daya pada jenis node yang sama. Layanan yang tidak diatur mungkin menggunakan terlalu banyak sumber daya dan memengaruhi layanan yang diatur. Tentukan batasan penempatan untuk memastikan bahwa jenis layanan tersebut tidak berjalan pada kumpulan simpul yang sama. (Ini adalah contoh dari pola Bulkhead.)
  • Tentukan core dan memori CPU untuk cadangan instans layanan. Untuk informasi tentang penggunaan dan batasan kebijakan tata kelola sumber daya, lihat Tata kelola sumber daya.

Untuk menghindari satu titik kegagalan (SPOF), pastikan bahwa setiap instans target atau jumlah replika layanan lebih besar dari satu. Jumlah terbesar yang dapat Anda gunakan sebagai instans layanan atau jumlah replika sama dengan jumlah simpul yang membatasi layanan.

Pastikan bahwa setiap layanan stateful memiliki setidaknya dua replika sekunder aktif. Kami merekomendasikan lima replika untuk beban kerja produksi.

Untuk informasi selengkapnya, lihat Ketersediaan layanan Service Fabric.

Keamanan

Keamanan memberikan jaminan terhadap serangan yang disukai dan penyalahgunaan data dan sistem berharga Anda. Untuk informasi selengkapnya, lihat Gambaran Umum pilar keamanan.

Berikut adalah beberapa poin penting untuk mengamankan aplikasi Anda di Service Fabric.

Jaringan virtual

Pertimbangkan untuk menentukan batas subnet untuk setiap skala mesin virtual yang diatur untuk mengontrol aliran komunikasi. Setiap jenis simpul memiliki skala mesin virtual sendiri yang diatur dalam subnet dalam jaringan virtual kluster Service Fabric. Anda dapat menambahkan grup keamanan jaringan (NSG) ke subnet untuk mengizinkan atau menolak lalu lintas jaringan. Misalnya, dengan jenis node front-end dan back-end, Anda dapat menambahkan NSG ke subnet back-end untuk menerima lalu lintas masuk hanya dari subnet front-end.

Saat Anda memanggil layanan Azure eksternal dari kluster, gunakan titik akhir layanan jaringan virtual jika layanan Azure mendukungnya. Menggunakan titik akhir layanan mengamankan layanan hanya ke jaringan virtual kluster.

Misalnya, jika Anda menggunakan Azure Cosmos DB untuk menyimpan data, konfigurasikan akun Azure Cosmos DB dengan titik akhir layanan untuk mengizinkan akses hanya dari subnet tertentu. Lihat Mengakses sumber daya Azure Cosmos DB dari jaringan virtual.

Titik akhir dan komunikasi antar layanan

Jangan membuat kluster Service Fabric yang tidak aman. Jika kluster mengekspos titik akhir manajemen ke internet publik, pengguna anonim dapat terhubung ke sana. Kluster yang tidak aman tidak didukung untuk beban kerja produksi. Lihat Skenario keamanan kluster Service Fabric.

Untuk membantu mengamankan komunikasi antar layanan Anda:

  • Anda dapat mengaktifkan titik akhir HTTPS di layanan web ASP.NET Core atau Java Anda.
  • Pembentukan koneksi yang aman antara reverse proxy dan layanan. Untuk mengetahui detailnya, lihat Koneksi ke layanan yang aman.

Jika Anda menggunakan gateway API, Anda dapat membongkar autentikasi ke gateway. Pastikan bahwa layanan individual tidak dapat dijangkau secara langsung (tanpa gateway API) kecuali keamanan tambahan tersedia untuk mengautentikasi pesan.

Jangan mengekspos proksi terbalik Service Fabric secara publik. Melakukannya menyebabkan semua layanan yang mengekspos titik akhir HTTP dapat diatasi dari luar kluster. Itu akan memperkenalkan kerentanan keamanan dan berpotensi mengekspos informasi tambahan di luar kluster yang tidak perlu. Jika Anda ingin mengakses layanan secara publik, gunakan gateway API. Bagian gateway API nanti dalam artikel ini menyebutkan beberapa opsi.

Desktop Jauh berguna untuk diagnostik dan pemecahan masalah, tetapi pastikan untuk menutupnya. Membiarkannya terbuka menyebabkan lubang keamanan.

Rahasia dan sertifikat

Simpan rahasia, seperti string koneksi ke penyimpanan data, di brankas kunci. Brankas kunci harus berada di wilayah yang sama dengan set skala komputer virtual. Untuk menggunakan brankas kunci:

  1. Autentikasi akses layanan ke brankas kunci.

    Aktifkan identitas terkelola pada set skala mesin virtual yang menghosting layanan.

  2. Simpan rahasia Anda di brankas kunci.

    Tambahkan rahasia dalam format yang dapat diterjemahkan ke pasangan kunci/nilai. Misalnya, gunakan CosmosDB--AuthKey. Saat konfigurasi dibuat, tanda hubung ganda (--) dikonversi menjadi titik dua (:).

  3. Akses rahasia tersebut dalam layanan Anda.

    Tambahkan URI brankas kunci di file appSettings.json Anda. Dalam layanan Anda, tambahkan penyedia konfigurasi yang membaca dari brankas kunci, membangun konfigurasi, dan mengakses rahasia dari konfigurasi bawaan.

Berikut adalah contoh di mana layanan Alur Kerja menyimpan rahasia dalam brankas kunci dalam format CosmosDB--Database.

namespace Fabrikam.Workflow.Service
{
    public class ServiceStartup
    {
        public static void ConfigureServices(StatelessServiceContext context, IServiceCollection services)
        {
            var preConfig = new ConfigurationBuilder()
                …
                .AddJsonFile(context, "appsettings.json");

            var config = preConfig.Build();

            if (config["AzureKeyVault:KeyVaultUri"] is var keyVaultUri && !string.IsNullOrWhiteSpace(keyVaultUri))
            {
                preConfig.AddAzureKeyVault(keyVaultUri);
                config = preConfig.Build();
            }
    }
}

Untuk mengakses rahasia, tentukan nama rahasia dalam konfigurasi bawaan.

       if(builtConfig["CosmosDB:Database"] is var database && !string.IsNullOrEmpty(database))
       {
            // Use the secret.
       }

Jangan gunakan sertifikat klien untuk mengakses Service Fabric Explorer. Sebagai gantinya, gunakan ID Microsoft Entra. Lihat Layanan Azure yang mendukung autentikasi Microsoft Entra.

Jangan gunakan sertifikat yang ditandatangani sendiri untuk produksi.

Perlindungan data tidak aktif

Jika Anda melampirkan disk data ke set skala komputer virtual kluster Service Fabric dan layanan Anda menyimpan data pada disk tersebut, Anda harus mengenkripsi disk. Untuk informasi selengkapnya, lihat Mengenkripsi OS dan disk data terlampir dalam set skala komputer virtual dengan Azure PowerShell (pratinjau).

Untuk informasi selengkapnya tentang mengamankan Service Fabric, lihat:

Ketahanan

Untuk pulih dari kegagalan dan mempertahankan keadaan yang berfungsi penuh, aplikasi harus menerapkan pola ketahanan tertentu. Berikut adalah beberapa metode umum:

  • Coba lagi: Untuk menangani kesalahan yang Anda harapkan bersifat sementara, seperti sumber daya yang sementara tidak tersedia.
  • Pemutus arus: Untuk mengatasi kesalahan yang mungkin membutuhkan waktu lebih lama untuk diperbaiki.
  • Massal: Untuk mengisolasi sumber daya untuk setiap layanan.

Implementasi referensi ini menggunakan Polly, opsi sumber terbuka, untuk menerapkan semua pola tersebut.

Pemantauan

Sebelum Anda menjelajahi opsi pemantauan, kami sarankan Anda membaca artikel ini tentang mendiagnosis skenario umum dengan Service Fabric. Anda dapat memikirkan pemantauan data dalam kumpulan ini:

Ini adalah dua opsi utama untuk menganalisis data itu:

  • Application Insights
  • Log Analytics

Anda dapat menggunakan Azure Monitor untuk menyiapkan dasbor untuk pemantauan dan mengirim peringatan ke operator. Beberapa alat pemantauan pihak ketiga juga terintegrasi dengan Service Fabric, seperti Dynatrace. Untuk detailnya, lihat Mitra pemantauan Azure Service Fabric.

Log metrik aplikasi

Telemetri aplikasi menyediakan data yang dapat membantu Anda memantau kesehatan layanan Anda dan mengidentifikasi masalah. Untuk menambahkan jejak dan peristiwa di layanan Anda:

Application Insights menyediakan banyak telemetri bawaan: permintaan, jejak, peristiwa, pengecualian, metrik, dependensi. Jika layanan Anda mengekspos titik akhir HTTP, aktifkan Application Insights dengan memanggil UseApplicationInsights metode ekstensi untuk Microsoft.AspNetCore.Hosting.IWebHostBuilder. Untuk informasi tentang instrumen layanan Anda untuk Application Insights, lihat artikel ini:

Untuk melihat jejak dan log peristiwa, gunakan Application Insights sebagai salah satu sink untuk pengelogan terstruktur. Konfigurasikan Application Insights dengan kunci instrumentasi Anda dengan memanggil AddApplicationInsights metode ekstensi. Dalam contoh ini, kunci instrumentasi disimpan sebagai rahasia di brankas kunci.

    .ConfigureLogging((hostingContext, logging) =>
        {
            logging.AddApplicationInsights(hostingContext.Configuration ["ApplicationInsights:InstrumentationKey"]);
        })

Jika layanan Anda tidak mengekspos titik akhir HTTP, Anda perlu menulis ekstensi kustom yang mengirim jejak ke Application Insights. Misalnya, lihat layanan Alur Kerja dalam implementasi referensi.

ASP.NET Layanan Core menggunakan antarmuka ILogger untuk pembuatan log aplikasi. Untuk membuat log aplikasi ini tersedia di Azure Monitor, kirim peristiwa ke ILogger Application Insights. Application Insights dapat menambahkan properti korelasi ke ILogger peristiwa, yang berguna untuk memvisualisasikan pelacakan terdistribusi.

Untuk informasi selengkapnya, lihat:

Service Fabric data kesehatan dan peristiwa

Service Fabric telemetri mencakup metrik dan peristiwa kesehatan tentang pengoperasian dan kinerja kluster Service Fabric dan entitasnya: simpul, aplikasi, layanan, partisi, dan replikanya. Data kesehatan dan peristiwa dapat berasal dari:

  • EventStore. Layanan sistem stateful ini mengumpulkan peristiwa yang terkait dengan kluster dan entitasnya. Service Fabric menggunakan EventStore untuk menulis peristiwa Service Fabric untuk memberikan informasi tentang kluster Anda untuk pembaruan status, pemecahan masalah, dan pemantauan. EventStore juga dapat menghubungkan peristiwa dari entitas yang berbeda pada waktu tertentu untuk mengidentifikasi masalah dalam kluster. Layanan ini mengekspos peristiwa tersebut melalui REST API.

    Untuk informasi tentang cara meminta API EventStore, lihat API Query EventStore untuk peristiwa klaster. Anda dapat melihat peristiwa dari EventStore di Log Analytics dengan mengonfigurasi kluster Anda dengan ekstensi Azure Diagnostics untuk Windows (WAD).

  • HealthStore. Layanan stateful ini menyediakan rekam jepret dari kesehatan kluster saat ini. Ini menggabungkan semua data kesehatan yang dilaporkan oleh entitas dalam hierarki. Data divisualisasikan dalam Service Fabric Explorer. HealthStore juga memantau peningkatan aplikasi. Anda dapat menggunakan kueri kesehatan di PowerShell, aplikasi .NET, atau API REST. Lihat Pengantar pemantauan kesehatan Service Fabric.

  • Laporan kesehatan kustom. Pertimbangkan untuk menerapkan layanan pengawas internal yang dapat secara berkala melaporkan data kesehatan kustom, seperti status layanan yang berjalan yang rusak. Anda dapat membaca laporan kesehatan di Service Fabric Explorer.

Metrik dan log infrastruktur

Metrik infrastruktur membantu Anda memahami alokasi sumber daya di kluster. Berikut adalah opsi utama untuk mengumpulkan informasi ini:

  • WAD. Kumpulkan log dan metrik pada tingkat simpul pada Windows. Anda dapat menggunakan WAD dengan mengonfigurasi ekstensi IaaSDiagnostics VM pada set skala komputer virtual apa pun yang dipetakan ke jenis node untuk mengumpulkan peristiwa diagnostik. Peristiwa ini dapat mencakup log peristiwa Windows, penghitung kinerja, sistem ETW/manifes dan peristiwa operasional, dan log kustom.
  • Agen Analitik Log. Konfigurasikan ekstensi MicrosoftMonitoringAgent VM untuk mengirim log peristiwa Windows, penghitung kinerja, dan log kustom ke Analitik Log.

Ada beberapa tumpang tindih dalam jenis metrik yang dikumpulkan melalui mekanisme sebelumnya, seperti penghitung kinerja. Jika ada tumpang tindih, sebaiknya gunakan agen Analitik Log. Karena agen Analitik Log tidak menggunakan penyimpanan Azure, latensi rendah. Selain itu, penghitung kinerja di IaaSDiagnostics tidak dapat disalurkan ke Log Analytics dengan mudah.

Diagram yang menunjukkan pemantauan infrastruktur di Service Fabric.

Untuk informasi umum tentang ekstensi VM, lihat Ekstensi dan fitur komputer virtual Azure.

Untuk melihat data, konfigurasikan Analitik Log untuk menampilkan data yang dikumpulkan melalui WAD. Untuk informasi tentang cara mengonfigurasi Analitik Log untuk membaca peristiwa dari akun penyimpanan, lihat Menyiapkan Analitik Log untuk kluster.

Anda juga dapat melihat log kinerja dan data telemetri yang terkait dengan kluster Service Fabric, beban kerja, lalu lintas jaringan, pembaruan yang tertunda, dan banyak lagi. Lihat Pemantauan performa dengan Analitik Log.

Solusi Peta Layanan di Log Analytics menyediakan informasi tentang topologi kluster (yaitu, proses yang berjalan di setiap simpul). Kirim data di akun penyimpanan ke Insights Aplikasi. Mungkin ada beberapa keterlambatan dalam mendapatkan data ke Application Insights. Jika Anda ingin melihat data secara real time, pertimbangkan untuk mengonfigurasi Azure Event Hubs dengan menggunakan sink dan saluran. Untuk informasi selengkapnya, lihat Agregasi dan pengumpulan peristiwa menggunakan WAD.

Metrik layanan dependen

  • Peta Aplikasi di Application Insights menyediakan topologi aplikasi dengan menggunakan panggilan dependensi HTTP yang dilakukan di antara layanan, dengan Application Insights SDK yang diinstal.
  • Peta Layanan di Log Analytics menyediakan informasi tentang lalu lintas masuk dan keluar dari dan ke layanan eksternal. Peta Layanan terintegrasi dengan solusi lain, seperti pembaruan atau keamanan.
  • Pengawas kustom dapat melaporkan kondisi kesalahan pada layanan eksternal. Misalnya, layanan dapat memberikan laporan kesehatan kesalahan jika tidak dapat mengakses layanan eksternal atau penyimpanan data (Azure Cosmos DB).

Pelacakan terdistribusi

Dalam arsitektur layanan mikro, beberapa layanan sering berpartisipasi untuk menyelesaikan tugas. Telemetri dari masing-masing layanan tersebut berkorelasi melalui bidang konteks (seperti ID operasi dan ID permintaan) dalam jejak terdistribusi.

Dengan menggunakan Peta Aplikasi di Application Insights, Anda dapat membangun tampilan operasi logis terdistribusi dan memvisualisasikan seluruh grafik layanan aplikasi Anda. Anda juga dapat menggunakan diagnostik transaksi di Application Insights untuk menghubungkan telemetri sisi server. Untuk informasi selengkapnya, lihat Diagnostik transaksi lintas komponen terpadu.

Penting juga untuk menghubungkan tugas yang dikirim secara asinkron dengan menggunakan antrean. Untuk detail tentang mengirim telemetri korelasi dalam pesan antrean, lihat Instrumentasi antrean.

Untuk informasi selengkapnya, lihat:

Pemberitahuan dan dasbor

Application Insights dan Log Analytics mendukung bahasa kueri yang luas (bahasa kueri Kusto) yang memungkinkan Anda mengambil dan menganalisis data log. Gunakan kueri untuk membuat himpunan data dan memvisualisasikannya di dasbor diagnostik.

Gunakan pemberitahuan Azure Monitor untuk memberi tahu admin sistem saat kondisi tertentu terjadi dalam sumber daya tertentu. Pemberitahuan bisa berupa email, fungsi Azure, atau webhook, misalnya. Untuk informasi lebih lengkap, lihat Peringatan log dalam Azure Monitor.

Aturan peringatan penelusuran log memungkinkan Anda menentukan dan menjalankan kueri Kusto terhadap ruang kerja Analitik Log secara berkala. Peringatan dibuat jika hasil kueri cocok dengan kondisi tertentu.

Pengoptimalan biaya

Gunakan kalkulator harga Azure untuk memperkirakan biaya. Pertimbangan lain dijelaskan dalam pilar pengoptimalan biaya Microsoft Azure Well-Architected Framework.

Berikut ini beberapa poin yang perlu dipertimbangkan untuk beberapa layanan yang digunakan dalam arsitektur ini.

Azure Service Fabric

Anda dikenakan biaya untuk instans komputasi, penyimpanan, sumber daya jaringan, dan alamat IP yang Anda pilih saat membuat kluster Service Fabric. Ada biaya penyebaran untuk Service Fabric.

Kumpulan skala komputer virtual

Dalam arsitektur ini, layanan mikro disebarkan ke dalam simpul yang merupakan set skala komputer virtual. Anda dikenakan biaya untuk Azure VM yang disebarkan sebagai bagian dari kluster dan sumber daya infrastruktur yang mendasar, seperti penyimpanan dan jaringan. Tidak ada biaya tambahan untuk set skala komputer virtual itu sendiri.

Azure API Management

Azure API Management adalah gateway untuk merutekan permintaan dari klien ke layanan Anda di kluster.

Ada berbagai opsi harga. Opsi Konsumsi dibebankan berdasarkan bayar per penggunaan dan mencakup komponen gateway. Berdasarkan beban kerja Anda, pilih opsi yang dijelaskan dalam harga API Management.

Application Insights

Anda dapat menggunakan Application Insights untuk mengumpulkan telemetri untuk semua layanan dan melihat jejak dan log peristiwa secara terstruktur. Harga untuk Application Insights adalah model bayar sesuai penggunaan yang didasarkan pada volume data yang diserap dan opsi untuk retensi data. Untuk informasi selengkapnya, lihat Mengelola penggunaan dan biaya untuk Application Insights.

Azure Monitor

Untuk Azure Monitor Log Analytics, Anda dikenakan biaya untuk penyerapan dan retensi data. Untuk informasi selengkapnya, lihat Harga Azure Monitor.

Azure Key Vault

Anda menggunakan Azure Key Vault untuk menyimpan kunci instrumentasi untuk Application Insights sebagai rahasia. Azure menawarkan Key Vault dalam dua tingkat layanan. Jika Anda tidak memerlukan kunci yang dilindungi HSM, pilih tingkat Standar. Untuk informasi tentang fitur di setiap tingkat, lihat Harga Key Vault.

Azure DevOps Services

Arsitektur referensi ini menggunakan Azure Pipelines untuk penyebaran. Layanan Azure Pipelines memungkinkan pekerjaan gratis yang dihosting Microsoft dengan 1.800 menit per bulan untuk CI/CD dan satu pekerjaan yang dihost sendiri dengan menit tanpa batas per bulan. Pekerjaan tambahan memiliki biaya. Untuk informasi selengkapnya, lihat Harga Layanan Azure DevOps.

Untuk pertimbangan DevOps dalam arsitektur layanan mikro, lihat CI/CD untuk layanan mikro.

Untuk mempelajari cara menyebarkan aplikasi kontainer dengan CI/CD ke kluster Service Fabric, lihat tutorial ini.

Menyebarkan skenario ini

Untuk menyebarkan penerapan referensi untuk arsitektur ini, ikuti langkah-langkah dalam repositori GitHub.

Langkah berikutnya