Komunikasi layanan ke layanan

Tip

Konten ini adalah kutipan dari eBook, Merancang Aplikasi .NET Cloud Native untuk Azure, tersedia di .NET Docs atau sebagai PDF gratis yang dapat diunduh yang dapat dibaca secara offline.

Unduh PDF

Beranjak dari klien front-end, kami sekarang menangani layanan mikro back-end yang berkomunikasi dengan satu sama lain.

Saat membangun aplikasi cloud-native, Anda harus peka terhadap cara layanan back-end berkomunikasi dengan satu sama lain. Idealnya, semakin sedikit komunikasi antar-layanan, semakin baik. Namun, penghindaran tidak selalu memungkinkan karena layanan back-end sering mengandalkan satu sama lain untuk menyelesaikan operasi.

Ada beberapa pendekatan yang diterima secara luas untuk mengimplementasikan komunikasi lintas layanan. Jenis interaksi komunikasi sering kali akan menentukan pendekatan terbaik.

Perhatikan jenis interaksi berikut:

• Kueri – saat layanan mikro yang memanggil membutuhkan respons dari layanan mikro yang dipanggil, seperti, "Hei, beri saya informasi pembeli untuk Id pelanggan tertentu."

• Perintah – saat layanan mikro yang memanggil membutuhkan layanan mikro lain untuk menjalankan tindakan, seperti, "Hei, kirimkan pesanan ini."

• Event – saat layanan mikro, yang disebut penerbit, memunculkan kejadian bahwa status telah berubah atau tindakan telah terjadi. Layanan mikro lainnya, yang disebut pelanggan dan tertarik, dapat bereaksi terhadap kejadian tersebut dengan tepat. Penerbit dan pelanggan tidak saling menyadari satu sama lain.

Sistem layanan mikro biasanya menggunakan kombinasi dari jenis interaksi ini saat menjalankan operasi yang membutuhkan interaksi lintas layanan. Mari kita lihat lebih dekat masing-masing jenis interaksi dan bagaimana Anda dapat mengimplementasikannya.

Kueri

Sering kali, satu layanan mikro mungkin perlu mengkueri layanan mikro lainnya, yang membutuhkan respons segera untuk menyelesaikan operasi. Sebuah layanan mikro keranjang belanja mungkin membutuhkan informasi dan harga produk untuk menambahkan item ke keranjangnya. Ada banyak pendekatan untuk menerapkan operasi kueri.

Olahpesan Permintaan/Respons

Salah satu opsi mengimplementasikan skenario ini adalah layanan mikro back-end yang memanggil, membuat permintaan HTTP langsung ke layanan mikro yang perlu dikueri, yang ditunjukkan dalam Gambar 4-8.

Gambar 4-8. Komunikasi HTTP langsung

Meskipun panggilan HTTP langsung antar layanan mikro relatif mudah untuk diimplementasikan, kehati-hatian dibutuhkan untuk meminimalkan praktik ni. Untuk memulai, panggilan-panggilan ini selalu sinkron dan akan memblokir operasi sampai hasil dikembalikan atau waktu permintaan habis. Layanan yang dulunya mandiri, independen, mampu berkembang secara independen, serta sering disebarkan, sekarang digabungkan dengan satu sama lain. Seiring dengan meningkatnya penggandengan di antara layanan mikro, keuntungan arsitekturalnya berkurang.

Menjalankan permintaan yang jarang terjadi, yang membuat satu panggilan HTTP langsung ke layanan mikro lain mungkin dapat diterima untuk beberapa sistem. Namun, panggilan bervolume tinggi yang memanggil panggilan HTTP langsung ke beberapa layanan mikro tidak disarankan. Panggilan-panggilan tersebut dapat meningkatkan latensi dan berdampak negatif pada performa, skalabilitas, dan ketersediaan sistem Anda. Lebih buruk lagi, serangkaian panjang komunikasi HTTP langsung dapat menyebabkan rantai panggilan layanan mikro sinkron yang dalam dan rumit, yang ditunjukkan dalam Gambar 4-9:

Gambar 4-9. Penautan kueri HTTP

Anda tentu dapat membayangkan risiko desain yang ditunjukkan pada gambar sebelumnya. Apa yang akan terjadi jika Langkah #3 gagal? Atau Langkah #8 gagal? Bagaimana Anda memulihkannya? Bagaimana jika Langkah #6 berjalan lambat karena layanan yang mendasarinya sibuk? Bagaimana Anda melanjutkannya? Bahkan jika semua berfungsi dengan benar, pikirkan tentang latensi yang akan ditimbulkan oleh panggilan ini, yang merupakan jumlah latensi dari setiap langkah.

Tingkat penggandengan yang besar pada gambar sebelumnya menunjukkan bahwa layanan tidak dimodelkan secara optimal. Tim harus meninjau kembali desain mereka.

Pola Tampilan Terwujud

Opsi populer untuk menghapus penggandengan layanan mikro adalah pola Tampilan Terwujud. Dengan pola ini, layanan mikro menyimpan salinan data lokal yang didenormalisasi, yang dimiliki oleh layanan lain. Alih-alih mengkueri layanan mikro Katalog dan Harga Produk, layanan mikro Keranjang Belanja menyimpan salinan lokalnya sendiri dari data tersebut. Pola ini menghilangkan penggandengan yang tidak perlu serta meningkatkan reliabilitas dan waktu respons. Seluruh operasi dijalankan dalam satu proses. Kami mengeksplorasi pola ini dan masalah data lainnya di Bab 5.

Pola Agregator Layanan

Opsi lain untuk menghilangkan penggandengan layanan mikro ke layanan mikro adalah layanan mikro Agregator, yang ditunjukkan dengan warna ungu pada Gambar 4-10.

Gambar 4-10. Layanan mikro Agregator

Pola ini mengisolasi operasi yang membuat panggilan ke beberapa layanan mikro back-end, memusatkan logikanya ke layanan mikro khusus. Layanan agregator selesai ungu pada gambar sebelumnya mengatur alur kerja untuk operasi Selesai. Hal ini termasuk panggilan ke beberapa layanan mikro back-end secara berurutan. Data dari alur kerja diagregasi dan dikembalikan ke pemanggil. Meskipun masih mengimplementasikan panggilan HTTP langsung, layanan mikro agregator mengurangi dependensi langsung di antara layanan mikro back-end.

Pola Permintaan/Balasan

Pendekatan lain untuk memisahkan pesan HTTP sinkron adalah Pola Permintaan-Balasan, yang menggunakan komunikasi antrean. Komunikasi menggunakan antrean selalu merupakan saluran satu arah, dengan produsen mengirim pesan dan konsumen menerimanya. Dengan pola ini, antrean permintaan dan antrean respons diimplementasikan, yang ditunjukkan pada Gambar 4-11.

Gambar 4-11. Pola permintaan-balasan

Di sini, produser pesan membuat pesan berbasis kueri yang berisi ID korelasi unik dan menempatkannya ke dalam antrean permintaan. Layanan yang menggunakan menghapus antrean pesan, memprosesnya, dan menempatkan respons ke dalam antrean respons dengan ID korelasi yang sama. Layanan produsen menghapus antrean pesan, mencocokkannya dengan ID korelasi dan melanjutkan pemrosesan. Kami membahas antrean secara detail di bagian berikutnya.

Perintah

Jenis lain dari interaksi komunikasi adalah perintah. Sebuah layanan mikro mungkin membutuhkan layanan mikro lain untuk melakukan tindakan. Layanan mikro Pemesanan mungkin membutuhkan layanan mikro Pengiriman untuk membuat pengiriman untuk pesanan yang disetujui. Pada Gambar 4-12, satu layanan mikro, yang disebut Produsen, mengirimkan sebuah pesan ke layanan mikro lain, Konsumen, memerintahkannya untuk melakukan sesuatu.

Gambar 4-12. Interaksi perintah dengan antrean

Sering kali, Produsen tidak membutuhkan respons dan dapat mengaktifkan-dan melupakan pesan. Jika dibutuhkan balasan, Konsumen mengirimkan pesan terpisah kembali ke Produser di saluran lain. Sebuah pesan perintah paling baik dikirim secara asinkron dengan antrean pesan. didukung oleh perantara pesan ringan. Dalam diagram sebelumnya, perhatikan bagaimana antrean memutuskan dan memisahkan kedua layanan.

Antrean pesan adalah konstruksi perantara di mana produsen dan konsumen meneruskan pesan. Antrean mengimplementasikan pola olahpesan titik-ke-titik yang asinkron. Produsen tahu ke mana perintah perlu dikirim dan dirutekan dengan tepat. Antrean menjamin bahwa pesan diproses oleh salah satu instans konsumen yang membaca dari saluran. Dalam skenario ini, layanan produsen atau konsumen dapat memperluas skala tanpa memengaruhi yang lain. Selain itu, teknologi bisa berbeda di setiap sisi, yang berarti bahwa kita mungkin memiliki layanan mikro Java yang memanggil layanan mikro Golang.

Dalam bab 1, kita berbicara tentang layanan pendukung. Layanan pendukung adalah sumber daya tambahan yang menjadi sandaran sistem cloud-native. Antrean pesan adalah layanan pendukung. Cloud Azure mendukung dua jenis antrean pesan yang dapat digunakan oleh sistem cloud-native Anda untuk mengimplementasikan olahpesan perintah: Antrean Azure Storage dan Antrean Azure Service Bus.

Azure Storage Queues

Antrean Azure storage menawarkan infrastruktur antrean yang cepat, murah, dan didukung oleh akun penyimpanan Azure.

Antrean Azure Storage menghadirkan mekanisme antrean berbasis REST dengan olahpesan yang andal dan persisten. Antrean Azure Storage menyediakan serangkaian fitur minimal, tetapi tidak mahal dan dapat menyimpan jutaan pesan. Rentang kapasitasnya mencapai 500 TB. Satu pesan dapat berukuran hingga 64 KB.

Anda dapat mengakses pesan dari mana saja di dunia melalui panggilan yang diautentikasi dengan menggunakan HTTP atau HTTPS. Skala antrean penyimpanan dapat diperluas ke sejumlah besar klien serentak untuk menangani lonjakan lalu lintas.

Meskipun begitu, ada batasan-batasan layanan tersebut:

• Urutan pesan tidak dijamin.

• Sebuah pesan hanya dapat bertahan selama tujuh hari sebelum dihapus secara otomatis.

• Dukungan untuk manajemen status, pendeteksian duplikat, atau transaksi tidak tersedia.

Gambar 4-13 menunjukkan hierarki Azure Storage Queue.

Gambar 4-13. Hierarki antrean penyimpanan

Pada gambar sebelumnya, perhatikan bagaimana antrean penyimpanan menyimpan pesan mereka di akun Azure Storage yang mendasarinya.

Untuk pengembang, Microsoft menyediakan beberapa pustaka sisi klien dan server untuk pemrosesan antrean Penyimpanan. Sebagian besar platform didukung, termasuk .NET, Java, JavaScript, Ruby, Python, dan Go. Pengembang tidak boleh berkomunikasi secara langsung dengan pustaka ini. Melakukan hal tersebut akan menggabungkan kode layanan mikro Anda dengan erat ke layanan Azure Storage Queue. Ini adalah praktik yang lebih baik untuk mengisolasi detail implementasi API. Perkenalkan lapisan perantara atau API perantara, yang mengekspor operasi generik dan merangkum pustaka yang konkret. Penggabungan yang longgar ini memungkinkan Anda untuk menukar satu layanan antrean untuk layanan lain tanpa harus membuat perubahan pada kode layanan utama.

Antrean Azure Storage merupakan opsi yang ekonomis untuk mengimplementasikan olahpesan perintah di aplikasi cloud-native Anda. Khususnya ketika ukuran antrean akan melebihi 80 GB atau serangkaian fitur sederhana dapat diterima. Anda hanya membayar untuk penyimpanan pesan; tidak ada biaya per jam yang tetap.

Azure Service Bus Queues

Untuk persyaratan olahpesan yang lebih rumit, pertimbangkan antrean Azure Service Bus.

Berada di atas infrastruktur pesan yang kuat, Azure Service Bus mendukung model olahpesan dengan perantara. Pesan-pesan disimpan dengan andal dalam perantara (antrean) sampai diterima oleh konsumen. Antrean menjamin pengiriman pesan First-In/First-Out (FIFO), menghormati urutan pesan ditambahkan ke antrean.

Ukuran pesan bisa jauh lebih besar, yaitu hingga 256 KB. Pesan dipertahankan dalam antrean untuk jangka waktu yang tidak terbatas. Service Bus tidak hanya mendukung panggilan berbasis HTTP, tetapi juga menyediakan dukungan penuh untuk protokol AMQP. AMQP adalah standar terbuka di seluruh vendor yang mendukung protokol biner dan tingkat reliabilitas yang lebih tinggi.

Service Bus menyediakan serangkaian fitur yang kaya, termasuk dukungan transaksi dan fitur deteksi duplikat. Antrean menjamin "paling banyak sekali pengiriman" per pesan. Pesan yang telah terkirim secara otomatis akan dibuang. Jika produsen ragu, produsen dapat mengirim ulang pesan yang sama dan Service Bus menjamin hanya satu salinan yang akan diproses. Deteksi duplikat membebaskan Anda dari keharusan membangun saluran infrastruktur tambahan.

Dua fitur enterprise lainnya adalah pemartisian dan sesi. Antrean Service Bus konvensional ditangani oleh satu perantara pesan dan disimpan dalam satu penyimpanan pesan. Tetapi, Pemartisian Service Bus menyebarkan antrean ke beberapa perantara pesan dan penyimpanan pesan. Throughput keseluruhan tidak lagi dibatasi oleh performa satu perantara pesan atau penyimpanan olahpesan. Gangguan penyimpanan olahpesan sementara tidak membuat antrean yang dipartisi menjadi tidak tersedia.

Sesi Service Bus menyediakan cara untuk mengelompokkan pesan-pesan terkait. Bayangkan skenario alur kerja di mana pesan harus diproses bersama dan operasi selesai di akhir. Untuk memanfaatkannya, sesi harus diaktifkan secara eksplisit untuk antrean dan setiap pesan terkait harus berisi ID sesi yang sama.

Namun, ada beberapa peringatan penting: ukuran antrean Service Bus dibatasi hingga 80 GB, yang jauh lebih kecil daripada apa yang tersedia dari antrean penyimpanan. Selain itu, antrean Service Bus dikenakan biaya dasar dan tarif per operasi.

Gambar 4-14 menguraikan arsitektur tingkat tinggi dari antrean Service Bus.

Gambar 4-14. Antrean Microsoft Azure Service Bus

Pada gambar sebelumnya, perhatikan hubungan titik-ke-titik. Dua instans penyedia yang sama mengantrekan pesan-pesan ke dalam satu antrean Service Bus. Setiap pesan hanya digunakan oleh salah satu dari tigas instans konsumen di sebelah kanan. Selanjutnya, kita membahas cara mengimplementasikan olahpesan ketika konsumen-konsumen yang berbeda mungkin tertarik dengan pesan yang sama.

Acara

Message queuing merupakan cara yang efektif untuk menerapkan komunikasi di mana produsen dapat mengirimkan pesan kepada konsumen secara asinkron. Namun, apa yang terjadi ketika banyak konsumen yang berbeda tertarik pada pesan yang sama? Antrean pesan khusus untuk setiap konsumen tidak akan diskalakan dengan baik dan akan menjadi sulit untuk dikelola.

Untuk mengatasi skenario ini, kita berpindah ke jenis interaksi pesan ketiga, yaitu kejadian. Satu layanan mikro mengumumkan bahwa sebuah tindakan telah terjadi. Jika tertarik, layanan mikro lainnya bereaksi terhadap tindakan atau kejadian tersebut. Ini juga dikenal sebagai gaya arsitektur berbasis peristiwa.

Eventing adalah proses dua langkah. Untuk perubahan status tertentu, layanan mikro menerbitkan kejadian ke perantara pesan, membuatnya tersedia untuk layanan mikro lainnya yang tertarik. Layanan mikro yang tertarik akan diberi tahu dengan berlangganan kejadian di perantara pesan. Anda menggunakan pola Terbitkan/Berlangganan untuk mengimplementasikan komunikasi berbasis kejadian.

Gambar 4-15 menunjukkan layanan mikro keranjang belanja yang menerbitkan kejadian dengan dua layanan mikro lain yang berlangganan padanya.

Gambar 4-15. Olahpesan yang Digerakkan Kejadian

Perhatikan komponen event bus yang berada di tengah saluran komunikasi. Itu adalah kelas kustom yang merangkum perantara pesan dan memisahkannya dari aplikasi yang mendasarinya. Layanan mikro pemesanan dan layanan mikro inventaris mengoperasikan kejadian secara independen tanpa sepengetahuan satu sama lain atau layanan keranjang belanja. Ketika kejadian terdaftar diterbitkan ke event bus, mereka menindaklanjutinya.

Dengan eventing, kita berpindah dari teknologi antrean ke topik. Topik mirip dengan antrean, tetapi mendukung pola olahpesan satu ke banyak. Satu layanan mikro menerbitkan pesan. Beberapa layanan mikro yang berlangganan dapat memilih untuk menerima dan menindaklanjuti pesan tersebut. Gambar 4-16 menunjukkan arsitektur topik.

Gambar 4-16. Arsitektur topik

Pada gambar sebelumnya, penerbit mengirimkan pesan ke topik. Di akhir, pelanggan menerima pesan dari langganan. Di bagian tengah, topik meneruskan pesan ke langganan berdasarkan seperangkat peraturan, yang ditunjukkan dalam kotak biru tua. Peraturan bertindak sebagai filter yang meneruskan pesan tertentu ke langganan. Di sini, kejadian "GetPrice" akan dikirim ke langganan harga dan pengelogan karena langganan pengelogan telah memilih untuk menerima semua pesan. Kejadian "GetInformation" akan dikirim ke langganan informasi dan pengelogan.

Cloud Azure mendukung dua layanan topik berbeda: Topik Azure Service Bus dan Azure EventGrid.

Topik Azure Service Bus

Duduk di atas model pesan berperantara yang sama kuatnya dari antrean Azure Service Bus adalah Topik Azure Service Bus. Sebuah topik dapat menerima pesan dari beberapa penerbit independen dan mengirimkan pesan hingga ke 2.000 pelanggan. Langganan dapat ditambahkan atau dihapus secara dinamis saat durasi tanpa menghentikan sistem atau membuat ulang topik.

Banyak fitur canggih dari antrean Azure Service Bus juga tersedia untuk topik, termasuk Deteksi Duplikat dan dukungan Transaction. Secara default, topik Service Bus ditangani oleh satu perantara pesan dan disimpan dalam satu penyimpanan pesan. Tetapi, Pemartisian Service Bus menskalakan topik dengan menyebarkannya ke banyak perantara pesan dan penyimpanan pesan.

Pengiriman Pesan Terjadwal menandai pesan dengan waktu pemrosesan tertentu. Pesan tidak akan muncul dalam topik sebelum waktu tersebut. Penundaan Pesan memungkinkan Anda menunda pengambilan pesan ke lain waktu. Keduanya biasa digunakan dalam skenario pemrosesan di mana operasi diproses dalam urutan tertentu. Anda dapat menunda pemrosesan pesan yang diterima hingga pekerjaan sebelumnya selesai.

Topik Service Bus adalah teknologi yang kuat dan terbukti untuk mengaktifkan komunikasi terbitkan/langganan di sistem cloud-native Anda.

Kisi Aktivitas Azure

Berbeda dengan Azure Service Bus yang merupakan perantara olahpesan yang telah teruji dengan serangkaian lengkap fitur enterprise, Azure Event Grid adalah layanan baru.

Sekilas, Event Grid mungkin terlihat seperti sistem olahpesan berbasis topik lainnya. Namun, Event Grid berbeda dalam banyak hal. Berfokus pada beban kerja yang digerakkan kejadian, Event Grid memungkinkan pemrosesan kejadian secara real time, integrasi Azure mendalam, dan platform terbuka - semua dalam infrastruktur tanpa server. Event Grid dirancang untuk cloud-native kontemporer dan aplikasi tanpa server

Sebagai eventing backplane terpusat, atau pipa, Event Grid bereaksi terhadap kejadian di dalam sumber daya Azure dan dari layanan Anda sendiri.

Pemberitahuan kejadian diterbitkan ke Topik Event Grid, yang pada gilirannya, merutekan setiap kejadian ke langganan. Pelanggan memetakan langganan dan menggunakan kejadian. Seperti Service Bus, Event Grid mendukung model pelanggan yang difilter di mana langganan menetapkan aturan untuk kejadian yang ingin diterimanya. Event Grid menyediakan throughput yang cepat dengan jaminan 10 juta kejadian per detik, yang memungkinkan pengiriman mendekati real-time - lebih banyak daripada yang dapat dihasilkan oleh Azure Service Bus.

Fitur yang paling disukai dari Event Grid adalah integrasinya yang mendalam ke fabric infrastruktur Azure. Sumber daya Azure, seperti Cosmos DB, dapat menerbitkan kejadian bawaan secara langsung ke sumber daya Azure lain yang tertarik - tanpa membutuhkan kode kustom. Event Grid dapat menerbitkan kejadian dari Langganan Azure, Grup Sumber Daya, atau Layanan, yang memberikan pengembang kontrol yang mendetail terhadap siklus hidup sumber daya cloud. Namun, Event Grid tidak terbatas pada Azure. Ini adalah platform terbuka yang dapat menggunakan kejadian HTTP kustom yang diterbitkan dari aplikasi atau layanan pihak ketiga dan merutekan kejadian ke pelanggan eksternal.

Saat menerbitkan dan berlangganan kejadian asli dari sumber daya Azure, tidak dibutuhkan pengodean. Dengan konfigurasi sederhana, Anda dapat mengintegrasikan kejadian dari satu sumber daya Azure ke sumber daya Azure lainnya dengan memanfaatkan saluran bawaan untuk Topik dan Langganan. Gambar 4-17 menunjukkan anatomi Event Grid.

Gambar 4-17. Anatomi Event Grid

Perbedaan utama antara EventGrid dan Service Bus adalah pola pertukaran pesan yang mendasarinya.

Service Bus mengimplementasikan model penarikan gaya lama, di mana pelanggan hilir secara aktif melakukan polling langganan topik untuk pesan baru. Sisi positifnya, pendekatan ini memberi pelanggan kontrol penuh atas kecepatan pemrosesan pesan. Pelanggan mengontrol kapan dan berapa banyak pesan yang akan diproses pada waktu tertentu. Pesan yang belum dibaca tetap berada dalam langganan hingga diproses. Sebuah kekurangan yang signifikan adalah latensi antara waktu kejadian dihasilkan dan operasi polling yang menarik pesan tersebut ke pelanggan untuk diproses. Selain itu, overhead polling konstanta untuk kejadian selanjutnya menghabiskan sumber daya dan uang.

Namun, EventGrid berbeda. EventGrid mengimplementasikan model pendorongan, yaitu kejadian dikirim ke EventHandlers saat diterima, sehingga memberikan pengiriman kejadian yang mendekati real-time. Hal tersebut juga mengurangi biaya karena layanan dipicu hanya saat dibutuhkan untuk menggunakan kejadian – tidak terus-menerus seperti polling. Oleh karena itu, penanganan aktivitas harus menangani beban yang masuk dan menyediakan mekanisme pembatasan untuk melindungi diri agar tidak kewalahan. Banyak layanan Azure yang menggunakan kejadian ini, seperti Azure Functions dan Logic Apps, menyediakan kemampuan penskalaan otomatis untuk menangani peningkatan beban.

Event Grid adalah layanan cloud tanpa server yang dikelola penuh. Secara dinamis, Event Grid menskalakan berdasarkan lalu lintas Anda dan menagih hanya untuk penggunaan Anda yang sebenarnya, bukan kapasitas yang dibeli sebelumnya. 100.000 operasi pertama per bulan gratis – operasi didefinisikan sebagai masuknya kejadian (pemberitahuan kejadian masuk), upaya pengiriman langganan, panggilan manajemen, dan pemfilteran berdasarkan subjek. Dengan ketersediaan 99,99%, EventGrid menjamin pengiriman kejadian dalam periode 24 jam, dengan fungsionalitas coba ulang bawaan untuk pengiriman yang gagal. Pesan yang tidak terkirim dapat dipindahkan ke antrean "surat gagal" untuk penyelesaian. Tidak seperti Azure Service Bus, Event Grid disetel untuk performa cepat dan tidak mendukung fitur seperti olahpesan yang dipesan, transaksi, dan sesi.

Streaming pesan di cloud Azure

Azure Service Bus dan Event Grid menyediakan dukungan yang besar untuk aplikasi yang mengekspos kejadian tunggal dan terpisah, seperti dokumen baru yang dimasukkan ke dalam Cosmos DB. Namun, bagaimana jika sistem cloud-native Anda perlu memproses aliran kejadian terkait? Aliran kejadian lebih rumit. Aliran kejadian biasanya diurutkan waktu, saling terkait dan harus diproses sebagai grup.

Azure Event Hub adalah platform aliran data dan layanan penyerapan kejadian yang mengumpulkan, mengubah, dan menyimpan kejadian. Platform tersebut disempurnakan untuk mengambil data streaming, seperti pemberitahuan kejadian berkelanjutan yang dipancarkan dari konteks telemetri. Layanan ini sangat scalable dan dapat menyimpan serta memproses jutaan kejadian per detik. Ditunjukkan pada Gambar 4-18, Azure Event Hub sering kali menjadi pintu depan untuk alur kejadian, yang memisahkan aliran penyerapan dari konsumsi kejadian.

Gambar 4-18. Microsoft Event Hub

Event Hub mendukung latensi rendah dan retensi waktu yang dapat dikonfigurasi. Tidak seperti antrean dan topik, Azure Event Hubs menyimpan data kejadian setelah dibaca oleh konsumen. Fitur ini memungkinkan layanan analitik data lainnya, baik internal dan eksternal, untuk memutar ulang data untuk analisis lebih lanjut. Kejadian yang disimpan dalam event hub hanya dihapus setelah berakhirnya periode retensi, yaitu satu hari secara default, tetapi dapat dikonfigurasi.

Event Hub mendukung protokol penerbitan kejadian umum, termasuk HTTPS dan AMQP. Event Hub juga mendukung Kafka 1.0. Aplikasi Kafka yang ada dapat berkomunikasi dengan Event Hub menggunakan protokol Kafka yang menyediakan alternatif untuk mengelola kluster Kafka besar. Banyak sistem cloud-native sumber terbuka yang merangkul Kafka.

Azure Event Hubs mengimplementasikan streaming pesan melalui model konsumen yang dipartisi di mana setiap konsumen hanya membaca subset atau partisi khusus dari aliran pesan. Pola ini memungkinkan skala horizontal yang luar biasa untuk pemrosesan kejadian dan menyediakan fitur fokus-aliran lainnya yang tidak tersedia di antrean dan topik. Partisi adalah urutan peristiwa kronologis yang diadakan di pusat aktivitas. Ketika peristiwa yang lebih baru tiba, peristiwa tersebut akan ditambahkan ke akhir urutan ini. Gambar 4-19 menunjukkan pemartisian dalam Event Hub.

Gambar 4-19. Pemartisian Event Hub

Alih-alih membaca dari sumber daya yang sama, setiap grup konsumen membaca seluruh subset atau partisi dari aliran pesan.

Untuk aplikasi cloud-native yang harus mengalirkan sejumlah besar kejadian, Azure Event Hub dapat menjadi solusi yang kuat dan terjangkau.

SebelumnyaBerikutnya