Dalam arsitektur layanan mikro, klien mungkin berinteraksi dengan lebih dari satu layanan front-end. Mengingat fakta ini, bagaimana klien tahu titik akhir apa yang harus dihubungi? Apa yang terjadi jika layanan baru diperkenalkan, atau layanan yang ada direfaktor? Bagaimana layanan menangani penghentian SSL, autentikasi, dan masalah lainnya? Gateway API dapat membantu mengatasi tantangan ini.
Unduh file Visio arsitektur ini.
Apa yang dimaksud dengan gateway API?
Gateway API berada di antara klien dan layanan. Ini bertindak sebagai proksi terbalik, permintaan perutean dari klien ke layanan. Gateway API juga dapat melakukan berbagai tugas lintas sektor seperti autentikasi, penghentian SSL, dan pembatasan tarif. Jika Anda tidak menggunakan gateway, klien harus mengirim permintaan langsung ke layanan front-end. Namun, ada beberapa masalah potensial dengan mengekspos layanan langsung ke klien:
- Hal tersebut dapat menghasilkan kode klien yang kompleks. Klien harus melacak beberapa endpoint, dan menangani kegagalan dengan cara yang tangguh.
- Ini menciptakan sambungan antara klien dan backend. Klien perlu tahu cara layanan individu diurai. Hal tersebut membuat lebih sulit untuk mempertahankan klien dan juga lebih sulit untuk merefaktor layanan.
- Satu operasi mungkin memerlukan panggilan ke beberapa layanan. Hal tersebut dapat menyebabkan beberapa perjalanan pulang pergi jaringan antara klien dan server, menambahkan latensi yang signifikan.
- Setiap layanan yang menghadap publik harus menangani masalah seperti autentikasi, SSL, dan pembatasan tarif klien.
- Layanan harus mengekspos protokol yang mudah digunakan klien seperti HTTP atau WebSocket. Ini membatasi pilihan protokol komunikasi.
- Layanan dengan endpoint publik adalah permukaan serangan potensial, dan harus diperketat.
Gateway membantu mengatasi masalah ini dengan memisahkan klien dari layanan. Gateway dapat melakukan berbagai fungsi yang berbeda, dan Anda mungkin tidak memerlukan semuanya. Fungsi dapat dikelompokkan menjadi pola desain berikut:
Perutean Gateway. Gunakan gateway tersebut sebagai proksi terbalik untuk merutekan permintaan ke satu atau beberapa layanan backend, menggunakan perutean lapisan 7. Gateway menyediakan satu endpoint untuk klien, dan membantu memisahkan klien dari layanan.
Agregasi Gateway. Gunakan gateway tersebut untuk menggabungkan beberapa permintaan individual menjadi satu permintaan. Pola ini berlaku saat satu operasi memerlukan panggilan ke beberapa layanan backend. Klien mengirimkan satu permintaan ke gateway. Gateway mengirimkan permintaan ke berbagai layanan backend, lalu mengagregasi hasilnya dan mengirimkannya kembali ke klien. Ini membantu mengurangi obrolan antara klien dan backend.
Pemindahan Gateway. Gunakan gateway tersebut untuk memindahkan fungsionalitas dari layanan individual ke gateway, khususnya masalah lintas sektoral. Hal ini dapat berguna untuk mengonsolidasikan fungsi-fungsi ini ke dalam satu tempat, dan tidak membuat setiap layanan bertanggung jawab untuk menerapkannya. Ini terutama berlaku untuk fitur yang memerlukan keterampilan khusus untuk diterapkan dengan benar, seperti autentikasi dan otorisasi.
Berikut ini beberapa contoh fungsi yang dapat dibongkar ke gateway:
- Penghentian SSL
- Autentikasi
- Daftar ip yang diizinkan atau daftar blokir
- Batas tarif klien (pembatasan)
- Pengelogan dan pemantauan
- Pembuatan cache respons
- Firewall aplikasi web
- Kompresi GZIP
- Konten statis pelayanan
Memilih teknologi gateway
Berikut adalah beberapa opsi untuk menerapkan gateway API di aplikasi Anda.
Server proksi terbalik. Nginx dan HAProxy adalah server proksi terbalik populer yang mendukung fitur seperti penyeimbangan beban, SSL, dan perutean lapisan 7. Keduanya adalah produk sumber terbuka gratis, dengan edisi berbayar yang menyediakan fitur tambahan dan opsi dukungan. Nginx dan HAProxy keduanya adalah produk matang dengan kumpulan fitur yang beragam dan performa tinggi. Anda dapat memperluasnya dengan modul pihak ketiga atau dengan menulis skrip kustom di Lua. Nginx juga mendukung modul skrip berbasis JavaScript yang disebut sebagai NGINX JavaScript. Modul ini secara resmi bernama nginScript.
Pengontrol ingress jala layanan. Jika Anda menggunakan jala layanan seperti Linkerd atau Istio, pertimbangkan fitur yang disediakan oleh pengontrol ingress untuk jala layanan tersebut. Misalnya, pengontrol ingress Istio mendukung perutean lapisan 7, pengalihan HTTP, percobaan ulang, dan fitur lainnya.
Azure Application Gateway. Application Gateway adalah layanan penyeimbangan beban terkelola yang dapat melakukan perutean lapisan-7 dan penghentian SSL. Ini juga menyediakan firewall aplikasi web (WAF).
Azure Front Door adalah Jaringan Pengiriman Konten (CDN) cloud modern Microsoft yang menyediakan akses cepat, andal, dan aman antara pengguna Anda dan konten web statis dan dinamis aplikasi Anda di seluruh dunia. Azure Front Door mengirimkan konten Anda menggunakan jaringan tepi global Microsoft dengan ratusan titik kehadiran (PoPs) global dan lokal yang didistribusikan di seluruh dunia yang dekat dengan pengguna akhir perusahaan dan konsumen Anda.
Azure API Management. API Management adalah solusi siap pakai untuk menerbitkan API ke pelanggan eksternal dan internal. Ini menyediakan fitur yang berguna untuk mengelola API yang menghadap publik, termasuk pembatasan tarif, pembatasan IP, dan autentikasi menggunakan ID Microsoft Entra atau penyedia identitas lainnya. API Management tidak melakukan penyeimbangan beban apa pun, sehingga harus digunakan bersama dengan load balancer seperti Application Gateway atau proksi terbalik. Untuk informasi tentang menggunakan API Management dengan Application Gateway, lihat Mengintegrasikan API Management di VNet internal dengan Application Gateway.
Saat memilih teknologi gateway, pertimbangkan hal berikut:
Fitur. Opsi yang tercantum di atas semua mendukung perutean lapisan 7, tetapi dukungan untuk fitur lain akan bervariasi. Bergantung pada fitur yang Anda butuhkan, Anda mungkin menyebarkan lebih dari satu gateway.
Penyebaran. Azure Application Gateway dan API Management adalah layanan terkelola. Nginx dan HAProxy biasanya akan berjalan dalam kontainer di dalam kluster, tetapi juga dapat disebarkan ke VM khusus di luar kluster. Ini mengisolasi gateway dari beban kerja lainnya, tetapi menimbulkan overhead manajemen yang lebih tinggi.
Manajemen. Saat layanan diperbarui atau layanan baru ditambahkan, aturan perutean gateway mungkin perlu diperbarui. Pertimbangkan bagaimana proses ini akan dikelola. Pertimbangan serupa berlaku untuk mengelola sertifikat SSL, daftar izin IP, dan aspek konfigurasi lainnya.
Menyebarkan Nginx atau HAProxy ke Kubernetes
Anda dapat menyebarkan Nginx atau HAProxy ke Kubernetes sebagai ReplicaSet atau DaemonSet yang menentukan gambar kontainer Nginx atau HAProxy. Gunakan ConfigMap untuk menyimpan file konfigurasi untuk proksi, dan pasang ConfigMap sebagai volume. Buat layanan jenis LoadBalancer untuk mengekspos gateway melalui Azure Load Balancer.
Alternatifnya adalah membuat Ingress Controller. Ingress Controller adalah sumber daya Kubernetes yang menyebarkan load balancer atau server proksi terbalik. Beberapa penerapan ada, termasuk Nginx dan HAProxy. Sumber daya terpisah yang disebut Ingress menentukan pengaturan untuk Ingress Controller, seperti aturan perutean dan sertifikat TLS. Dengan begitu, Anda tidak perlu mengelola file konfigurasi kompleks yang khusus untuk teknologi server proksi tertentu.
Gateway adalah potensi penyempitan atau titik kegagalan tunggal dalam sistem, jadi selalu sebarkan setidaknya dua replika untuk ketersediaan tinggi. Anda mungkin perlu memperbesar replika lebih jauh, tergantung pada bebannya.
Pertimbangkan juga untuk menjalankan gateway pada kumpulan node khusus di kluster. Keuntungan dari pendekatan ini meliputi:
Isolasi. Semua lalu lintas masuk menuju ke kumpulan node tetap, yang dapat diisolasi dari layanan backend.
Konfigurasi stabil. Jika gateway salah dikonfigurasi, seluruh aplikasi mungkin menjadi tidak tersedia.
Performa. Anda mungkin ingin menggunakan konfigurasi VM tertentu untuk gateway karena alasan performa.
Langkah berikutnya
Artikel sebelumnya telah membahas antarmuka antara layanan mikro atau antara layanan mikro dan aplikasi klien. Secara desain, antarmuka ini memperlakukan setiap layanan sebagai kotak buram. Secara khusus, layanan mikro tidak boleh mengekspos detail penerapan tentang caranya mengelola data. Ini berimplikasi pada integritas data dan konsistensi data, yang dieksplorasi di artikel berikutnya.