Endpoints adalah sistem pengelolaan API terdistribusi yang terdiri dari layanan, runtime, dan alat. Endpoints menyediakan pengelolaan, pemantauan, dan autentikasi.
Komponen yang membentuk Endpoint adalah:
Extensible Service Proxy (ESP) atau Extensible Service Proxy V2 (ESPv2) - untuk menyuntikkan fungsi Endpoints.
Service Control - untuk menerapkan aturan pengelolaan API.
Service Management - untuk mengonfigurasi aturan pengelolaan API.
Google Cloud CLI - untuk deployment dan pengelolaan.
Google Cloud console - untuk logging, pemantauan, dan berbagi.
Arsitektur endpoint
Komponen endpoint
ESP
ESP adalah proxy berbasis NGINX yang berjalan di depan backend dan menyuntikkan fungsi Endpoints seperti autentikasi, pemantauan, dan logging. ESP mengambil konfigurasi layanan dari Pengelolaan Layanan dan menggunakannya untuk memvalidasi permintaan masuk.
ESP dirancang agar Anda dapat men-deploy-nya di lingkungan yang dikontainerkan dan memvalidasi JWT dan token ID Google. Library ini menggunakan berbagai teknik, seperti caching berat dan panggilan asinkron agar tetap ringan dan berperforma tinggi.
Dukungan ESP tersedia untuk platform berikut:
ESPv2
ESPv2 adalah proxy berperforma tinggi dan skalabel berbasis Envoy yang berjalan di depan backend API OpenAPI atau gRPC. Endpoints di ESPv2 mendukung versi 2 dari Spesifikasi OpenAPI dan spesifikasi gRPC.
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
Service Control menerapkan aturan pengelolaan API saat runtime, seperti autentikasi kunci, pemantauan, dan logging. Service Control 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 menjelaskan perilaku layanan gRPC dalam file YAML yang disebut sebagai konfigurasi Endpoints. Anda men-deploy konfigurasi Endpoints dan file.proto yang dikompilasi ke
Service Management menggunakan gcloud CLI, yang
mengonfigurasi aturan pengelolaan API.
Tugas terkait konfigurasi lainnya juga dilakukan di sini, seperti membagikan API Anda kepada 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 menggunakan Google Cloud CLI untuk men-deploy konfigurasi Endpoints ke Service Management.
KonsolGoogle Cloud
Google Cloud console adalah antarmuka pengguna grafis (GUI) untuk Google Cloud. Endpoints menggunakan konsol Google Cloud untuk mengekspos data pemantauan dan logging yang dikirim dari ESP atau ESPv2 dan dicatat oleh Service Control serta membagikan API kepada developer lain, dan bagi mereka untuk membuat kunci API guna 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 dan ESPv2 serta ESP dapat di-deploy dalam mode sidecar, seperti yang dijelaskan di bagian berikut.
Mode proxy jarak jauh
Jika menggunakan ESPv2, Endpoints dapat di-deploy sebagai proxy jarak jauh. Mode ini digunakan untuk mendukung aplikasi yang berjalan di platform serverless seperti Cloud Run, Cloud Run 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 dalam konfigurasi layanan OpenAPI. Saat berfungsi sebagai proxy jarak jauh dalam mode deployment ini, satu ESPv2 dapat mendukung beberapa backend jarak jauh.
Mode file bantuan
ESP dan ESPv2 mendukung deployment dalam container bersama setiap instance backend Anda. Topologi lokal server ini ideal untuk API yang menghadap web dan microservice. Hal ini menghindari lompatan jaringan yang biasanya terkait dengan proxy terpusat dan memungkinkan pengelolaan API yang berperforma tinggi serta dapat diskalakan.
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 Service Management. Konfigurasi layanan dibuat dari spesifikasi OpenAPI atau dari gRPC, file YAML konfigurasi layanan. ESP atau ESPv2 akan mengetahui permukaan API yang akan dikelola beserta kebijakan, seperti metode mana yang memerlukan autentikasi, dan metode mana yang memerlukan kunci API.
Perutean permintaan
Saat permintaan diterima, ESP atau ESPv2 akan membuat token rekaman aktivitas untuk Cloud Trace.
Selanjutnya, ESP atau ESPv2 mencocokkan jalur permintaan masuk dengan permukaan API. Setelah menemukan rute yang cocok, ESP atau ESPv2 akan melakukan langkah-langkah autentikasi 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.
Service Control mencari kunci untuk memvalidasinya, dan memastikan bahwa project yang terkait dengan kunci 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, ditambah header validasi JWT, jika sesuai, akan diteruskan ke backend.
Saat respons diterima dari backend, ESP atau ESPv2 akan menampilkan respons ke pemanggil dan mengirimkan informasi waktu akhir ke Trace. Titik panggilan dicatat oleh Service Control API, yang menulis metrik dan log ke tujuan yang sesuai.
ESP atau ESPv2 di Kubernetes
Diagram berikut menunjukkan arsitektur keseluruhan tempat ESP berjalan sebagai container side-car di depan container aplikasi layanan API, dengan my-api API dihosting di my-api.com dan didukung oleh layanan Kubernetes. Arsitekturnya akan sama untuk deployment sidecar dengan ESPv2.
