Ringkasan Cloud Service Mesh dengan layanan gRPC tanpa proxy

Panduan ini memberikan ringkasan arsitektur Cloud Service Mesh dengan layanan gRPC tanpa proxy, termasuk kasus penggunaan dan pola arsitektur.

Bidang kontrol terkelola Cloud Service Mesh memungkinkan pemilihan rute global, load balancing, dan failover regional untuk kasus penggunaan mesh layanan dan load balancing. Hal ini mencakup deployment yang menggabungkan proxy sidecar dan proxy gateway. Dukungan Cloud Service Mesh untuk aplikasi gRPC tanpa proxy menawarkan model deployment tambahan yang memungkinkan aplikasi gRPC berpartisipasi dalam service mesh tanpa memerlukan proxy sidecar.

Dalam contoh umum, klien gRPC membuat koneksi dengan server gRPC yang menghosting logika backend Anda. Cloud Service Mesh memberikan informasi kepada klien gRPC Anda tentang server mana yang harus dihubungi, cara menyeimbangkan beban permintaan ke beberapa instance server, dan tindakan yang harus dilakukan terhadap permintaan jika server tidak berjalan.

Untuk ringkasan lengkap tentang cara kerja Cloud Service Mesh, lihat Ringkasan Cloud Service Mesh.

Cara kerja Cloud Service Mesh dengan aplikasi gRPC

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

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

Service mesh diaktifkan dengan menggunakan proxy sidecar.
Mesh layanan yang diaktifkan menggunakan proxy sidecar (klik untuk memperbesar)

Untuk mengonfigurasi proxy sidecar, Cloud Service Mesh menggunakan xDS API. Klien berkomunikasi dengan server melalui proxy sidecar.

Dalam ilustrasi kedua, mesh layanan diaktifkan tanpa proxy sidecar dengan menggunakan klien gRPC tanpa proxy.

Service mesh diaktifkan menggunakan gRPC tanpa proxy.
Service mesh yang diaktifkan menggunakan gRPC tanpa proxy (klik untuk memperbesar)

Jika hanya men-deploy layanan gRPC yang dikonfigurasi Cloud Service Mesh, Anda dapat membuat mesh layanan tanpa men-deploy proxy sama sekali. Hal ini memudahkan penerapan kemampuan service mesh ke aplikasi gRPC Anda.

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, di target URI xds:///example.hostname.
  2. Klien gRPC menyelesaikan hostname:port di URI target dengan mengirimkan permintaan listener discovery service (LDS) ke Cloud Service Mesh.
  3. Cloud Service Mesh mencari aturan penerusan yang dikonfigurasi yang memiliki port yang cocok. Kemudian, ia akan mencari peta URL yang sesuai untuk aturan host yang cocok dengan hostname:port. API ini menampilkan konfigurasi perutean terkait ke klien gRPC.

Aturan host yang Anda konfigurasi di Cloud Service Mesh 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 penyelesaian 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 Cloud Service Mesh. Klien gRPC kemudian berkomunikasi langsung dengan server gRPC.

Anda dapat menggabungkan pola deployment tanpa proxy dan proxy sidecar 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 sidecar menggunakan skema resolusi nama dns.

Service mesh yang terdiri dari klien gRPC tanpa proxy dan klien gRPC dengan proxy sidecar.
Service mesh yang terdiri dari klien gRPC tanpa proxy dan klien gRPC dengan proxy sidecar (klik untuk memperbesar)

Kasus penggunaan

Kasus penggunaan berikut membantu Anda memahami kapan Anda mungkin ingin menggunakan Cloud Service Mesh dengan aplikasi gRPC tanpa proxy. Deployment Anda dapat mencakup aplikasi gRPC tanpa proxy, aplikasi gRPC dengan proxy sidecar, atau campuran keduanya.

Efisiensi resource dalam mesh layanan skala besar

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

Aplikasi gRPC berperforma tinggi

Untuk beberapa kasus penggunaan, setiap milidetik latensi permintaan dan respons sangat penting. Dalam kasus seperti itu, Anda mungkin akan menemukan latensi yang lebih rendah saat menggunakan aplikasi gRPC tanpa proxy, alih-alih meneruskan setiap permintaan melalui proxy sidecar sisi klien dan, mungkin, proxy sidecar sisi server.

Service mesh untuk lingkungan tempat Anda tidak dapat men-deploy proxy sidecar

Di beberapa lingkungan, Anda mungkin tidak dapat menjalankan proxy sidecar sebagai proses tambahan bersama aplikasi klien atau server Anda. Atau, Anda mungkin tidak dapat mengonfigurasi stack jaringan mesin untuk pencegatan dan pengalihan permintaan—misalnya, dengan menggunakan iptables. Dalam hal ini, Anda dapat menggunakan Cloud Service Mesh 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 Cloud Service Mesh, service mesh Anda dapat mencakup kedua model deployment. Dengan menyertakan kedua model, Anda dapat memenuhi kebutuhan operasional, performa, dan fitur tertentu dari berbagai aplikasi dan tim pengembangan yang berbeda.

Bermigrasi dari mesh layanan dengan proxy ke mesh tanpa proxy

Jika sudah memiliki aplikasi gRPC dengan proxy sidecar yang dikonfigurasi Cloud Service Mesh, Anda dapat beralih ke aplikasi gRPC tanpa proxy.

Saat di-deploy dengan proxy sidecar, klien gRPC menggunakan DNS untuk menyelesaikan nama host yang terhubung dengannya. Proxy sidecar mencegat traffic untuk menyediakan kemampuan mesh layanan.

Anda dapat menentukan apakah klien gRPC menggunakan rute tanpa proxy atau rute proxy sidecar untuk berkomunikasi dengan server gRPC dengan mengubah skema penyelesaian nama yang digunakannya. Klien tanpa proxy menggunakan skema resolusi nama xds, sedangkan proxy sidecar menggunakan skema resolusi nama dns. Beberapa klien gRPC bahkan dapat 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 bermigrasi secara bertahap ke deployment tanpa proxy.

Untuk bermigrasi dari service mesh dengan proxy ke mesh tanpa proxy, Anda membuat layanan Cloud Service Mesh baru yang digunakan oleh klien gRPC tanpa proxy. Anda dapat menggunakan API yang sama untuk mengonfigurasi Cloud Service Mesh untuk versi yang ada dan baru.

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

Arsitektur dan resource

Model data konfigurasi untuk layanan gRPC tanpa proxy memperluas model konfigurasi Cloud Service Mesh, 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 batasan lainnya 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 Cloud Service Mesh.

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

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

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. Jangan gunakan health check HTTP, HTTPS, atau HTTP/2.

Untuk mengetahui 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.

  • Di semua deployment Cloud Service Mesh, skema load balancing untuk layanan backend harus berupa INTERNAL_SELF_MANAGED.

Backend

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

Langkah berikutnya