Membandingkan layanan gRPC dengan HTTP API
Catatan
Ini bukan versi terbaru dari artikel ini. Untuk rilis saat ini, lihat versi .NET 8 dari artikel ini.
Peringatan
Versi ASP.NET Core ini tidak lagi didukung. Untuk informasi selengkapnya, lihat Kebijakan Dukungan .NET dan .NET Core. Untuk rilis saat ini, lihat versi .NET 8 dari artikel ini.
Penting
Informasi ini berkaitan dengan produk pra-rilis yang mungkin dimodifikasi secara substansial sebelum dirilis secara komersial. Microsoft tidak memberikan jaminan, tersirat maupun tersurat, sehubungan dengan informasi yang diberikan di sini.
Untuk rilis saat ini, lihat versi .NET 8 dari artikel ini.
Oleh James Newton-King
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 |
---|---|---|
Contract | 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.
Sumber Daya Tambahan:
ASP.NET Core
Saran dan Komentar
https://aka.ms/ContentUserFeedback.
Segera hadir: Sepanjang tahun 2024 kami akan menghentikan penggunaan GitHub Issues sebagai mekanisme umpan balik untuk konten dan menggantinya dengan sistem umpan balik baru. Untuk mengetahui informasi selengkapnya, lihat:Kirim dan lihat umpan balik untuk