Membandingkan layanan gRPC dengan HTTP API

Artikel
11/30/2023

Artikel ini menjelaskan bagaimana layanan gRPC dibandingkan dengan API HTTP dengan JSON (termasuk API web ASP.NET Core). Teknologi yang digunakan untuk menyediakan API untuk aplikasi Anda adalah pilihan penting, dan gRPC menawarkan manfaat unik dibandingkan dengan API HTTP. Artikel ini membahas kekuatan dan kelemahan gRPC dan merekomendasikan skenario untuk menggunakan gRPC dibandingkan teknologi lain.

Perbandingan tingkat tinggi

Tabel berikut menawarkan perbandingan fitur tingkat tinggi antara gRPC dan API HTTP dengan JSAKTIF.

Fitur	gRPC	API HTTP dengan JSAKTIF
Kontrak	Diperlukan (`.proto`)	Opsional (OpenAPI)
Protokol	HTTP/2	HTTP
Payload	Protobuf (kecil, biner)	JSAKTIF (besar, dapat dibaca manusia)
Preskriptif	Spesifikasi ketat	Longgar. HTTP apa pun valid.
Streaming	Klien, server, dua arah	Klien, server
Dukungan browser	Tidak (memerlukan grpc-web)	Ya
Keamanan	Transportasi (TLS)	Transportasi (TLS)
Pembuatan kode klien	Ya	OpenAPI + alat pihak ketiga

Kekuatan gRPC

Performa

Pesan gRPC diserialisasikan menggunakan Protobuf, format pesan biner yang efisien. Protobuf menserialisasikan dengan sangat cepat di server dan klien. Serialisasi Protobuf menghasilkan payload pesan kecil, penting dalam skenario bandwidth terbatas seperti aplikasi seluler.

gRPC dirancang untuk HTTP/2, revisi utama HTTP yang memberikan manfaat performa signifikan melalui HTTP 1.x:

Pembingkaian dan pemadatan biner. Protokol HTTP/2 ringkas dan efisien baik dalam pengiriman maupun penerimaan.
Multipleks beberapa panggilan HTTP/2 melalui satu koneksi TCP. Multiplexing menghilangkan pemblokiran head-of-line.

HTTP/2 tidak eksklusif untuk gRPC. Banyak jenis permintaan, termasuk API HTTP dengan JSAKTIF, dapat menggunakan HTTP/2 dan mendapat manfaat dari peningkatan performanya.

Pembuatan Kode

Semua kerangka kerja gRPC menyediakan dukungan kelas satu untuk pembuatan kode. File inti untuk pengembangan gRPC adalah .proto file, yang menentukan kontrak layanan dan pesan gRPC. Dari file ini, kerangka kerja gRPC menghasilkan kelas dasar layanan, pesan, dan klien lengkap.

Dengan berbagi .proto file antara server dan klien, pesan dan kode klien dapat dihasilkan dari ujung ke ujung. Pembuatan kode klien menghilangkan duplikasi pesan di klien dan server, dan membuat klien yang sangat diketik untuk Anda. Tidak harus menulis klien menghemat waktu pengembangan yang signifikan dalam aplikasi dengan banyak layanan.

Spesifikasi ketat

Spesifikasi formal untuk HTTP API dengan JSON tidak ada. Pengembang memperdebatkan format URL terbaik, kata kerja HTTP, dan kode respons.

Spesifikasi gRPC adalah preskriptif tentang format yang harus diikuti layanan gRPC. gRPC menghilangkan perdebatan dan menghemat waktu pengembang karena gRPC konsisten di seluruh platform dan implementasi.

Streaming

HTTP/2 menyediakan fondasi untuk aliran komunikasi real-time yang berumur panjang. gRPC menyediakan dukungan kelas satu untuk streaming melalui HTTP/2.

Layanan gRPC mendukung semua kombinasi streaming:

Unary (tanpa streaming)
Streaming server ke klien
Streaming klien ke server
Streaming dua arah

Tenggat waktu/batas waktu dan pembatalan

gRPC memungkinkan klien untuk menentukan berapa lama mereka bersedia menunggu RPC selesai. Tenggat waktu dikirim ke server, dan server dapat memutuskan tindakan apa yang harus diambil jika melebihi tenggat waktu. Misalnya, server mungkin membatalkan permintaan gRPC/HTTP/database yang sedang berlangsung pada waktu habis.

Menyebarkan tenggat waktu dan pembatalan melalui panggilan gRPC anak membantu memberlakukan batas penggunaan sumber daya.

Skenario yang direkomendasikan gRPC

gRPC sangat cocok untuk skenario berikut:

Layanan mikro: gRPC dirancang untuk latensi rendah dan komunikasi throughput tinggi. gRPC sangat bagus untuk layanan mikro ringan di mana efisiensi sangat penting.
Komunikasi real time titik-ke-titik: gRPC memiliki dukungan yang sangat baik untuk streaming dua arah. Layanan gRPC dapat mendorong pesan secara real time tanpa polling.
Lingkungan poliglot: peralatan gRPC mendukung semua bahasa pengembangan populer, menjadikan gRPC pilihan yang baik untuk lingkungan multi-bahasa.
Lingkungan yang dibatasi jaringan: pesan gRPC diserialisasikan dengan Protobuf, format pesan ringan. Pesan gRPC selalu lebih kecil dari pesan ON yang setara JS.
Komunikasi antarproses (IPC): Transportasi IPC seperti soket domain Unix dan pipa bernama dapat digunakan dengan gRPC untuk berkomunikasi antara aplikasi pada komputer yang sama. Untuk informasi selengkapnya, lihat Komunikasi antarproses dengan gRPC.

kelemahan gRPC

Dukungan browser terbatas

Tidak mungkin untuk langsung memanggil layanan gRPC dari browser hari ini. gRPC sangat menggunakan fitur HTTP/2 dan tidak ada browser yang menyediakan tingkat kontrol yang diperlukan atas permintaan web untuk mendukung klien gRPC. Misalnya, browser tidak mengizinkan pemanggil untuk mengharuskan HTTP/2 digunakan, atau menyediakan akses ke bingkai HTTP/2 yang mendasar.

gRPC di ASP.NET Core menawarkan dua solusi yang kompatibel dengan browser:

gRPC-Web memungkinkan aplikasi browser untuk memanggil layanan gRPC dengan klien gRPC-Web dan Protobuf. gRPC-Web mengharuskan aplikasi browser untuk menghasilkan klien gRPC. gRPC-Web memungkinkan aplikasi browser untuk mendapatkan manfaat dari penggunaan jaringan gRPC berkinerja tinggi dan rendah.

.NET memiliki dukungan bawaan untuk gRPC-Web. Untuk informasi selengkapnya, lihat gRPC-Web di aplikasi gRPC ASP.NET Core.
Transcoding gRPC JSON memungkinkan aplikasi browser untuk memanggil layanan gRPC seolah-olah api tersebut RESTpenuh dengan JSAKTIF. Aplikasi browser tidak perlu menghasilkan klien gRPC atau tahu apa pun tentang gRPC. RESTAPI ful dapat dibuat secara otomatis dari layanan gRPC dengan menganotasi .proto file dengan metadata HTTP. Transcoding memungkinkan aplikasi untuk mendukung API web gRPC dan JSON tanpa menduplikasi upaya membangun layanan terpisah untuk keduanya.

.NET memiliki dukungan bawaan untuk membuat JSAPI web ON dari layanan gRPC. Untuk informasi selengkapnya, lihat transcoding gRPC JSON di aplikasi gRPC ASP.NET Core.

Catatan

transcoding gRPC JSON memerlukan .NET 7 atau yang lebih baru.

Tidak dapat dibaca manusia

Permintaan API HTTP dikirim sebagai teks dan dapat dibaca dan dibuat oleh manusia.

Pesan gRPC dikodekan dengan Protobuf secara default. Meskipun Protobuf efisien untuk dikirim dan diterima, format binernya tidak dapat dibaca manusia. Protobuf memerlukan deskripsi antarmuka pesan yang ditentukan dalam .proto file untuk deserialisasi dengan benar. Alat tambahan diperlukan untuk menganalisis payload Protobuf pada kawat dan untuk menyusun permintaan dengan tangan.

Fitur seperti refleksi server dan alat baris perintah gRPC ada untuk membantu dengan pesan Protobuf biner. Selain itu, pesan Protobuf mendukung konversi ke dan dari JSAKTIF. Konversi ON bawaan JSmenyediakan cara yang efisien untuk mengonversi pesan Protobuf ke dan dari bentuk yang dapat dibaca manusia saat penelusuran kesalahan.

Skenario kerangka kerja alternatif

Kerangka kerja lain direkomendasikan daripada gRPC dalam skenario berikut:

API yang dapat diakses browser: gRPC tidak sepenuhnya didukung di browser. gRPC-Web dapat menawarkan dukungan browser, tetapi memiliki batasan dan memperkenalkan proksi server.
Menyiarkan komunikasi real time: gRPC mendukung komunikasi real-time melalui streaming, tetapi konsep menyiarkan pesan ke koneksi terdaftar tidak ada. Misalnya dalam skenario ruang obrolan di mana pesan obrolan baru harus dikirim ke semua klien di ruang obrolan, setiap panggilan gRPC diperlukan untuk melakukan streaming pesan obrolan baru secara individual ke klien. SignalR adalah kerangka kerja yang berguna untuk skenario ini. SignalR memiliki konsep koneksi persisten dan dukungan bawaan untuk menyiarkan pesan.