Catatan
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba masuk atau mengubah direktori.
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba mengubah direktori.
BERLAKU UNTUK: Semua tingkatan dari manajemen API
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:
Peran gerbang
Gateway API Management (juga disebut bidang data atau runtime) adalah komponen layanan yang bertanggung jawab untuk memproksi permintaan API, menerapkan kebijakan, dan mengumpulkan telemetri.
Khususnya, 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 JWT dan sertifikat yang diajukan bersama permintaan.
- Memberlakukan kuota penggunaan dan batas tarif
- Secara opsional mengubah permintaan dan respons seperti yang ditentukan dalam pernyataan kebijakan
- Jika dikonfigurasi dengan benar, mencache respons untuk meningkatkan kecepatan respons dan meminimalkan beban pada layanan backend
- Memancarkan 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: Terkelola versus gateway 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 dihost sendiri dikemas sebagai kontainer Docker berbasis Linux dan umumnya disebarkan ke Kubernetes, termasuk ke Azure Kubernetes Service dan Kubernetes dengan dukungan Azure Arc.
Setiap gateway yang dihost sendiri dikaitkan dengan sumber daya Gateway dalam instans API Management berbasis cloud tempat gateway menerima pembaruan konfigurasi dan mengkomunikasikan 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, Standard v2, dan Premium v2
- Konsumsi - gateway terkelola yang tersedia di lapis 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.
- Agar fitur yang saat ini didukung oleh gateway yang dihosting sendiri bisa berjalan, pastikan Anda telah memperbarui ke versi utama terbaru dari image container untuk gateway tersebut.
- Lihat juga batasan gateway yang di-host secara mandiri.
Infrastruktur
| Dukungan fitur | Klasik | V2 | Konsumsi | Dihosting secara mandiri | Ruang kerja |
|---|---|---|---|---|---|
| Domain khusus | ✔️ | ✔️ | ✔️ | ✔️ | ❌ |
| Cache bawaan | ✔️ | ✔️ | ❌ | ❌ | ✔️ |
| Cache eksternal yang kompatibel dengan Redis | ✔️ | ✔️ | ✔️ | ✔️ | ❌ |
| Injeksi jaringan virtual | Pengembang, Premium | Premium v2 | ❌ | ✔️1,2 | ✔️ |
| Titik akhir privat masuk | Pengembang, Dasar, Standar, dan Premium | Standar v2 | ❌ | ❌ | ❌ |
| Integrasi jaringan virtual eksternal | ❌ | Standar v2, Premium v2 | ❌ | ❌ | ✔️ |
| Zona ketersediaan | Premi | ✔️3 | ❌ | ✔️1 | ✔️3 |
| Penyebaran multi-wilayah | Premi | ❌ | ❌ | ✔️1 | ❌ |
| Sertifikat akar CA untuk validasi sertifikat | ✔️ | ✔️ | ❌ | ✔️4 | ❌ |
| Sertifikat domain yang dikelola | Pengembang, Dasar, Standar, dan Premium | ❌ | ✔️ | ❌ | ❌ |
| Pengaturan TLS | ✔️ | ✔️ | ✔️ | ✔️ | ❌ |
| HTTP/2 (Klien-ke-gerbang) | ✔️5 | ✔️5 | ❌ | ✔️ | ❌ |
| HTTP/2 (Gateway-ke-backend) | ❌ | ❌ | ❌ | ✔️ | ❌ |
| Deteksi ancaman API dengan Defender untuk API | ✔️ | ✔️ | ❌ | ❌ | ❌ |
1 Itu tergantung pada bagaimana gateway disebarkan, tetapi tetap merupakan tanggung jawab pelanggan.
2 Konektivitas ke gateway v2 yang dihosting sendiri pada titik akhir konfigurasi 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.
Backend API
| Dukungan fitur | Klasik | V2 | Konsumsi | Dihosting secara mandiri | Ruang kerja |
|---|---|---|---|---|---|
| Spesifikasi OpenAPI | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
| Spesifikasi WSDL | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
| Spesifikasi WADL | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
| Aplikasi Logika | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
| Layanan Aplikasi | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
| Aplikasi Fungsi | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
| Aplikasi Kontainer | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
| Service Fabric | Pengembang, Premium | ❌ | ❌ | ❌ | ❌ |
| Pass-through GraphQL | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
| GraphQL Sintetis | ✔️ | ✔️ | ✔️1 | ✔️1 | ❌ |
| Pass-through WebSocket | ✔️ | ✔️ | ❌ | ✔️ | ✔️ |
| Pass-through gRPC | ❌ | ❌ | ❌ | ✔️ | ❌ |
| OData | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
| Azure OpenAI dan LLM | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
| Pemutus sirkuit pada sistem belakang | ✔️ | ✔️ | ❌ | ✔️ | ✔️ |
| Kumpulan backend dengan penyeimbangan beban | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
1 Langganan GraphQL sintetis (pratinjau) tidak didukung.
Kebijakan
Gateway terkelola dan dihost sendiri mendukung semua kebijakan yang tersedia dalam definisi kebijakan dengan pengecualian berikut. Lihat referensi kebijakan untuk detail tentang setiap kebijakan.
| Dukungan fitur | Klasik | V2 | Konsumsi | 1 yang dihost sendiri | Ruang kerja |
|---|---|---|---|---|---|
| Integrasi Dapr | ❌ | ❌ | ❌ | ✔️ | ❌ |
| Pemecah masalah GraphQL dan validasi GraphQL | ✔️ | ✔️ | ✔️ | ❌ | ❌ |
| Mendapatkan konteks otorisasi | ✔️ | ✔️ | ✔️ | ❌ | ❌ |
| Mengautentikasi dengan identitas terkelola | ✔️ | ✔️ | ✔️ | ✔️ | ❌ |
| Azure OpenAI dan cache semantik LLM | ✔️ | ✔️ | ✔️ | ❌ | ❌ |
| Kuota dan batas tarif | ✔️ | ✔️ | ✔️2 | ✔️3 | ✔️ |
1 Kebijakan yang dikonfigurasi yang tidak didukung oleh gateway yang dikelola sendiri dilewati selama eksekusi kebijakan.
2 Batas tarif menurut kunci, kuota menurut kunci, dan kebijakan batas token AI tidak tersedia di tingkat Konsumsi.
3 Pembatasan jumlah permintaan dalam gateway yang dihosting 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 | Konsumsi | Dihosting secara mandiri | Ruang kerja |
|---|---|---|---|---|---|
| Analitik API | ✔️ | ✔️1 | ❌ | ❌ | ❌ |
| Wawasan Aplikasi | ✔️ | ✔️ | ✔️ | ✔️2 | ✔️ |
| Pencatatan 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. Secara opsional kirim metrik ke Azure Monitor, atau konfigurasikan dan pertahankan log di mana gateway yang dihost sendiri ditempatkan secara lokal.
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 | Konsumsi | Dihosting secara mandiri | Ruang kerja |
|---|---|---|---|---|---|
| Pengelola 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 beban gateway menggunakan kondisi produksi yang diperkirakan 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 pada tingkatan Pengembang.)
- Di tingkat Dasar, Standar, dan Premium, konfigurasikan skala otomatis Azure Monitor secara opsional.
- Di tingkat Premium, secara opsional tambahkan dan distribusikan kapasitas gateway di beberapa wilayah.
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.
- Konfigurasikan autoscaling secara opsional untuk memenuhi tuntutan lalu lintas.
Gerbang Ruang Kerja
Skalakan kapasitas dengan menambah dan menghapus unit skala di gateway ruang kerja.
Konten terkait
Pelajari lebih lanjut tentang:
- API Management di Dunia Hibrid dan multicloud
- Metrik kapasitas untuk keputusan penskalaan
- Kemampuan pengamatan dalam API Management
- Kemampuan gateway AI dalam Manajemen API (API Management)