protobuf vs gRPC


111

Saya mencoba memahami protobuf dan gRPC dan bagaimana saya dapat menggunakan keduanya. Bisakah Anda membantu saya memahami yang berikut:

  • Mempertimbangkan model OSI dimana, misalnya Protobuf pada layer 4?
  • Berpikir melalui transfer pesan bagaimana "aliran", apa yang dilakukan gRPC, apa yang terlewatkan oleh protobuf?
  • Jika pengirim menggunakan protobuf, apakah server dapat menggunakan gRPC atau apakah gRPC menambahkan sesuatu yang hanya dapat dikirim oleh klien gRPC?
  • Jika gRPC dapat membuat komunikasi sinkron dan asinkron menjadi mungkin, Protobuf hanya untuk marshalling dan oleh karena itu tidak ada hubungannya dengan status - benar atau salah?
  • Dapatkah saya menggunakan gRPC di aplikasi frontend yang berkomunikasi sebagai ganti REST atau GraphQL?

Saya sudah tahu - atau menganggap saya tahu - bahwa:

Protobuf

  • Protokol biner untuk pertukaran data
  • Didesain oleh Google
  • Menggunakan "Struct" yang dihasilkan seperti deskripsi di klien dan server untuk menghapus pesan marshall

gRPC

  • Menggunakan protobuf (v3)
  • Sekali lagi dari Google
  • Kerangka kerja untuk panggilan RPC
  • Memanfaatkan HTTP / 2 juga
  • Komunikasi sinkron dan asinkron dimungkinkan

Saya sekali lagi menganggap ini pertanyaan yang mudah bagi seseorang yang sudah menggunakan teknologi. Saya tetap berterima kasih karena Anda bersabar dan membantu saya. Saya juga akan sangat berterima kasih atas semua jaringan yang menyelami teknologi.

Jawaban:


92

Buffer protokol adalah (are?) Bahasa Definisi Antarmuka dan pustaka serialisasi:

  • Anda mendefinisikan struktur data Anda dalam IDL-nya, yaitu mendeskripsikan objek data yang ingin Anda gunakan
  • Ini menyediakan rutinitas untuk menerjemahkan objek data Anda ke dan dari biner, misalnya untuk menulis / membaca data dari disk

gRPC menggunakan IDL yang sama tetapi menambahkan sintaks "rpc" yang memungkinkan Anda menentukan tanda tangan metode Panggilan Prosedur Jarak Jauh menggunakan struktur data Protobuf sebagai tipe data:

  • Anda menentukan struktur data Anda
  • Anda menambahkan definisi metode rpc Anda
  • Ini menyediakan kode untuk melayani dan memanggil tanda tangan metode melalui jaringan
  • Anda masih dapat membuat serial objek data secara manual dengan Protobuf jika perlu

Sebagai jawaban atas pertanyaan:

  1. gRPC bekerja pada layer 5, 6 dan 7. Protobuf bekerja pada layer 6.
  2. Saat Anda mengatakan "transfer pesan", Protobuf tidak peduli dengan transfer itu sendiri. Ini hanya berfungsi di kedua ujung transfer data, mengubah byte menjadi objek
  3. Menggunakan gRPC secara default berarti Anda menggunakan Protobuf . Anda dapat menulis klien Anda sendiri yang menggunakan Protobuf tetapi tidak gRPC untuk beroperasi dengan gRPC, atau menambahkan serializer lain ke gRPC - tetapi menggunakan gRPC akan lebih mudah
  4. Benar
  5. ya kamu bisa

Bisakah Anda ceritakan tentang "Lapisan" yang Anda bicarakan? Tolong beri saya tautan untuk memahami konsep ini secara detail. Terima kasih.
Millie Hudson

Ini adalah model OSI - menambahkan tautan di pertanyaan. Masih bisa diperdebatkan apakah gRPC termasuk dalam lapisan 5 & 6 karena menggunakan protokol lapisan 7 ( HTTP/2), tetapi pasti melakukan tugas lapisan tersebut.
Peter Wishart

70

Sebenarnya, gRPC dan Protobuf adalah 2 hal yang sangat berbeda. Izinkan saya menyederhanakan:

  • gRPC mengelola cara klien dan server dapat berinteraksi (seperti klien / server web dengan REST API)
  • protobuf hanyalah alat serialisasi / deserialisasi (seperti JSON)

gRPC memiliki 2 sisi: sisi server, dan sisi klien, yang dapat menghubungi server. Server mengekspos RPC (mis. Fungsi yang dapat Anda panggil dari jarak jauh). Dan Anda memiliki banyak opsi di sana: Anda dapat mengamankan komunikasi (menggunakan TLS), menambahkan lapisan otentikasi (menggunakan interseptor), ...

Anda dapat menggunakan protobuf di dalam program apa pun, yang tidak perlu menjadi klien / server. Jika Anda perlu bertukar data, dan ingin data diketik dengan kuat, protobuf adalah pilihan yang bagus (cepat & andal).

Karena itu, Anda dapat menggabungkan keduanya untuk membangun sistem klien / server yang bagus: gRPC akan menjadi kode klien / server Anda, dan melindungi protokol data Anda.

PS: Saya menulis makalah ini untuk menunjukkan bagaimana seseorang dapat membangun klien / server dengan gRPC dan protobuf menggunakan Go, selangkah demi selangkah.


3
Terima kasih, ini membantu saya menerapkan sampel.
lony

7

grpc adalah kerangka kerja yang dibangun oleh google dan digunakan dalam proyek produksi dari google itu sendiri dan #HyperledgerFabric dibangun dengan grpc ada banyak aplikasi sumber terbuka yang dibangun dengan grpc

protobuff adalah representasi data seperti json ini juga oleh google sebenarnya mereka memiliki beberapa ribu file proto yang dihasilkan dalam proyek produksinya

grpc

  • gRPC adalah kerangka kerja sumber terbuka yang dikembangkan oleh google
  • Ini memungkinkan kami membuat Permintaan & Respons untuk RPC dan menangani sisanya dengan kerangka kerja
  • REST berorientasi CRUD tetapi grpc berorientasi pada API (tanpa batasan)
  • Dibuat di atas HTTP / 2
  • Menyediakan >>>>> Auth, Loadbalancing, Monitoring, logging
  • [HTTP / 2]
    • HTTP1.1 telah dirilis pada tahun 1997 sejak lama
    • HTTP1 membuka koneksi TCP baru ke server di setiap permintaan
    • Itu tidak memampatkan header
    • TIDAK ADA dorongan server, ini hanya berfungsi dengan Req, Res
    • HTTP2 dirilis pada 2015 (SPDY)
    • Mendukung multiplexing
    • klien & server dapat mendorong pesan secara paralel melalui koneksi TCP yang sama
    • Sangat mengurangi latensi
    • HTTP2 mendukung kompresi header
    • HTTP2 adalah biner
      • proto buff adalah biner sehingga sangat cocok untuk HTTP2
  • [JENIS]
    • Unary
    • streaming klien
    • streaming server
    • Streaming dua arah
    • server grpc adalah Async secara default
    • klien grpc dapat disinkronkan atau Async

protobuff

  • Buffer protokol adalah bahasa agnostik
  • Buffer protokol penguraian (format biner) tidak membutuhkan banyak CPU
  • [Penamaan]
    • Gunakan kasus unta untuk nama pesan
    • underscore_seperated untuk bidang
    • Gunakan camelcase untuk Enum dan CAPITAL_WITH_UNDERSCORE untuk nama nilai
  • [Komentar]
    • Dukung //
    • Dukung /* */
  • [Keuntungan]
    • Data sepenuhnya Diketik
    • Data sepenuhnya dikompresi (penggunaan bandwidth lebih sedikit)
    • Skema (pesan) diperlukan untuk menghasilkan kode dan membaca kode
    • Dokumentasi dapat disematkan dalam skema
    • Data dapat dibaca dalam berbagai bahasa
    • Skema dapat berkembang kapan saja dengan cara yang aman
    • lebih cepat dari XML
    • kode dibuat untuk Anda secara otomatis
    • Google menemukan proto buff, mereka menggunakan 48000 pesan protobuf & 12000. fileproto
    • Banyak sekali framework RPC, termasuk grpc yang menggunakan buffer protokol untuk bertukar data

3
Kompresi TIDAK mengurangi penggunaan CPU. Anda harus mengompres dan mendekompresi untuk mengirim atau menggunakan data dalam serialisasi- yang membakar CPU MELAKUKAN itu .. Apa yang dilakukan kompresi untuk Anda adalah mengurangi jejak serial, mengurangi potensi tekanan memori, penggunaan disk jika digunakan untuk membuat serial ke disk, atau lebih sinyal kabel.
Svartalf

@Svartalf mengedit untuk memperbaiki ini. Terima kasih telah menunjukkannya!
swrobel
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.