Endpoints 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 Endpoints.
Kontrol Layanan - untuk menerapkan aturan pengelolaan API.
Pengelolaan Layanan - untuk mengonfigurasi aturan pengelolaan API.
Google Cloud CLI - untuk deployment dan pengelolaan.
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 Endpoints seperti autentikasi, pemantauan, dan logging. ESP mengambil konfigurasi layanan dari Pengelolaan Layanan dan menggunakannya untuk memvalidasi permintaan yang masuk.
ESP dirancang agar Anda dapat men-deploy-nya di lingkungan berkontainer dan memvalidasi JWT serta token ID Google. Library ini menggunakan berbagai teknik, seperti cache berat dan panggilan asinkron agar tetap ringan dan berperforma tinggi.
Dukungan ESP tersedia untuk platform berikut:
ESPv2
ESPv2 adalah proxy skalabel berperforma tinggi berbasis Envoy yang berjalan di depan backend OpenAPI atau gRPC API. Endpoint 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. Kontrol Layanan menyediakan metode berikut:
Periksa - memverifikasi autentikasi dan kunci API, serta menunjukkan apakah panggilan harus diizinkan
Laporan - memberi tahu sistem data untuk logging dan pemantauan
Pengelolaan Layanan
Anda mendeskripsikan 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
ke 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 Endpoint ke Pengelolaan Layanan.
Konsol Google Cloud
Konsol Google Cloud 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, fungsi Cloud Run, 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 Sidecar
ESP dan ESPv2 mendukung deployment dalam penampung bersama setiap instance backend Anda. Topologi lokal server ini ideal untuk API yang menghadap 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 traffic masuk untuk load balancing. Di Google Kubernetes Engine, Anda dapat menggunakan Cloud Load Balancing atau proxy ingress untuk load balancing.
Saat memulai, ESP atau ESPv2 mendapatkan konfigurasi layanannya dari Pengelolaan Layanan. Konfigurasi layanan dibuat dari spesifikasi OpenAPI atau dari gRPC, file YAML konfigurasi layanan. Ini memberi tahu ESP atau ESPv2 antarmuka API yang akan dikelola beserta kebijakan, seperti metode mana yang memerlukan autentikasi, dan mana yang memerlukan kunci API.
Pemilihan rute permintaan
Saat permintaan diterima, ESP atau ESPv2 akan membuat token rekaman aktivitas untuk Cloud Trace.
Selanjutnya, ESP atau ESPv2 mencocokkan jalur permintaan yang masuk dengan platform 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 tersebut.
Service Control akan 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 ke dalam log 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 kepada 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 arsitektur keseluruhan tempat ESP
berjalan sebagai penampung side-car di depan penampung 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.
