Ringkasan Cloud Service Mesh dengan layanan gRPC tanpa proxy

Panduan ini memberikan ringkasan tentang 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 tempat aplikasi gRPC dapat 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 memberi klien gRPC Anda informasi tentang server yang akan dihubungi, cara melakukan load balancing permintaan ke beberapa instance server, dan tindakan yang harus dilakukan dengan 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, serupa dengan cara konfigurasi proxy sidecar seperti Envoy. Namun, aplikasi gRPC tanpa proxy yang terhubung langsung ke Cloud Service Mesh tidak memerlukan proxy sidecar. Sebagai gantinya, Cloud Service Mesh menggunakan API xDS 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 menggunakan proxy sidecar.

Mesh layanan yang diaktifkan 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 menggunakan klien gRPC tanpa proxy.

Mesh layanan yang 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 apa pun. Hal ini memudahkan Anda menghadirkan kemampuan mesh layanan ke aplikasi gRPC.

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

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

Anda dapat menggabungkan proxy sidecar dan pola deployment 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 sidecar berkomunikasi dengan server gRPC. Klien gRPC dengan proxy sidecar menggunakan skema resolusi nama dns.

Mesh layanan yang terdiri dari klien gRPC tanpa proxy dan klien gRPC dengan proxy sidecar.
Mesh layanan 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 kombinasi keduanya.

Efisiensi resource dalam mesh layanan skala besar

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

Aplikasi gRPC berperforma tinggi

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

Mesh layanan 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. Atau, Anda mungkin tidak dapat mengonfigurasi stack jaringan mesin untuk intersepsi 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, mesh layanan Anda dapat menyertakan kedua model deployment. Menyertakan kedua model memungkinkan Anda 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 oleh Cloud Service Mesh, Anda dapat bertransisi ke aplikasi gRPC tanpa proxy.

Saat di-deploy dengan proxy sidecar, klien gRPC menggunakan DNS untuk me-resolve nama host yang terhubung. 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 resolusi nama yang digunakannya. Klien tanpa proxy menggunakan skema resolusi nama xds, sedangkan proxy sidecar menggunakan skema resolusi nama dns. Beberapa klien gRPC mungkin bahkan menggunakan rute tanpa proxy saat berkomunikasi dengan satu server gRPC, tetapi menggunakan rute proxy sidecar saat berkomunikasi dengan server gRPC lain. Dengan demikian, Anda dapat bermigrasi secara bertahap ke deployment tanpa proxy.

Untuk bermigrasi dari mesh layanan dengan proxy ke mesh tanpa proxy, Anda harus 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 sudah ada dan versi 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 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 yang lainnya merupakan hal yang melekat dalam 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 Anda.

Langkah selanjutnya