Gateway API di Azure API Management
BERLAKU UNTUK: Semua tingkatAN API Management
Artikel ini menyediakan informasi tentang peran dan fitur komponen gateway API Management dan membandingkan gateway yang dapat Anda sebarkan.
Informasi terkait:
Untuk gambaran umum skenario, komponen, dan konsep API Management, lihat Apa itu Azure API Management?
Untuk informasi selengkapnya tentang tingkat dan fitur layanan API Management, lihat:
- Tingkat API Management
- Perbandingan berbasis fitur dari tingkat Azure API Management.
Peran gateway
Gateway API Management (juga disebut data plane atau runtime) adalah komponen layanan yang bertanggung jawab untuk memproksi permintaan API, menerapkan kebijakan, dan mengumpulkan telemetri.
Utamanya, gateway:
- Bertindak sebagai fasad untuk layanan backend dengan menerima panggilan API dan merutekannya ke backend yang sesuai
- Memverifikasi kunci API dan kredensial lainnya seperti token dan sertifikat JWT yang disajikan dengan permintaan
- Memberlakukan kuota penggunaan dan batas tarif
- Secara opsional mengubah permintaan dan tanggapan sebagaimana ditentukan dalam pernyataan kebijakan
- Apabila dikonfigurasi, menerapkan cache pada respons untuk meningkatkan latensi respons dan meminimalkan muatan pada layanan backend
- Mengeluarkan log, metrik, dan jejak untuk pemantauan, pelaporan, dan pemecahan masalah
Catatan
Semua permintaan ke gateway API Management, termasuk yang ditolak oleh konfigurasi kebijakan, dihitung terhadap batas tarif, kuota, dan batas penagihan yang dikonfigurasi jika diterapkan di tingkat layanan.
Terkelola dan dihost sendiri
API Management menawarkan gateway terkelola dan dihost sendiri:
Terkelola - Gateway terkelola adalah komponen gateway default yang disebarkan di Azure untuk setiap instans API Management di setiap tingkat layanan. Gateway terkelola mandiri juga dapat dikaitkan dengan ruang kerja dalam instans API Management. Dengan gateway terkelola, semua lalu lintas API mengalir melalui Azure terlepas dari tempat backend yang mengimplementasikan API dihosting.
Catatan
Karena perbedaan dalam arsitektur layanan yang mendasar, gateway yang disediakan di berbagai tingkat layanan API Management memiliki beberapa perbedaan dalam kemampuan. Untuk detailnya, lihat bagian Perbandingan fitur: Gateway terkelola versus yang dihost sendiri.
Dihost sendiri - Gateway yang dihost sendiri adalah versi opsional yang dikontainerisasi dari gateway terkelola default yang tersedia di tingkat layanan tertentu. Ini berguna untuk skenario hibrid dan multicloud di mana ada persyaratan untuk menjalankan gateway dari Azure di lingkungan yang sama tempat backend API dihosting. Gateway yang dihosting sendiri memungkinkan pelanggan dengan infrastruktur TI hibrid untuk mengelola API yang dihosting di lokasi dan di seluruh cloud dari satu layanan API Management di Azure.
Gateway yang dihosting sendiri dikemas sebagai kontainer Docker berbasis Linux dan umumnya disebarkan ke Kubernetes, termasuk ke Azure Kubernetes Service dan Kubernetes yang mendukung Azure Arc.
Setiap gateway yang dihost sendiri dikaitkan dengan sumber daya Gateway dalam instans API Management berbasis cloud tempat gateway menerima pembaruan konfigurasi dan mengomunikasikan status.
Perbandingan fitur: Gateway terkelola versus yang dihost sendiri
Tabel berikut membandingkan fitur yang tersedia di gateway API Management berikut:
- Klasik - gateway terkelola yang tersedia di tingkat layanan Pengembang, Dasar, Standar, dan Premium (sebelumnya dikelompokkan sebagai tingkat khusus )
- V2 - gateway terkelola yang tersedia di tingkat Dasar v2 dan Standar v2
- Konsumsi - gateway terkelola yang tersedia di tingkat Konsumsi
- Dihost sendiri - gateway opsional yang dihost sendiri tersedia di tingkat layanan tertentu
- Ruang kerja - gateway terkelola yang tersedia di ruang kerja di tingkat layanan tertentu
Catatan
- Beberapa fitur gateway terkelola dan yang dihost sendiri hanya didukung di tingkat layanan tertentu atau dengan lingkungan penyebaran tertentu untuk gateway yang dihost sendiri.
- Untuk fitur gateway yang didukung saat ini, pastikan Anda telah meningkatkan ke versi utama terbaru dari gambar kontainer gateway yang dihost sendiri.
- Lihat juga batasan gateway yang dihost sendiri.
Infrastruktur
| Dukungan fitur | Klasik | V2 | Consumption | Dihosting sendiri | Ruang kerja |
|---|---|---|---|---|---|
| Domain kustom | ✔️ | ✔️ | ✔️ | ✔️ | ❌ |
| Cache bawaan | ✔️ | ✔️ | ❌ | ❌ | ✔️ |
| Cache eksternal yang kompatibel dengan Redis | ✔️ | ✔️ | ✔️ | ✔️ | ❌ |
| Injeksi jaringan virtual | Pengembang, Premium | ❌ | ❌ | ✔️1,2 | ✔️ |
| Titik akhir privat masuk | Pengembang, Dasar, Standar, dan Premium | ❌ | ❌ | ❌ | ❌ |
| Integrasi jaringan virtual keluar | ❌ | Standard V2 | ❌ | ❌ | ✔️ |
| Zona ketersediaan | Premium | ✔️3 | ❌ | ✔️1 | ✔️3 |
| Penyebaran multi-wilayah | Premium | ❌ | ❌ | ✔️1 | ❌ |
| Sertifikat akar CA untuk validasi sertifikat | ✔️ | ✔️ | ❌ | ✔️4 | ❌ |
| Sertifikat domain terkelola | Pengembang, Dasar, Standar, dan Premium | ❌ | ✔️ | ❌ | ❌ |
| Pengaturan TLS | ✔️ | ✔️ | ✔️ | ✔️ | ❌ |
| HTTP/2 (Client-to-gateway) | ✔️5 | ✔️5 | ❌ | ✔️ | ❌ |
| HTTP/2 (Gateway-ke-backend) | ❌ | ❌ | ❌ | ✔️ | ❌ |
| Deteksi ancaman API dengan Defender untuk API | ✔️ | ✔️ | ❌ | ❌ | ❌ |
1 Tergantung pada cara gateway disebarkan, tetapi merupakan tanggung jawab pelanggan.
2 Konektivitas ke titik akhir konfigurasi gateway v2 yang dihost sendiri memerlukan resolusi DNS dari nama host titik akhir.
3 Dua zona diaktifkan secara default; tidak dapat dikonfigurasi.
4 sertifikat akar CA untuk gateway yang dihost sendiri dikelola secara terpisah per gateway
5 Protokol klien perlu diaktifkan.
API backend
| Dukungan fitur | Klasik | V2 | Consumption | Dihosting sendiri | Ruang kerja |
|---|---|---|---|---|---|
| spesifikasi OpenAPI | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
| Spesifikasi WSDL | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
| Spesifikasi WADL | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
| Aplikasi Logika | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
| App Service | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
| Aplikasi Fungsi | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
| Aplikasi Kontainer | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
| Service Fabric | Pengembang, Premium | ❌ | ❌ | ❌ | ❌ |
| Pass-through GraphQL | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
| Synthetic GraphQL | ✔️ | ✔️ | ✔️1 | ✔️1 | ❌ |
| Pass-through WebSocket | ✔️ | ✔️ | ❌ | ✔️ | ❌ |
| Pass-through gRPC | ❌ | ❌ | ❌ | ✔️ | ❌ |
| OData | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
| Azure OpenAI | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
| Pemutus sirkuit di backend | ✔️ | ✔️ | ❌ | ✔️ | ✔️ |
| Kumpulan backend seimbang beban | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
1 Langganan GraphQL sintetis (pratinjau) tidak didukung.
Kebijakan
Gateway terkelola dan yang dihost sendiri mendukung semua kebijakan yang tersedia dalam definisi kebijakan dengan pengecualian berikut.
| Dukungan fitur | Klasik | V2 | Consumption | 1 yang dihostsendiri | Ruang kerja |
|---|---|---|---|---|---|
| Integrasi Dapr | ❌ | ❌ | ❌ | ✔️ | ❌ |
| Pemecah masalah GraphQL dan validasi GraphQL | ✔️ | ✔️ | ✔️ | ❌ | ❌ |
| Mendapatkan konteks otorisasi | ✔️ | ✔️ | ✔️ | ❌ | ❌ |
| Kuota dan batas tarif | ✔️ | ✔️2 | ✔️3 | ✔️4 | ✔️ |
1 Kebijakan yang dikonfigurasi yang tidak didukung oleh gateway yang dihost sendiri dilewati selama eksekusi kebijakan.
2 Kuota berdasarkan kebijakan kunci tidak tersedia di tingkat v2.
3 Batas tarif menurut kunci, kuota menurut kunci, dan kebijakan batas token Azure OpenAI tidak tersedia di tingkat Konsumsi.
4 Jumlah batas laju dalam gateway yang dihost sendiri dapat dikonfigurasi untuk disinkronkan secara lokal (di antara instans gateway di seluruh node kluster), misalnya, melalui penyebaran bagan Helm untuk Kubernetes atau menggunakan templat penyebaran portal Azure. Namun, jumlah batas laju tidak disinkronkan dengan sumber daya gateway lain yang dikonfigurasi dalam instans API Management, termasuk gateway terkelola di cloud. Pelajari lebih lanjut
Pemantauan
Untuk detail tentang opsi pemantauan, lihat Pengamatan di Azure API Management.
| Dukungan fitur | Klasik | V2 | Consumption | Dihosting sendiri | Ruang kerja |
|---|---|---|---|---|---|
| Analitik API | ✔️ | ✔️1 | ❌ | ❌ | ❌ |
| Application Insights | ✔️ | ✔️ | ✔️ | ✔️2 | ✔️ |
| Pengelogan melalui Event Hubs | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
| Metrik di Azure Monitor | ✔️ | ✔️ | ✔️ | ✔️ | ❌ |
| Pengumpul OpenTelemetry | ❌ | ❌ | ❌ | ✔️ | ❌ |
| Meminta log di Azure Monitor dan Analitik Log | ✔️ | ✔️ | ❌ | ❌3 | ❌ |
| Metrik dan log lokal | ❌ | ❌ | ❌ | ✔️ | ❌ |
| Pelacakan permintaan | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
1 Tingkat v2 mendukung analitik berbasis Azure Monitor.
2 Gateway menggunakan buffer memori bawaan Azure Application Insight dan tidak memberikan jaminan pengiriman.
3 Gateway yang dihost sendiri saat ini tidak mengirim log sumber daya (log diagnostik) ke Azure Monitor. Anda secara opsional dapat mengirim metrik ke Azure Monitor, atau mengonfigurasikan dan mempertahankan log secara lokal tempat gateway yang dihost sendiri disebarkan.
Autentikasi dan otorisasi
Gateway terkelola dan yang dihost sendiri mendukung semua opsi autentikasi dan otorisasi API yang tersedia dengan pengecualian berikut.
| Dukungan fitur | Klasik | V2 | Consumption | Dihosting sendiri | Ruang kerja |
|---|---|---|---|---|---|
| Manajer kredensial | ✔️ | ✔️ | ✔️ | ❌ | ❌ |
Throughput dan penskalaan gateway
Penting
Throughput dipengaruhi oleh jumlah dan tingkat koneksi klien bersamaan, jenis dan jumlah kebijakan yang dikonfigurasi, ukuran payload, performa API backend, serta faktor lainnya. Throughput gateway yang dihost sendiri juga tergantung pada kapasitas komputasi (CPU dan memori) host tempat gateway tersebut berjalan. Lakukan pengujian muatan gateway menggunakan kondisi produksi yang diantisipasi untuk menentukan throughput yang diharapkan secara akurat.
Gateway terkelola
Untuk perkiraan throughput gateway maksimum di tingkat layanan API Management, lihat harga API Management.
Penting
Angka throughput disajikan hanya sebagai informasi dan tidak boleh diandalkan untuk perencanaan kapasitas dan anggaran. Lihat harga API Management untuk detailnya.
Tingkat klasik
- Skalakan kapasitas gateway dengan menambahkan dan menghapus unit skala, atau meningkatkan tingkat layanan. (Penskalaan tidak tersedia di tingkat Pengembang.)
- Di tingkat Dasar, Standar, dan Premium, konfigurasikan skala otomatis Azure Monitor secara opsional.
- Di tingkat Premium, tambahkan dan distribusikan kapasitas gateway di beberapa wilayah secara opsional.
Tingkat v2
- Skalakan kapasitas gateway dengan menambahkan dan menghapus unit skala, atau meningkatkan tingkat layanan.
Tingkat konsumsi
- Instans API Management pada tingkat Konsumsi menskalakan secara otomatis berdasarkan lalu lintas.
Gateway yang dihost sendiri
- Di lingkungan seperti Kubernetes, tambahkan beberapa replika gateway untuk menangani penggunaan yang diharapkan.
- Secara opsional konfigurasikan penskalaan otomatis untuk memenuhi permintaan lalu lintas.
Gateway ruang kerja
Skalakan kapasitas dengan menambahkan dan menghapus unit skala di gateway ruang kerja.
Konten terkait
Manfaatkan lebih banyak tentang:
- API Management di Dunia Hibrid dan multicloud
- Metrik kapasitas untuk keputusan penskalaan
- Kemampuan pengamatan dalam API Management
- Kemampuan gateway GenAI dalam API Management