Pola Agregasi Gateway

Gunakan gateway untuk mengagregasi beberapa permintaan individual menjadi satu permintaan. Pola ini berguna ketika klien harus melakukan beberapa panggilan ke sistem back-end yang berbeda untuk melakukan operasi.

Konteks dan masalah

Untuk melakukan satu tugas, klien mungkin harus melakukan beberapa panggilan ke berbagai layanan back-end. Aplikasi yang bergantung pada banyak layanan untuk melakukan tugas harus mengeluarkan sumber daya pada setiap permintaan. Ketika fitur atau layanan baru ditambahkan ke aplikasi, permintaan tambahan diperlukan, yang selanjutnya meningkatkan persyaratan sumber daya dan panggilan jaringan. Obrolan antara klien dan back end ini dapat berdampak buruk pada performa dan skala aplikasi. Arsitektur layanan mikro telah membuat masalah ini lebih umum karena aplikasi yang dibangun di sekitar banyak layanan yang lebih kecil memiliki jumlah panggilan lintas layanan yang lebih tinggi.

Dalam diagram berikut, klien mengirim permintaan ke setiap layanan (bernomor 1, 2, dan 3). Setiap layanan memproses permintaan dan mengembalikan respons ke aplikasi (bernomor 4, 5, dan 6). Mengirim permintaan individual dengan cara ini melalui jaringan seluler yang memiliki latensi tinggi tidak efisien dan dapat menyebabkan kehilangan konektivitas atau respons yang tidak lengkap. Setiap permintaan mungkin berjalan secara paralel. Namun, aplikasi masih harus mengirim, menunggu, dan memproses data untuk setiap permintaan pada koneksi terpisah, yang meningkatkan kemungkinan kegagalan.

Diagram yang memperlihatkan klien melakukan panggilan terpisah ke beberapa layanan back-end dan menerima respons individual. Panah menghubungkan aplikasi ke layanan 1, 2, dan 3 di kedua arah.

Solusi

Gunakan gateway untuk mengurangi terlalu banyaknya komunikasi antara klien dan layanan. Gateway menerima permintaan klien, mengirimkan permintaan ke berbagai sistem back-end, dan menggabungkan hasilnya sebelum mengirimkannya kembali ke klien.

Pola ini dapat mengurangi jumlah permintaan yang dilakukan aplikasi ke layanan back-end dan meningkatkan performa aplikasi melalui jaringan latensi tinggi.

Dalam diagram berikut, aplikasi mengirimkan permintaan ke gateway (1). Permintaan berisi paket permintaan tambahan. Gateway menguraikan permintaan ini dan memproses setiap permintaan dengan mengirimkannya ke layanan yang relevan (2). Setiap layanan mengembalikan respons ke gateway (3). Gateway menggabungkan tanggapan dari setiap layanan dan mengirimkan respons ke aplikasi (4). Aplikasi membuat satu permintaan dan hanya menerima satu respons dari gateway.

Diagram memperlihatkan aplikasi yang mengirim satu permintaan ke gateway, yang memanggil beberapa layanan back-end dan mengembalikan respons agregat. Tiga panah menunjuk dari gateway ke layanan 1, 2, dan 3. Tiga panah mengarah dari layanan kembali ke gateway. Satu panah menunjuk dari aplikasi ke gateway, dan panah lain menunjuk dari gateway ke aplikasi.

Masalah dan pertimbangan

Pertimbangkan poin-poin berikut saat Anda memutuskan cara menerapkan pola ini:

• Gateway tidak boleh menimbulkan ketergantungan antarlayanan di antara layanan back-end.

• Gateway harus terletak di dekat layanan back-end untuk mengurangi latensi sebanyak mungkin.

• Layanan gateway mungkin menyebabkan satu titik kegagalan (SPoF). Pastikan gateway dirancang dengan benar untuk memenuhi persyaratan ketersediaan aplikasi Anda.

• Gateway mungkin memperkenalkan hambatan. Pastikan gateway memiliki performa yang memadai untuk menangani beban saat ini dan dapat diskalakan untuk memenuhi pertumbuhan yang Anda antisipasi.

• Lakukan pengujian beban terhadap gateway untuk memastikan bahwa Anda tidak menyebabkan kegagalan berantai pada layanan.

• Terapkan desain tangguh dengan menggunakan teknik seperti sekat, pemutusan sirkuit, coba lagi, dan batas waktu.

• Jika satu atau beberapa panggilan layanan memakan waktu terlalu lama, mungkin masih dapat diterima untuk menghentikan proses karena batas waktu terlampaui dan mengembalikan sebagian data. Pertimbangkan bagaimana aplikasi Anda akan menangani skenario ini.

• Gunakan input dan output asinkron (I/O) untuk memastikan bahwa penundaan di ujung belakang tidak menyebabkan masalah performa dalam aplikasi.

• Terapkan pelacakan terdistribusi dengan menggunakan ID korelasi untuk melacak setiap panggilan individu.

• Pantau metrik permintaan dan ukuran respons.

• Pertimbangkan untuk mengembalikan data cache sebagai strategi failover untuk menangani kegagalan.

• Daripada membangun fungsi agregasi ke dalam gateway, pertimbangkan untuk menempatkan layanan agregasi di belakang gateway. Penggabungan permintaan kemungkinan memiliki kebutuhan sumber daya yang berbeda dibandingkan dengan layanan lain dalam gateway dan dapat memengaruhi fungsionalitas perutean serta pengalihan beban gateway.

Kapan menggunakan pola ini

Gunakan pola ini ketika:

• Klien perlu berkomunikasi dengan beberapa layanan back-end untuk melakukan operasi.

• Klien mungkin menggunakan jaringan yang memiliki latensi signifikan, seperti jaringan seluler.

Pola ini mungkin tidak cocok ketika:

• Anda ingin mengurangi jumlah panggilan antara klien dan satu layanan dalam beberapa operasi. Dalam skenario itu, menambahkan operasi batch ke layanan mungkin lebih cocok.

• Klien atau aplikasi terletak di dekat layanan back-end dan latensi bukanlah faktor yang signifikan.

Desain beban kerja

Evaluasi cara menggunakan pola Agregasi Gateway dalam desain beban kerja untuk mengatasi tujuan dan prinsip yang tercakup dalam pilar kerangka kerja Azure Well-Architected. Tabel berikut memberikan panduan tentang bagaimana pola ini mendukung tujuan setiap pilar.

Prinsip Dasar	Bagaimana pola ini mendukung tujuan pilar
Keputusan desain Keandalan membantu beban kerja Anda menjadi tangguh tidak berfungsi dan memastikan bahwa memulihkan ke keadaan yang berfungsi penuh setelah kegagalan terjadi.	Dengan topologi ini, Anda dapat mengalihkan penanganan kesalahan sementara dari implementasi terdistribusi di seluruh klien ke implementasi terpusat. - Rekomendasi untuk menangani kesalahan sementara
Keputusan desain keamanan membantu memastikan kerahasiaan, integritas, dan ketersediaan data dan sistem beban kerja Anda.	Topologi ini sering mengurangi jumlah titik sentuh yang dimiliki klien dengan sistem, yang mengurangi area permukaan publik dan titik autentikasi. Back-end yang diagregasikan dapat tetap sepenuhnya terisolasi dari jaringan klien. - Segmentasi SE:04 - SE:08 Amankan sumber daya
Keunggulan Operasional membantu memberikan kualitas beban kerja melalui proses yang distandarisasi dan kohesi tim.	Pola ini memungkinkan logika back-end berkembang secara independen dari klien. Pemisahan ini memberi Anda fleksibilitas untuk mengubah implementasi layanan berantai, atau bahkan sumber data, tanpa perlu mengubah titik sentuh klien. - Alat dan proses OE:04
Efisiensi Performa membantu beban kerja Anda memenuhi permintaan secara efisien melalui pengoptimalan dalam penskalaan, data, dan kode.	Desain ini dapat menimbulkan lebih sedikit latensi daripada desain di mana klien membuat beberapa koneksi. Penyimpanan cache dalam implementasi agregasi meminimalkan permintaan ke sistem backend. - PE:03 Pilih layanan - Kinerja data PE:08

Jika pola ini memperkenalkan kompromi di dalam pilar, bandingkan dengan tujuan pilar lain.

Example

Pertimbangkan aplikasi berbasis layanan mikro yang memberikan pengalaman ringkasan pesanan bagi pelanggan. Saat pengguna membuka halaman pesanan, aplikasi harus mengambil data dari beberapa layanan back-end, seperti layanan pesanan, layanan pengiriman, dan layanan profil pelanggan.

Dalam arsitektur layanan mikro, layanan ini diimplementasikan dan disebarkan secara independen. Tanpa agregasi, klien harus memanggil setiap layanan secara langsung, yang meningkatkan latensi dan kompleksitas.

Untuk mengatasi masalah ini, aplikasi menggunakan Azure API Management sebagai lapisan agregasi gateway. Klien mengirimkan satu permintaan ke operasi API Management yang bertindak sebagai pengumpul untuk informasi pesanan. API Management kemudian memanggil API back-end pendukung dan mengembalikan respons terpadu kepada klien.

Anda dapat menerapkan komposisi ringan ini dengan menggunakan kebijakan permintaan kirim API Management untuk mengambil data dari beberapa layanan dan membuat respons gabungan. Dalam contoh ini, layanan back-end berjalan di lingkungan Azure Container Apps, dan Anda menyebarkan setiap layanan back-end sebagai aplikasi kontainer yang tetap tersembunyi dari akses klien langsung.

Dalam diagram, panah menunjuk dari pelanggan ke API Management. Panah lain mengarah dari API Management dan bercabang menjadi tiga panah yang menunjuk ke pesanan, pengiriman, dan profil pelanggan. Lingkungan aplikasi ditunjukkan di bawah ini dan di sebelah kanan profil pelanggan. Sebuah panah menunjuk dari ringkasan payload ke API Management.

Unduh file Visio dari arsitektur ini.

Alur permintaan mengikuti langkah-langkah berikut:

1. Klien mengirim permintaan ke titik akhir ringkasan pesanan yang diekspos melalui API Management.

2. API Management menerapkan kebijakan yang mengumpulkan data pesanan, pengiriman, dan profil pelanggan dari layanan back-end.

3. API Management menggabungkan respons back-end menjadi satu payload ringkasan pesanan.

4. API Management mengembalikan respons agregat ke klien.

Dengan memperkenalkan lapisan agregasi ini, solusinya mengurangi perjalanan pulang pergi klien ke layanan dan menyederhanakan interaksi klien. Lapisan ini bertanggung jawab untuk menangani layanan backend yang tidak merespons secara mulus dan mencegah kegagalan merambat ke seluruh respons gabungan. Perkuat kebijakan API Management Anda dengan menggunakan batas waktu per permintaan, penanganan kesalahan kondisional, dan pemutus sirkuit.

Jika salah satu panggilan back-end kehabisan waktu atau mengembalikan kesalahan, API Management dapat menerapkan perilaku yang paling sesuai dengan operasi. Misalnya, sistem itu mungkin mengembalikan respons parsial jika kehilangan sebagian data dapat diterima, atau mungkin gagal memproses seluruh permintaan jika data pesanan yang lengkap dan konsisten diperlukan. Buat keputusan ini secara eksplisit dalam desain kebijakan sehingga klien mengalami perilaku yang dapat diprediksi.

Pendekatan ini berfungsi dengan baik ketika gateway melakukan komposisi ringan, pemformatan, dan perakitan respon. Jika agregasi memerlukan logika domain kustom, transformasi kompleks, atau orkestrasi yang berjalan lebih lama, tempatkan fungsionalitas tersebut dalam layanan kustom khusus di belakang gateway.

Untuk pemantauan, kumpulkan telemetri di seluruh jalur permintaan penuh sehingga Anda dapat menghubungkan perilaku API Management dengan latensi back-end. Visibilitas ini penting dalam pola agregasi gateway karena satu operasi klien bergantung pada beberapa panggilan back-end, dan kegagalan atau respons lambat dalam satu dependensi dapat memengaruhi hasil agregat akhir. Gunakan Azure Monitor sebagai platform observabilitas pusat. Kumpulkan log dan metrik API Management untuk gateway dan jalur eksekusi kebijakan, lalu aktifkan pemantauan untuk Container Apps guna mengumpulkan log dan metrik aplikasi dari aplikasi kontainer backend. Arahkan API Management dan telemetri back-end ke ruang kerja Log Analytics untuk kueri, peringatan, dan pemecahan masalah terpadu. Dengan telemetri ini, Anda dapat mendeteksi pola batas waktu, mengidentifikasi dependensi back-end mana yang menyebabkan respons parsial atau gagal, dan membuat pemberitahuan untuk latensi atau tingkat kesalahan yang ditinggikan.

Langkah berikutnya

• Menggunakan layanan eksternal dari layanan API Management
• Kebijakan kirim permintaan
• Dokumentasi Container Apps

Sumber daya terkait

• Backend untuk pola Frontend
• Pola Desain Gateway Offloading
• Pola Gateway Routing