Cześć,
Mam pytanie do osób, które pracują w architekturze mikroserwisów. Czy do komunikacji pomiędzy serwisami wykorzystujecie gRPC (grpc.io) ? Jeśli tak, to jaka jest skala Waszych aplikacji i jakich problemów chcieliście uniknąć wybierając właśnie gRPC? Obecnie REST jak tak bardzo powszechny a poczytałem w internecie i do pewnych problemów myślę, że warto rozważyć takie rozwiązanie.
Odkopuję :) Jak to u Was wygląda? Nadal wszędzie REST? Warto zagłębić się w temat bo może być wkrótce detronizacja?
Na razie widziałem Rest, Thrift, Avro, Kafka, RabbitMQ i oczywiście Soap do łączenia się z prawdziwym legacy. Żadnego gRPC ani nawet
Protocol Buffers - nie :(
też mnie to w sumie ciekawi
stosujecie gRPC? jak tak to dlaczego?
Używałem grpc na produkcji. Jak nie jestem w skali podobnej google to odpuscilbym sobie grpc. Zabawa ze schema nie jest za darmo i dystrybuowanie jej między serwisami... okropne.
Polecam przeczytac https://vasters.com/blog/data-encodings-and-layout/
As a summary, I’d like to suggest to embrace the “Content-Type” declaration available in protocols like HTTP, MQTT (5.0+), and AMQP, and choose the appropriate data layout and encoding per use-case. Make data encoding and layout choices an explicit engineering decision, and don’t blindly pick a format to rule them all. Also be deliberate about long term storage choices and really think hard about taking dependencies on formats requiring external schema references outside of RPC scenarios.
jest tez cos jak https://github.com/twitchtv/twirp. czyli grpc troche lepsze
Przeciez glowny powod uzywania to reduced footprint. Naprawde potrzebujesz tego?
Żadnej detronizacji nie będzie.
Czy potrzebuję? Szczerze to nie wiem. Wczytuje się dopiero w temat, parę razy słyszałem wychwalanie, że gRPC to przyszłość itp. stąd moja ciekawość czy gdzieś się to już u Was przyjęło
Raczej REST + JSON.
Używałem grpc na produkcji. Jak nie jestem w skali podobnej google to odpuscilbym sobie grpc. Zabawa ze schema nie jest za darmo i dystrybuowanie jej między serwisami... okropne.
Co do tego "nie jesteś Googlem" i psioczenia że firmy bez odpowiedniej skali biorą się za gRPC itd. - może to i lepiej, że gRPC jest złożone i trzeba się wokół niego natańcować?
Spójrz na to w ten sposób. Jak uderzenie do drugiego serwisu jest trudne i kosztuje, to człowiek nawet niezbyt świadomy konsekwencji swoich poczynań z czystego lenistwa zastanowi się, czy naprawdę musi, bo mu się nie będzie chciało z tym użerać. A przez RESTy z JSONami to można walić tymi requestami, jakby jutra nie było, a potem zdziwienie i płacz że odpowiedzi przychodzą po minucie do dziesięciu, z małego ruchu robi się gazylion żądań i przeżartych zasobów, z 5 nines zrobiło się 2 nines, most of the week, a cała architektóra to turbo-plątaniec dziwnych zależności :D
Dodał bym na poziomie ogólniejszym, że wielką szkodą dominacji REST w głowach jest strata modelu zdalnego wywołania procedur (RPC). Były złe implementacje, overingeneering, ale to nie przekreśla zasady.
A na modyfikacjach stanu (tam by się REST definiował) świat się nie kończy.
Czasem wyrazista, nie oszukiwana procedura z wyrazistymi argumentami jest ważna.
I mamy niby-REST, się robi jakieś nagięcia, pokrętne operacja, gwałci się to, bo od zdroworozsądkowych wymogów trudno uciec.
PS. akurat z protokołów binarnych jestem bardzo zadowolony na tabletach / biednej sieci GSM.
To nie muszą być mikrokotrolery, żeby się opłacało.
Akurat Thrift a nie gRPC, ale ta sama grupa.