protobuf vs gRPC

Próbuję zrozumieć protobuf i gRPC oraz jak mogę używać obu. Czy możesz mi pomóc zrozumieć, co następuje:

• Biorąc pod uwagę model OSI, gdzie jest na przykład Protobuf w warstwie 4?
• Zastanawiając się nad transferem wiadomości, jaki jest „przepływ”, co robi gRPC, czego brakuje protobufowi?
• Jeśli nadawca używa protokołu protobuf, czy serwer może używać gRPC, czy też gRPC dodaje coś, co może dostarczyć tylko klient gRPC?
• Jeśli gRPC może umożliwić synchroniczną i asynchroniczną komunikację, Protobuf służy tylko do kierowania i dlatego nie ma nic wspólnego ze stanem - prawda czy fałsz?
• Czy mogę używać gRPC w komunikującej się aplikacji frontendowej zamiast REST lub GraphQL?

Wiem już - lub zakładam, że tak - że:

Protobuf

• Protokół binarny do wymiany danych
• Zaprojektowany przez Google
• Używa wygenerowanego opisu „Struct” na kliencie i serwerze do usuwania / - organizowania wiadomości

gRPC

• Używa protobuf (v3)
• Ponownie od Google
• Struktura wywołań RPC
• Wykorzystuje również protokół HTTP / 2
• Możliwa komunikacja synchroniczna i asynchroniczna

Ponownie zakładam, że to łatwe pytanie dla kogoś, kto już korzysta z tej technologii. Nadal chciałbym ci podziękować za cierpliwość i pomoc. Byłbym również bardzo wdzięczny za wszelkie sieciowe zagłębienia się w technologie.

Bufory protokołów są (są?) Językiem definicji interfejsu i biblioteką serializacji:

• Definiujesz struktury danych w IDL, tj. Opisujesz obiekty danych, których chcesz użyć
• Udostępnia procedury do tłumaczenia obiektów danych do iz binarnego, np. Do zapisu / odczytu danych z dysku

gRPC używa tego samego IDL, ale dodaje składnię „rpc”, która umożliwia definiowanie sygnatur metod zdalnego wywoływania procedur przy użyciu struktur danych Protobuf jako typów danych:

• Definiujesz swoje struktury danych
• Dodajesz definicje metod RPC
• Dostarcza kod do obsługi i wywoływania podpisów metod przez sieć
• W razie potrzeby możesz nadal serializować obiekty danych ręcznie za pomocą Protobuf

W odpowiedzi na pytania:

1. gRPC działa na warstwach 5, 6 i 7. Protobuf działa na warstwie 6.
2. Kiedy mówisz „transfer wiadomości”, Protobuf nie przejmuje się samym transferem. Działa tylko na każdym końcu transferu danych, zamieniając bajty w obiekty
3. Używanie gRPC domyślnie oznacza, że używasz Protobuf . Możesz napisać własnego klienta, który używa Protobuf, ale nie gRPC do współdziałania z gRPC, lub podłączyć inne serializatory do gRPC - ale używanie gRPC byłoby łatwiejsze
4. Prawdziwe
5. tak, możesz

W rzeczywistości gRPC i Protobuf to dwie zupełnie różne rzeczy. Pozwól mi uprościć:

• gRPC zarządza sposobem, w jaki klient i serwer mogą współdziałać (podobnie jak klient / serwer sieciowy z REST API)
• protobuf to po prostu narzędzie do serializacji / deserializacji (podobnie jak JSON)

gRPC ma dwie strony: po stronie serwera i po stronie klienta, która może łączyć się z serwerem. Serwer udostępnia RPC (tj. Funkcje, które można wywołać zdalnie). I masz tam mnóstwo opcji: możesz zabezpieczyć komunikację (używając TLS), dodać warstwę uwierzytelniającą (używając przechwytywaczy), ...

Możesz użyć protobuf wewnątrz dowolnego programu, który nie musi być klientem / serwerem. Jeśli potrzebujesz wymieniać dane i chcesz, aby były mocno wpisane, protobuf to fajna opcja (szybka i niezawodna).

Mając to na uwadze, możesz połączyć oba, aby zbudować ładny system klient / serwer: gRPC będzie kodem klienta / serwera i będzie protokołem danych.

PS: Napisałem ten artykuł, aby pokazać, jak krok po kroku zbudować klienta / serwer z gRPC i protobuf przy użyciu Go.

grpc to framework zbudowany przez Google i jest używany w projektach produkcyjnych z samego Google, a #HyperledgerFabric jest zbudowany z grpc istnieje wiele aplikacji open source zbudowanych z grpc

protobuff to reprezentacja danych taka jak json to również jest przez Google w rzeczywistości mają tysiące plików proto generowanych w ich projektach produkcyjnych

grpc

• gRPC to platforma open source opracowana przez Google
• Pozwala nam tworzyć żądania i odpowiedzi dla RPC i obsługiwać resztę przez framework
• REST jest zorientowany na CRUD, ale grpc jest zorientowany na API (bez ograniczeń)
• Twórz w oparciu o HTTP / 2
• Zapewnia >>>>> uwierzytelnianie, równoważenie obciążenia, monitorowanie, logowanie
• [HTTP / 2]
  • HTTP1.1 został wydany w 1997 roku dawno temu
  • HTTP1 otwiera nowe połączenie TCP z serwerem przy każdym żądaniu
  • Nie kompresuje nagłówków
  • BRAK push serwera, działa tylko z Req, Res
  • HTTP2 wydany w 2015 roku (SPDY)
  • Obsługuje multipleksowanie
  • klient i serwer mogą przesyłać wiadomości równolegle przez to samo połączenie TCP
  • Znacznie zmniejsza opóźnienia
  • HTTP2 obsługuje kompresję nagłówków
  • HTTP2 jest binarny
    • proto buff jest binarny, więc świetnie pasuje do HTTP2
• [TYPY]
  • Jednoargumentowe
  • przesyłanie strumieniowe klienta
  • serwer strumieniowy
  • Dwukierunkowe przesyłanie strumieniowe
  • Serwery grpc są domyślnie asynchroniczne
  • Klienci grpc mogą być synchronizowani lub asynchroniczni

protobuff

• Bufory protokołów są niezależne od języka
• Parsowanie buforów protokołów (format binarny) jest mniej obciążające procesor
• [Naming]
  • Użyj wielbłąda w nazwach wiadomości
  • underscore_seperated dla pól
  • Użyj camelcase dla wyliczeń i CAPITAL_WITH_UNDERSCORE dla nazw wartości
• [Komentarze]
  • Wsparcie //
  • Wsparcie /* */
• [Zalety]
  • Dane są w pełni wpisane na maszynie
  • Dane są w pełni skompresowane (mniejsze wykorzystanie przepustowości)
  • Schemat (komunikat) jest potrzebny do wygenerowania kodu i odczytania kodu
  • Dokumentację można osadzić w schemacie
  • Dane można odczytać w dowolnym języku
  • Schemat może ewoluować w dowolnym momencie w bezpieczny sposób
  • szybszy niż XML
  • kod jest generowany automatycznie
  • Google wynalazł proto buff, używają 48000 protobuf messages i plików 12000.proto
  • Wiele platform RPC, w tym grpc, używa buforów protokołów do wymiany danych