Menggunakan broker pesan dan peristiwa untuk mengintegrasikan sistem perusahaan

Azure Event Grid
Azure Service Bus

Arsitektur ini didasarkan pada arsitektur integrasi perusahaan dasar tetapi mencakup cara mengintegrasikan sistem back-end perusahaan. Arsitektur ini menggunakan broker pesan dan peristiwa untuk memisahkan layanan untuk skalabilitas dan keandalan yang lebih besar. Pastikan Anda terbiasa dengan desain dan komponen dalam arsitektur integrasi dasar. Elemen-elemen ini memberikan informasi dasar tentang komponen inti arsitektur ini.

Sistem

Sistem back-end yang direferensikan desain ini mencakup sistem perangkat lunak sebagai layanan (SaaS), layanan Azure, layanan berbasis pesan, dan layanan web yang ada di perusahaan Anda.

Diagram yang memperlihatkan arsitektur referensi untuk integrasi perusahaan yang menggunakan antrean dan peristiwa.

Unduh file Visio arsitektur ini.

Detail skenario

Arsitektur sebelumnya dibangun pada arsitektur integrasi perusahaan dasar yang lebih sederhana yang menggunakan Azure Logic Apps untuk mengatur alur kerja langsung dengan sistem back-end dan menggunakan Azure API Management untuk membuat katalog API.

Versi arsitektur ini menambahkan dua komponen yang membantu membuat sistem lebih andal dan skalabel:

Arsitektur ini menggunakan komunikasi asinkron melalui broker pesan alih-alih melakukan panggilan langsung dan sinkron ke layanan back-end. Komunikasi asinkron memberikan keuntungan berikut:

  • Menggunakan pola Perataan Beban Berbasis Antrean untuk menangani ledakan beban kerja melalui penyelesaian beban

  • Menggunakan pola Penerbit-Pelanggan sehingga Anda dapat menyiarkan pesan ke beberapa konsumen

  • Melacak kemajuan alur kerja yang berjalan lama dengan andal, bahkan ketika melibatkan beberapa langkah atau beberapa aplikasi

  • Membantu memisahkan aplikasi

  • Terintegrasi dengan sistem berbasis pesan yang ada

  • Menyediakan kemampuan untuk mengantre pesan saat sistem back-end tidak tersedia

Gunakan Event Grid sehingga berbagai komponen dalam sistem dapat bereaksi terhadap peristiwa ketika terjadi, daripada mengandalkan tugas polling atau terjadwal. Mirip dengan antrean dan topik pesan, Event Grid membantu memisahkan aplikasi dan layanan. Jika aplikasi atau layanan menerbitkan peristiwa, pelanggan yang tertarik akan diberi tahu. Anda dapat menambahkan pelanggan baru tanpa memperbarui pengirim.

Banyak layanan Azure mendukung pengiriman peristiwa ke Event Grid. Misalnya, aplikasi logika dapat mendengarkan suatu peristiwa saat file baru ditambahkan ke penyimpanan blob. Pola ini membuat alur kerja reaktif di mana mengunggah file atau menempatkan pesan pada antrean memulai serangkaian proses. Proses mungkin berjalan secara paralel atau dalam urutan tertentu.

Rekomendasi

Pertimbangkan rekomendasi berikut. Untuk rekomendasi selengkapnya, lihat Arsitektur integrasi perusahaan dasar.

Service Bus

Bus Layanan memiliki dua model pengiriman, model penarikan dan model pendorongan yang diproksi:

  • Model penarikan: Penerima terus melakukan polling untuk pesan baru. Jika Anda perlu mengelola beberapa antrean dan waktu polling, polling mungkin tidak efisien. Tetapi model ini dapat menyederhanakan arsitektur Anda karena menghapus komponen dan hop data tambahan.

  • Model pendorongan yang diproksi: Penerima awalnya berlangganan jenis peristiwa tertentu pada topik Event Grid. Saat pesan baru tersedia, Bus Layanan menaikkan dan mengirim acara melalui Event Grid. Kejadian ini kemudian memicu penerima untuk menarik batch pesan berikutnya dari Bus Layanan. Model ini memungkinkan sistem untuk menerima pesan hampir secara real time tetapi tanpa menggunakan sumber daya untuk terus melakukan polling untuk pesan baru. Arsitektur ini menggunakan komponen tambahan yang harus Anda sebarkan, kelola, dan amankan.

Saat Anda membuat alur kerja Azure Logic Apps Standar yang menggunakan pesan Bus Layanan, kami sarankan Anda menggunakan pemicu konektor bawaan Bus Layanan. Konektor bawaan memicu sebagian besar konfigurasi model penarikan tanpa menambahkan biaya tambahan. Kemampuan ini memberikan keseimbangan yang tepat antara biaya, manajemen area permukaan, dan keamanan karena konektor terus mengulang dalam mesin runtime Logic Apps. Untuk informasi selengkapnya, lihat Bus Layanan pemicu konektor bawaan.

Gunakan mode PeekLock untuk mengakses grup pesan. Saat Anda menggunakan PeekLock, aplikasi logika dapat melakukan langkah-langkah untuk memvalidasi setiap pesan sebelum menyelesaikan atau mengabaikan pesan. Pendekatan ini mencegah kehilangan pesan yang tidak disengaja.

Event Grid

Saat pemicu Event Grid diaktifkan, itu berarti bahwa setidaknya satu peristiwa terjadi. Misalnya, saat aplikasi logika mendapatkan pemicu Event Grid untuk pesan Bus Layanan, mungkin ada beberapa pesan yang tersedia untuk diproses.

Pertimbangan

Pertimbangan ini mengimplementasikan pilar Azure Well-Architected Framework, yang merupakan serangkaian tenet panduan yang dapat digunakan untuk meningkatkan kualitas beban kerja. Untuk informasi selengkapnya, lihat Microsoft Azure Well-Architected Framework.

Keandalan

Keandalan memastikan aplikasi Anda dapat mencapai komitmen yang Anda buat kepada pelanggan Anda. Untuk informasi selengkapnya, lihat Daftar periksa tinjauan desain untuk Keandalan.

  • MICROSOFT Entra ID adalah platform SaaS yang terdistribusi secara global dan sangat tersedia.

  • Anda dapat menyebarkan API Management dalam beberapa konfigurasi yang sangat tersedia, sesuai dengan persyaratan bisnis dan toleransi biaya. Untuk informasi selengkapnya, lihat Memastikan ketersediaan dan keandalan API Management.

  • Tingkat Konsumsi Logic Apps mendukung penyimpanan geo-redundan. Untuk informasi selengkapnya, lihat Kelangsungan bisnis dan pemulihan bencana untuk Logic Apps.

  • Definisi sumber daya Event Grid untuk topik, topik sistem, domain, dan langganan peristiwa dan data peristiwa secara otomatis direplikasi di seluruh zona ketersediaan di suatu wilayah. Ketika ada kegagalan di salah satu zona ketersediaan, sumber daya Event Grid secara otomatis gagal ke zona ketersediaan lain tanpa intervensi manusia. Untuk informasi selengkapnya, lihat Pemulihan bencana lintas wilayah dan kelangsungan bisnis.

  • Bus Layanan Premium mendukung pemulihan bencana geografis dan zona ketersediaan. Bus Layanan Standard mendukung replikasi.

Untuk informasi tentang detail ketersediaan terjamin dari setiap layanan, lihat SLA untuk layanan online.

Keamanan

Keamanan memberikan jaminan terhadap serangan yang disukai dan penyalahgunaan data dan sistem berharga Anda. Untuk informasi selengkapnya, lihat Daftar periksa tinjauan desain untuk Keamanan.

Untuk membantu mengamankan Bus Layanan, pasangkan autentikasi Microsoft Entra dengan identitas terkelola. Integrasi MICROSOFT Entra ID untuk sumber daya Bus Layanan menyediakan kontrol akses berbasis peran Azure (RBAC) untuk kontrol terperinci atas akses klien ke sumber daya. Anda dapat menggunakan Azure RBAC untuk memberikan izin kepada prinsip keamanan, seperti pengguna, grup, atau perwakilan layanan aplikasi. Perwakilan layanan aplikasi dalam skenario ini adalah identitas terkelola.

Jika Anda tidak dapat menggunakan ID Microsoft Entra, gunakan autentikasi tanda tangan akses bersama (SAS) untuk memberi pengguna akses dan hak tertentu untuk Bus Layanan sumber daya.

Jika Anda perlu mengekspos antrean atau topik Bus Layanan sebagai titik akhir HTTP, misalnya, untuk memposting pesan baru, gunakan API Management untuk membantu mengamankan antrean dengan fronting titik akhir. Anda kemudian dapat menggunakan sertifikat atau autentikasi OAuth untuk membantu mengamankan titik akhir. Cara termudah untuk membantu mengamankan titik akhir adalah dengan menggunakan aplikasi logika yang memiliki permintaan HTTP atau pemicu respons sebagai perantara.

Layanan Event Grid membantu mengamankan pengiriman peristiwa melalui kode validasi. Jika Anda menggunakan Logic Apps untuk menggunakan peristiwa, validasi bersifat otomatis. Untuk mengetahui informasi selengkapnya, lihat Keamanan dan autentikasi Event Grid.

Keamanan jaringan

Pertimbangkan keamanan jaringan di seluruh desain Anda.

  • Anda dapat mengikat Bus Layanan Premium ke titik akhir layanan subnet jaringan virtual. Konfigurasi ini membantu mengamankan namespace layanan karena hanya menerima lalu lintas dari jaringan virtual resmi. Anda juga dapat menggunakan Azure Private Link untuk hanya mengizinkan lalu lintas privat ke jaringan virtual Anda melalui titik akhir privat.

  • Anda dapat mengonfigurasi Logic Apps Standard dan Premium untuk menerima lalu lintas masuk melalui titik akhir privat dan mengirim lalu lintas keluar melalui integrasi jaringan virtual.

  • Anda dapat menggunakan jaringan virtual Azure untuk membantu mengamankan akses ke instans dan API API Management Anda. Metode ini mendukung titik akhir privat. Untuk informasi selengkapnya, lihat Menggunakan jaringan virtual dengan API Management.

Pengoptimalan Biaya

Pengoptimalan Biaya adalah tentang melihat cara untuk mengurangi pengeluaran yang tidak perlu dan meningkatkan efisiensi operasional. Untuk informasi selengkapnya, lihat Daftar periksa tinjauan desain untuk Pengoptimalan Biaya.

Gunakan kalkulator harga Azure untuk memperkirakan biaya. Berikut beberapa pertimbangan lainnya.

API Management

Anda dikenakan biaya untuk semua instans API Management saat dijalankan. Jika Anda meningkatkan skala, dan kemudian Anda tidak lagi memerlukan tingkat performa tersebut, turunkan skala secara manual atau konfigurasikan penskalaan otomatis.

Untuk beban kerja penggunaan ringan, pertimbangkan tingkat Konsumsi, yang merupakan opsi tanpa server berbiaya rendah. Tingkat Konsumsi ditagih per panggilan API. Tingkatan lain ditagih per jam.

Logic Apps

Logic Apps menggunakan model tanpa server. Penagihan dihitung berdasarkan jumlah tindakan dan panggilan konektor. Untuk informasi selengkapnya, lihat Harga Logic Apps.

Antrean, topik, dan langganan Microsoft Azure Service Bus

Bus Layanan antrean dan langganan mendukung model pendorongan dan penarikan yang diproksi untuk mengirimkan pesan. Dalam model tarik, setiap permintaan polling diukur sebagai tindakan. Bahkan jika Anda mengatur polling panjang ke default 30 detik, biaya bisa tinggi. Kecuali Anda memerlukan pengiriman pesan real-time, pertimbangkan untuk menggunakan model pendorongan yang diproksi.

antrean Bus Layanan disertakan dalam semua tingkatan: Dasar, Standar, dan Premium. Bus Layanan topik dan langganan tersedia di tingkat Standar dan Premium. Untuk informasi selengkapnya, lihat Harga Azure Service Bus.

Event Grid

Event Grid menggunakan model tanpa server. Penagihan dihitung berdasarkan jumlah operasi. Operasi mencakup peristiwa yang masuk ke domain atau topik, kecocokan tingkat lanjut, upaya pengiriman, dan panggilan manajemen. Penggunaan hingga 100.000 operasi tidak dikenai biaya.

Untuk informasi selengkapnya, lihat Harga Event Grid dan Pengoptimalan Biaya Kerangka Kerja yang Dirancang Dengan Baik.

Keunggulan Operasional

Keunggulan Operasional mencakup proses operasi yang menyebarkan aplikasi dan membuatnya tetap berjalan dalam produksi. Untuk informasi selengkapnya, lihat Daftar periksa tinjauan desain untuk Keunggulan Operasional.

Arsitektur referensi integrasi perusahaan dasar menyediakan panduan tentang pola DevOps, yang selaras dengan pilar Keunggulan Operasional Kerangka Kerja Yang Dirancang Dengan Baik.

Mengotomatiskan operasi pemulihan sebanyak mungkin untuk membantu meningkatkan keunggulan operasional. Dengan mempertimbangkan otomatisasi, Anda dapat menggabungkan pemantauan log Azure dengan Azure Automation untuk mengotomatiskan failover sumber daya Bus Layanan Anda. Untuk contoh logika otomatisasi untuk memulai failover, lihat Alur failover.

Efisiensi Performa

Efisiensi Performa adalah kemampuan beban kerja Anda untuk menskalakan untuk memenuhi tuntutan yang ditempatkan di atasnya oleh pengguna dengan cara yang efisien. Untuk informasi selengkapnya, lihat Daftar periksa tinjauan desain untuk Efisiensi Performa.

Untuk mencapai skalabilitas yang lebih tinggi, tingkat Azure Service Bus Premium dapat melakukan peluasan skala jumlah unit pesan. Untuk informasi selengkapnya, lihat Bus Layanan tingkat olahpesan Premium dan Standar dan fitur Autoscaling.

Untuk rekomendasi Bus Layanan lainnya, lihat Praktik terbaik untuk peningkatan performa dengan menggunakan olahpesan Bus Layanan.

Langkah berikutnya