Menjelajahi API gateway
Solusi Anda mungkin terdiri dari beberapa layanan front-end dan back-end. Dalam skenario ini, bagaimana klien tahu titik akhir apa yang akan dipanggil? Apa yang terjadi ketika layanan baru diperkenalkan, atau layanan yang ada direfaktor? Bagaimana layanan menangani penghentian SSL, autentikasi, dan masalah lainnya?
Gateway API Management (juga disebut bidang data atau runtime) adalah komponen layanan yang bertanggung jawab untuk memproksi permintaan API, menerapkan kebijakan, dan mengumpulkan telemetri.
Gateway API berada di antara klien dan layanan. Ini bertindak sebagai proksi terbalik, mengalihkan permintaan dari klien ke layanan. Ini mungkin juga melakukan berbagai tugas lintas-fungsi seperti autentikasi, terminasi SSL, dan pembatasan kecepatan. Jika Anda tidak menyebarkan gateway, klien harus mengirim permintaan langsung ke layanan back-end. Namun, ada beberapa potensi masalah dengan mengekspos layanan langsung ke klien:
- Ini dapat mengakibatkan kode klien yang kompleks. Klien harus melacak beberapa titik akhir, dan menangani kegagalan dengan cara yang tangguh.
- Ini menciptakan koupling antara klien dan backend. Klien perlu tahu bagaimana setiap layanan didekomposisi. Itu membuatnya lebih sulit untuk mempertahankan klien dan juga lebih sulit untuk merefaktor layanan.
- Satu operasi mungkin memerlukan panggilan ke beberapa layanan.
- Setiap layanan yang menghadap publik harus menangani masalah seperti autentikasi, SSL, dan pembatasan tarif klien.
- Layanan harus mengekspos protokol yang ramah klien seperti HTTP atau WebSocket. Ini membatasi pilihan protokol komunikasi.
- Layanan dengan titik akhir publik adalah permukaan serangan potensial, dan harus diperkeras.
Gateway membantu mengatasi masalah ini dengan memisahkan klien dari layanan.
Dikelola dan dihost sendiri
API Management menawarkan gateway yang dikelola dan dihost sendiri:
Terkelola - Gateway terkelola adalah komponen gateway default yang disebarkan di Azure untuk setiap instans API Management di setiap tingkat layanan. Dengan gateway terkelola, semua lalu lintas API mengalir melalui Azure terlepas dari di mana backend yang menerapkan API dihosting.
yang dihost sendiri - Gateway yang dihost sendiri adalah versi opsional yang dikontainerisasi dari gateway terkelola default. 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 dihost sendiri memungkinkan pelanggan dengan infrastruktur TI hibrid untuk mengelola API yang dihosting secara lokal dan di seluruh cloud dari satu layanan API Management di Azure.