Ringkasan Traffic Director dengan layanan gRPC tanpa proxy

Panduan ini menyediakan ringkasan tentang arsitektur Traffic Director dengan layanan gRPC tanpa proxy, termasuk kasus penggunaan dan pola arsitektur. Panduan ini mencakup Traffic Director API lama. Untuk informasi tentang API pemilihan rute layanan, lihat ringkasan.

Bidang kontrol terkelola Traffic Director memungkinkan pemilihan rute global, load balancing, dan failover regional untuk kasus penggunaan mesh layanan dan load balancing. Ini termasuk deployment yang menggabungkan proxy file bantuan dan proxy gateway. Dukungan Traffic Director untuk aplikasi gRPC tanpa proxy menawarkan model deployment tambahan yang memungkinkan aplikasi gRPC dapat berpartisipasi dalam mesh layanan tanpa memerlukan proxy file bantuan.

Sebagai contoh umum, klien gRPC membuat koneksi dengan server gRPC yang menghosting logika backend Anda. Traffic Director memberikan informasi kepada klien gRPC Anda tentang server yang harus dihubungi, cara memuat permintaan keseimbangan ke beberapa instance server, dan tindakan yang harus dilakukan dengan permintaan jika server tidak berjalan.

Untuk ringkasan lengkap tentang cara kerja Traffic Director, lihat ringkasan Traffic Director.

Cara kerja Traffic Director dengan aplikasi gRPC

Traffic Director mengonfigurasi klien gRPC dengan versi gRPC yang didukung, sama dengan cara proxy file bantuan seperti Envoy dikonfigurasi. Namun, aplikasi gRPC tanpa proxy yang terhubung langsung ke Traffic Director tidak memerlukan proxy file bantuan. Sebagai gantinya, Traffic Director menggunakan API xDS open source untuk mengonfigurasi aplikasi gRPC secara langsung. Aplikasi gRPC ini berfungsi sebagai klien xDS, yang terhubung ke bidang kontrol global Traffic Director. Setelah terhubung, aplikasi gRPC akan menerima konfigurasi dinamis dari bidang kontrol, yang memungkinkan penemuan endpoint, load balancing, failover regional, dan health check. Pendekatan ini memungkinkan pola deployment Traffic Director tambahan.

Dalam ilustrasi pertama, mesh layanan diaktifkan dengan menggunakan proxy sidecar.

Mesh layanan yang diaktifkan menggunakan proxy file bantuan.
Mesh layanan yang diaktifkan menggunakan proxy file bantuan (klik untuk memperbesar)

Untuk mengonfigurasi proxy file bantuan, Traffic Director menggunakan API xDS. Klien berkomunikasi dengan server melalui proxy file bantuan.

Dalam ilustrasi kedua, mesh layanan diaktifkan tanpa proxy file bantuan menggunakan klien gRPC tanpa proxy.

Mesh layanan yang diaktifkan menggunakan gRPC tanpa proxy.
Mesh layanan yang diaktifkan menggunakan gRPC tanpa proxy (klik untuk memperbesar)

Jika hanya men-deploy layanan gRPC yang dikonfigurasi Traffic Director, Anda dapat membuat mesh layanan tanpa men-deploy proxy sama sekali. Hal ini memudahkan penyediaan kemampuan mesh layanan ke aplikasi gRPC Anda.

Skema resolusi nama

Resolusi nama berfungsi untuk deployment tanpa proxy dengan cara berikut:

  1. Anda menetapkan xds sebagai skema resolusi nama di saluran klien gRPC saat terhubung ke layanan. URI target diformat sebagai xds:///hostname:port. Jika port tidak ditentukan, nilai defaultnya adalah 80—misalnya, dalam URI target xds:///example.hostname.
  2. Klien gRPC akan me-resolve hostname:port di URI target dengan mengirimkan permintaan layanan penemuan pemroses (LDS) ke Traffic Director.
  3. Traffic Director mencari aturan penerusan yang telah dikonfigurasi dan memiliki port yang cocok. Kemudian, sistem akan mencari peta URL yang sesuai untuk aturan host yang cocok dengan hostname:port. Metode ini menampilkan konfigurasi perutean terkait ke klien gRPC.

Aturan host yang Anda konfigurasi di Traffic Director harus unik di semua peta URL. Misalnya, example.hostname, example.hostname:80, dan example.hostname:8080 adalah aturan yang berbeda.

Resolusi nama dengan berbagai jenis deployment

Skema resolusi nama berbeda untuk deployment tanpa proxy dan deployment yang menggunakan proxy Envoy.

Klien gRPC menggunakan skema resolusi nama xds untuk terhubung ke layanan, sehingga klien dapat menerima konfigurasi layanan dari Traffic Director. Klien gRPC kemudian berkomunikasi langsung dengan server gRPC.

Anda dapat menggabungkan pola deployment proxy sidecar dan tanpa proxy untuk meningkatkan fleksibilitas. Menggabungkan pola sangat membantu saat organisasi dan jaringan Anda mendukung beberapa tim dengan persyaratan fitur, kebutuhan operasional, dan versi gRPC yang berbeda.

Dalam ilustrasi berikut, klien gRPC tanpa proxy dan klien gRPC dengan proxy file bantuan berkomunikasi dengan server gRPC. Klien gRPC dengan proxy file bantuan menggunakan skema resolusi nama dns.

Mesh layanan yang terdiri dari klien gRPC tanpa proxy dan klien gRPC dengan proxy file bantuan.
Mesh layanan yang terdiri dari klien gRPC tanpa proxy dan klien gRPC dengan proxy file bantuan (klik untuk memperbesar)

Kasus penggunaan

Kasus penggunaan berikut membantu Anda memahami kapan sebaiknya menggunakan Traffic Director dengan aplikasi gRPC tanpa proxy. Deployment Anda dapat mencakup aplikasi gRPC tanpa proxy, aplikasi gRPC dengan proxy sidecar, atau perpaduan keduanya.

Efisiensi resource dalam mesh layanan berskala besar

Jika mesh layanan Anda mencakup ratusan atau ribuan klien dan backend, Anda mungkin mendapati bahwa total pemakaian resource dari menjalankan proxy file bantuan mulai bertambah. Saat menggunakan aplikasi gRPC tanpa proxy, Anda tidak perlu memperkenalkan proxy file bantuan ke deployment. Pendekatan tanpa proxy dapat menghasilkan efisiensi.

Aplikasi gRPC berperforma tinggi

Untuk beberapa kasus penggunaan, setiap milidetik permintaan dan latensi respons itu penting. Dalam kasus semacam ini, Anda mungkin menemukan latensi yang berkurang saat menggunakan aplikasi gRPC tanpa proxy, bukan meneruskan setiap permintaan melalui proxy sidecar sisi klien dan, mungkin, proxy sidecar sisi server.

Mesh layanan untuk lingkungan tempat Anda tidak dapat men-deploy proxy file bantuan

Di beberapa lingkungan, Anda mungkin tidak dapat menjalankan proxy file bantuan sebagai proses tambahan bersama aplikasi klien atau server. Atau, Anda mungkin tidak dapat mengonfigurasi stack jaringan mesin untuk intersepsi dan pengalihan permintaan—misalnya, dengan menggunakan iptables. Dalam hal ini, Anda dapat menggunakan Traffic Director dengan aplikasi gRPC tanpa proxy untuk memperkenalkan kemampuan mesh layanan ke aplikasi gRPC Anda.

Mesh layanan heterogen

Karena aplikasi gRPC tanpa proxy dan Envoy berkomunikasi dengan Traffic Director, mesh layanan Anda dapat menyertakan kedua model deployment. Dengan menyertakan kedua model tersebut, Anda dapat memenuhi kebutuhan operasional, performa, dan fitur tertentu dari berbagai aplikasi serta tim pengembangan yang berbeda.

Bermigrasi dari mesh layanan dengan proxy ke mesh tanpa proxy

Jika sudah memiliki aplikasi gRPC dengan proxy file bantuan yang dikonfigurasi Traffic Director, Anda dapat beralih ke aplikasi gRPC tanpa proxy.

Saat klien gRPC di-deploy dengan proxy file bantuan, klien gRPC akan menggunakan DNS untuk menyelesaikan nama host yang terhubung dengannya. Proxy file bantuan mencegat traffic untuk memberikan fungsi mesh layanan.

Anda dapat menentukan apakah klien gRPC menggunakan rute tanpa proxy atau rute proxy sidecar untuk berkomunikasi dengan server gRPC dengan mengubah skema resolusi nama yang digunakannya. Klien tanpa proxy menggunakan skema resolusi nama xds, sedangkan proxy file bantuan menggunakan skema resolusi nama dns. Beberapa klien gRPC bahkan mungkin menggunakan rute tanpa proxy saat berkomunikasi dengan satu server gRPC, tetapi menggunakan rute proxy sidecar saat berkomunikasi dengan server gRPC lain. Hal ini memungkinkan Anda secara bertahap bermigrasi ke deployment tanpa proxy.

Untuk bermigrasi dari mesh layanan dengan proxy ke mesh tanpa proxy, Anda harus membuat layanan Traffic Director baru yang digunakan oleh klien gRPC tanpa proxy. Anda dapat menggunakan API yang sama guna mengonfigurasi Traffic Director untuk versi yang sudah ada dan baru.

Mesh layanan dengan klien gRPC yang berkomunikasi dengan berbagai layanan menggunakan mekanisme tanpa proxy dan berbasis proxy.
Mesh layanan dengan klien gRPC yang berkomunikasi dengan berbagai layanan menggunakan mekanisme tanpa proxy dan berbasis proxy (klik untuk memperbesar)

Arsitektur dan resource

Model data konfigurasi untuk layanan gRPC tanpa proxy memperluas model konfigurasi Traffic Director, dengan beberapa penambahan dan batasan yang dijelaskan dalam panduan ini. Beberapa batasan ini bersifat sementara karena gRPC tanpa proxy tidak mendukung semua fitur Envoy, dan yang lainnya bersifat melekat pada penggunaan RPC. Misalnya, pengalihan HTTP yang menggunakan gRPC tidak didukung. Untuk membantu Anda memahami model konfigurasi dalam panduan ini, sebaiknya Anda memahami konsep dan konfigurasi Traffic Director.

Diagram berikut menunjukkan resource yang harus Anda konfigurasi untuk aplikasi gRPC tanpa proxy.

Resource yang didukung dalam gRPC tanpa proxy untuk load balancing.
Resource yang didukung dalam gRPC tanpa proxy untuk load balancing (klik untuk memperbesar)

Peta aturan perutean

Peta aturan perutean menentukan cara permintaan dirutekan di mesh. Library ini terdiri dari aturan penerusan, proxy gRPC target, dan peta URL. Peta aturan perutean hanya berlaku untuk deployment yang menggunakan API load balancing. Setelan ini tidak berlaku dengan API perutean layanan atau Gateway API.

Aturan penerusan

Biasanya, Anda membuat aturan penerusan menggunakan alamat IP virtual dan port layanan yang dikonfigurasi. Klien gRPC yang menggunakan skema resolusi nama xds tidak melakukan pencarian DNS untuk me-resolve nama host di URI saluran. Sebagai gantinya, klien tersebut menyelesaikan hostname[:port] di URI target dengan mengirimkan permintaan LDS ke Traffic Director. Tidak diperlukan pencarian DNS, dan entri DNS untuk nama {i>host<i} tidak diperlukan.

Akibatnya, Traffic Director hanya menggunakan port yang ditentukan dalam URI untuk mencari aturan penerusan, dengan mengabaikan alamat IP. Nilai default port adalah 80. Traffic Director kemudian mencari aturan host yang cocok dalam peta URL yang terkait dengan proxy target yang dirujuk oleh aturan penerusan.

Oleh karena itu, aturan penerusan yang merujuk ke proxy gRPC target dengan kolom validateForProxyless yang ditetapkan ke TRUE harus memiliki alamat IP yang ditetapkan ke 0.0.0.0. Jika validateForProxyless ditetapkan ke TRUE, konfigurasi yang menentukan alamat IP selain 0.0.0.0 akan ditolak. Pemeriksaan ini tidak mendeteksi aturan penerusan duplikat dengan port yang sama di peta aturan pemilihan rute lainnya.

Perhatikan hal-hal berikut:

  • Skema load balancing untuk aturan penerusan harus INTERNAL_SELF_MANAGED.
  • Anda dapat memiliki beberapa aturan penerusan, tetapi IP:port dari setiap aturan penerusan harus unik, dan port-nya harus cocok dengan port yang ditentukan dalam aturan host.
  • Jika lebih dari satu aturan penerusan memiliki port yang cocok dengan port di URI target, Traffic Director akan mencari hostname[:port] yang cocok dalam aturan host peta URL yang dirujuk oleh semua aturan penerusan tersebut. Traffic Director akan mencari kecocokan persis antara hostname[:port] dalam aturan host dan hostname[:port] yang ditentukan dalam URI target. Aturan host dan aturan default yang berisi karakter pengganti akan dilewati.

Jika ditemukan lebih dari satu kecocokan, perilaku tidak ditentukan dan dapat menyebabkan perilaku yang tidak dapat diprediksi. Hal ini biasanya terjadi jika kedua kondisi berikut terpenuhi:

  • Nama host yang sama digunakan di beberapa peta URL.
  • Beberapa aturan penerusan dengan skema load balancing INTERNAL_SELF_MANAGED menentukan port yang sama.

Karena alasan ini, sebaiknya Anda tidak menggunakan kembali nama host yang sama di beberapa peta URL yang dirujuk oleh aturan penerusan yang menentukan port yang sama.

Proxy gRPC target

Proxy target mengarah ke peta URL, yang berisi aturan yang digunakan untuk mengarahkan traffic ke backend yang benar. Saat Anda mengonfigurasi Traffic Director untuk aplikasi gRPC, gunakan proxy gRPC target, bukan proxy HTTP target, terlepas dari apakah Anda menggunakan aplikasi gRPC tanpa proxy atau aplikasi gRPC yang menggunakan Envoy.

Proxy gRPC target memiliki kolom yang disebut validateForProxyless di REST API. Nilai defaultnya adalah FALSE. Menetapkan kolom ini ke TRUE akan mengaktifkan pemeriksaan konfigurasi, sehingga Anda tidak mengaktifkan fitur yang tidak kompatibel dengan gRPC tanpa proxy secara tidak sengaja.

Di Google Cloud CLI, flag --validate-for-proxyless setara dengan kolom validateForProxyless.

Karena dukungan Traffic Director untuk aplikasi gRPC tanpa proxy tidak mencakup kemampuan lengkap yang tersedia untuk aplikasi gRPC dengan proxy file bantuan, Anda dapat menggunakan kolom ini untuk memastikan bahwa konfigurasi yang tidak valid, yang mungkin ditentukan di peta URL atau layanan backend, ditolak. Validasi konfigurasi dilakukan berdasarkan fitur yang didukung Traffic Director dengan gRPC versi terbaru.

Peta URL

Peta URL menentukan aturan perutean yang digunakan klien gRPC tanpa proxy untuk mengirim traffic. Peta URL berisi satu atau beberapa aturan host dalam format hostname:port. Masing-masing aturan {i>host<i} ini di-resolve ke layanan.

Saat mengonfigurasi klien gRPC, Anda menentukan URI target untuk layanan yang perlu dihubungi klien. URI ini juga menggunakan format hostname:port. URI ini sesuai dengan entri aturan host di peta URL.

Misalnya, jika Anda mengonfigurasi URI target xds:///myservice:8080 di klien gRPC, Traffic Director akan mengiriminya konfigurasi yang sesuai dengan aturan host peta URL untuk myservice:8080. Konfigurasi ini mencakup, di antara informasi lainnya, daftar endpoint yang masing-masing merupakan pasangan alamat IP:port yang sesuai dengan instance server gRPC tertentu.

Jika Anda tidak menentukan port dalam URI target, 80 akan digunakan sebagai nilai default. Itu artinya:

  • URI target xds:///myservice cocok dengan aturan host peta URL myservice.
  • URI target xds:///myservice:80 cocok dengan aturan host peta URL myservice:80.
  • URI target xds:///myservice tidak cocok dengan aturan host peta URL myservice:80.
  • URI target xds:///myservice:80 tidak cocok dengan aturan host peta URL myservice.

String dalam URI target dan string dalam aturan host peta URL harus identik.

Untuk informasi selengkapnya, lihat Batasan peta URL.

Health check

Health check gRPC dapat memeriksa status layanan gRPC yang berjalan di instance mesin virtual (VM) backend atau grup endpoint jaringan (NEG).

Jika health check gRPC tidak dapat digunakan karena server gRPC Anda tidak menerapkan protokol health check gRPC, gunakan health check TCP sebagai gantinya. Jangan gunakan health check HTTP, HTTPS, atau HTTP/2.

Untuk informasi selengkapnya, lihat health check gRPC dan Flag tambahan untuk health check gRPC.

Layanan backend

Layanan backend menentukan cara klien gRPC berkomunikasi dengan server gRPC. Saat Anda membuat layanan backend untuk gRPC, tetapkan kolom protokol ke GRPC.

  • Layanan backend yang dikonfigurasi dengan protokol yang ditetapkan ke GRPC juga dapat diakses oleh aplikasi gRPC melalui proxy sidecar. Dalam situasi tersebut, klien gRPC tidak boleh menggunakan skema resolusi nama xds.

  • Dalam semua deployment Traffic Director, skema load balancing untuk layanan backend harus INTERNAL_SELF_MANAGED.

Backend

Backend menghosting instance server gRPC Anda. Anda dapat menggunakan grup instance terkelola atau tidak terkelola di Compute Engine dan NEGonal zona di Google Kubernetes Engine sebagai backend untuk menghosting instance server gRPC Anda.

Langkah selanjutnya