Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Pola perutean jalur
Perutean berdasarkan jalur adalah mekanisme pengelompokan beberapa atau semua API di bawah nama host yang sama, dan menggunakan URI permintaan untuk mengisolasi layanan; misalnya, atau. api.example.com/service-a api.example.com/service-b
Kasus penggunaan khas
Sebagian besar tim memilih metode ini karena mereka menginginkan arsitektur sederhana ― pengembang harus mengingat hanya satu URL seperti api.example.com untuk berinteraksi dengan HTTP API. Dokumentasi API seringkali lebih mudah dicerna karena sering disimpan bersama alih-alih dibagi di berbagai portal atau PDF.
Routing berbasis jalur dianggap sebagai mekanisme sederhana untuk berbagi API HTTP. Namun, ini melibatkan overhead operasional seperti konfigurasi, otorisasi, integrasi, dan latensi tambahan karena beberapa hop. Ini juga membutuhkan proses manajemen perubahan yang matang untuk memastikan bahwa kesalahan konfigurasi tidak mengganggu semua layanan.
Pada AWS, ada beberapa cara untuk berbagi API dan rute secara efektif ke layanan yang benar. Bagian berikut membahas tiga pendekatan: HTTP service reverse proxy, API Gateway, dan Amazon CloudFront. Tak satu pun dari pendekatan yang disarankan untuk menyatukan layanan API bergantung pada layanan hilir yang berjalan. AWS Layanan dapat berjalan di mana saja tanpa masalah atau pada teknologi apa pun, selama mereka kompatibel dengan HTTP.
Proxy terbalik layanan HTTP
Anda dapat menggunakan server HTTP seperti NGINX
Konfigurasi berikut untuk NGINX secara dinamis memetakan permintaan HTTP ke. api.example.com/my-service/ my-service.internal.api.example.com
server { listen 80; location (^/[\w-]+)/(.*) { proxy_pass $scheme://$1.internal.api.example.com/$2; } }
Diagram berikut menggambarkan layanan HTTP metode reverse proxy.
Pendekatan ini mungkin cukup untuk beberapa kasus penggunaan yang tidak menggunakan konfigurasi tambahan untuk mulai memproses permintaan, memungkinkan API hilir mengumpulkan metrik dan log.
Untuk bersiap-siap menghadapi kesiapan produksi operasional, Anda akan ingin dapat menambahkan observabilitas ke setiap tingkat tumpukan Anda, menambahkan konfigurasi tambahan, atau menambahkan skrip untuk menyesuaikan titik masuk API Anda untuk memungkinkan fitur yang lebih canggih seperti pembatasan tarif atau token penggunaan.
Pro
Tujuan utama dari metode proxy balik layanan HTTP adalah untuk menciptakan pendekatan yang dapat diskalakan dan dikelola untuk menyatukan API ke dalam satu domain sehingga tampak koheren untuk setiap konsumen API. Pendekatan ini juga memungkinkan tim layanan Anda untuk menerapkan dan mengelola API mereka sendiri, dengan overhead minimal setelah penerapan. AWS layanan terkelola untuk penelusuran, seperti AWS X-Ray
Kontra
Kelemahan utama dari pendekatan ini adalah pengujian ekstensif dan manajemen komponen infrastruktur yang diperlukan, meskipun ini mungkin tidak menjadi masalah jika Anda memiliki tim rekayasa keandalan situs (SRE) di tempat.
Ada titik kritis biaya dengan metode ini. Pada volume rendah hingga menengah, ini lebih mahal daripada beberapa metode lain yang dibahas dalam panduan ini. Pada volume tinggi, ini sangat hemat biaya (sekitar 100 ribu transaksi per detik atau lebih baik).
API Gateway
Layanan Amazon API Gatewayapi.example.com, dan kemudian permintaan proxy ke layanan bersarang; misalnya,. billing.internal.api.example.com
Anda mungkin tidak ingin terlalu terperinci dengan memetakan setiap jalur di setiap layanan di gateway API root atau inti. Sebagai gantinya, pilih jalur wildcard seperti meneruskan permintaan /billing/* ke layanan penagihan. Dengan tidak memetakan setiap jalur di gateway API root atau inti, Anda mendapatkan lebih banyak fleksibilitas atas API Anda, karena Anda tidak perlu memperbarui gateway API root dengan setiap perubahan API.
Pro
Untuk mengontrol alur kerja yang lebih kompleks, seperti mengubah atribut permintaan, REST API mengekspos Apache Velocity Template Language (VTL) untuk memungkinkan Anda memodifikasi permintaan dan respons. REST API dapat memberikan manfaat tambahan seperti ini:
-
Auth N/Z dengan AWS Identity and Access Management (IAM), Amazon Cognito, atau otorisasi AWS Lambda
-
Token penggunaan untuk mendorong konsumen ke berbagai tingkatan (lihat permintaan Throttle API untuk throughput yang lebih baik dalam dokumentasi API Gateway)
Kontra
Pada volume tinggi, biaya mungkin menjadi masalah bagi beberapa pengguna.
CloudFront
Anda dapat menggunakan fitur pemilihan asal dinamisapi.example.com.
Kasus penggunaan khas
Logika perutean hidup sebagai kode dalam fungsi Lambda @Edge, sehingga mendukung mekanisme perutean yang sangat dapat disesuaikan seperti pengujian A/B, rilis kenari, penandaan fitur, dan penulisan ulang jalur. Ini diilustrasikan dalam diagram berikut.
Pro
Jika Anda memerlukan respons API caching, metode ini adalah cara yang baik untuk menyatukan kumpulan layanan di balik satu titik akhir. Ini adalah metode hemat biaya untuk menyatukan koleksi API.
Juga, CloudFront mendukung enkripsi tingkat lapangan serta integrasi dengan AWS WAF untuk pembatasan tarif dasar dan ACL dasar.
Kontra
Metode ini mendukung maksimal 250 asal (layanan) yang dapat disatukan. Batas ini cukup untuk sebagian besar penerapan, tetapi dapat menyebabkan masalah dengan sejumlah besar API saat Anda mengembangkan portofolio layanan Anda.
Memperbarui fungsi Lambda @Edge saat ini membutuhkan waktu beberapa menit. CloudFront juga membutuhkan waktu hingga 30 menit untuk menyelesaikan penyebaran perubahan ke semua titik kehadiran. Ini pada akhirnya memblokir pembaruan lebih lanjut sampai selesai.
