Endpoint adalah sistem pengelolaan API terdistribusi yang terdiri dari layanan, runtime, dan alat. Endpoint menyediakan pengelolaan, pemantauan, dan autentikasi.
Komponen yang membentuk Endpoint adalah:
Extensible Service Proxy (ESP) atau Extensible Service Proxy V2 (ESPv2) - untuk memasukkan fungsi Endpoint.
Service Control - untuk menerapkan aturan pengelolaan API.
Pengelolaan Layanan - untuk mengonfigurasi aturan pengelolaan API.
Google Cloud CLI - untuk men-deploy dan mengelola.
Konsol Google Cloud - untuk logging, pemantauan, dan berbagi.
Arsitektur endpoint
Komponen endpoint
ESP
ESP adalah proxy berbasis NGINX yang berjalan di depan backend dan memasukkan fungsi Endpoint seperti autentikasi, pemantauan, dan logging. ESP mengambil konfigurasi layanan dari Pengelolaan Layanan dan menggunakannya untuk memvalidasi permintaan masuk.
ESP dirancang bagi Anda untuk men-deploy-nya di lingkungan dalam container serta memvalidasi JWT dan token ID Google. API ini menggunakan berbagai teknik, seperti panggilan cache dan asinkron yang berat agar tetap ringan dan berperforma tinggi.
Dukungan ESP tersedia untuk platform berikut:
ESPv2
ESPv2 adalah proxy berbasis Envoy berperforma tinggi dan skalabel yang berjalan di depan backend OpenAPI atau gRPC API. Endpoint di ESPv2 mendukung Spesifikasi OpenAPI dan spesifikasi gRPC versi 2.
ESPv2 terintegrasi dengan Infrastruktur Layanan Google untuk mengaktifkan fitur pengelolaan API dalam skala besar, termasuk autentikasi, laporan telemetri, metrik, dan keamanan.
Dukungan ESPv2 tersedia untuk platform berikut:Service Control
Kontrol Layanan menerapkan aturan pengelolaan API saat runtime, seperti autentikasi kunci, pemantauan, dan logging. Kontrol Layanan menyediakan metode berikut:
Check - memverifikasi autentikasi dan kunci API, serta menunjukkan apakah panggilan harus diizinkan
Report - memberi tahu sistem pencatatan untuk logging dan pemantauan
Pengelolaan Layanan
Anda dapat menjelaskan perilaku layanan gRPC dalam file YAML yang disebut sebagai konfigurasi Endpoint. Anda men-deploy konfigurasi Endpoint dan file.proto yang dikompilasi ke Pengelolaan Layanan menggunakan gcloud CLI, yang mengonfigurasi aturan pengelolaan API.
Tugas terkait konfigurasi lainnya juga terjadi di sini, seperti membagikan API Anda
dengan developer lain, mengaktifkan atau menonaktifkan API di project yang berbeda, dan
membuat kunci API.
Gcloud CLI
Gcloud CLI menyediakan Google Cloud CLI yang dapat Anda gunakan untuk melakukan panggilan ke berbagai layanan Google Cloud. Anda dapat menggunakan Google Cloud CLI untuk men-deploy konfigurasi Endpoint ke Pengelolaan Layanan.
Konsol Google Cloud
Konsol Google Cloud adalah antarmuka pengguna grafis (GUI) untuk Google Cloud. Endpoint menggunakan Konsol Google Cloud untuk mengekspos data pemantauan dan logging yang dikirim dari ESP atau ESPv2 dan direkam oleh Service Control serta membagikan API kepada developer lain, dan agar mereka dapat membuat kunci API untuk memanggil API.
Skenario deployment
Opsi untuk deployment bervariasi, bergantung pada penggunaan ESP atau ESPv2 sebagai proxy Endpoints. ESPv2 dapat di-deploy sebagai proxy jarak jauh, serta ESPv2 dan ESP dapat di-deploy dalam mode bantuan, seperti yang dijelaskan di bagian berikut.
Mode proxy jarak jauh
Jika menggunakan ESPv2, Endpoint dapat di-deploy sebagai proxy jarak jauh. Mode ini digunakan untuk mendukung aplikasi yang berjalan pada platform serverless seperti Cloud Run, Cloud Functions, dan App Engine untuk lingkungan standar.
Dalam mode ini, ESPv2 di-deploy sebagai aplikasi Cloud Run. Aplikasi dikonfigurasi untuk menggunakan ESPv2 sebagai backend jarak jauh menggunakan kolom x-google-backend di konfigurasi layanan OpenAPI. Saat berfungsi sebagai proxy jarak jauh dalam mode deployment ini, satu ESPv2 dapat mendukung beberapa backend jarak jauh.
Mode bantuan
ESP dan ESPv2 mendukung deployment dalam container bersama setiap instance backend Anda. Topologi lokal server ini cocok untuk API yang berinteraksi dengan web serta microservice. Hal ini menghindari hop jaringan yang biasanya terkait dengan proxy terpusat dan memungkinkan pengelolaan API yang berperforma tinggi serta skalabel.
Biasanya, load balancing diterapkan sebelum traffic mencapai ESP atau ESPv2. Di Compute Engine, hal ini dilakukan oleh Cloud Load Balancing. Untuk deployment Kubernetes, Anda dapat menggunakan proxy ingress untuk load balancing. Di Google Kubernetes Engine, Anda dapat menggunakan Cloud Load Balancing atau proxy ingress untuk load balancing.
Saat startup, ESP atau ESPv2 mendapatkan konfigurasi layanannya dari Pengelolaan Layanan. Konfigurasi layanan dibuat dari spesifikasi OpenAPI atau dari gRPC, file YAML konfigurasi layanan. Kode ini akan memberi tahu ESP atau ESPv2 platform API agar dikelola bersama dengan kebijakannya, seperti metode mana yang memerlukan autentikasi, dan mana yang memerlukan kunci API.
Meminta perutean
Saat permintaan diterima, ESP atau ESPv2 membuat token rekaman aktivitas untuk Cloud Trace.
Selanjutnya, ESP atau ESPv2 mencocokkan jalur permintaan masuk dengan platform API. Setelah menemukan rute yang cocok, ESP atau ESPv2 akan melakukan langkah autentikasi apa pun untuk metode yang ditentukan.
Jika validasi JWT diperlukan, ESP atau ESPv2 akan memvalidasi autentikasi menggunakan kunci publik yang sesuai untuk penanda tangan, dan memvalidasi kolom audiens di JWT. Jika kunci API diperlukan, ESP atau ESPv2 akan memanggil Service Control API untuk memvalidasi kunci tersebut.
Service Control mencari kunci untuk memvalidasinya, dan memastikan bahwa project yang terkait dengan kunci tersebut telah mengaktifkan API. Jika kunci tidak valid atau project belum mengaktifkan API, panggilan akan ditolak dan dicatat melalui Service Control API.
Jika Service Control berhasil memvalidasi kunci, permintaan beserta semua header asli, serta header validasi JWT, jika sesuai, akan diteruskan ke backend.
Saat respons diterima dari backend, ESP atau ESPv2 menampilkan respons ke pemanggil dan mengirimkan informasi pengaturan waktu akhir ke Trace. Titik panggilan dicatat ke dalam log oleh Service Control API, yang menulis metrik dan log ke tujuan yang sesuai.
ESP atau ESPv2 di Kubernetes
Diagram berikut menunjukkan keseluruhan arsitektur tempat ESP
dijalankan sebagai container side-car di depan container aplikasi layanan
API, dengan my-api API yang dihosting di my-api.com dan didukung oleh
layanan Kubernetes. Arsitekturnya akan sama untuk deployment file bantuan dengan ESPv2.
