Twirp против gRPC. Стоит ли?

[@Dmitri-D]

gRPC тоже не менялся и остается совместимым с самим собой старых версий. Так что не вижу проблем в этом плане. Про балансер — да, согласен. Но они и не заботились, что у AWS что-то там не сделано.
Если говорить о проблемах в использовании gRPC, когда много разных клиентов сидят на разных версиях, вероятно это девелопер создавал сам себе такие проблемы. Наиболее простой способ выстрелить себе в ногу — это выпустить обновление на сервер, и там поменять тэги существующих полей или, например, добавить обязательное поле, о котором старые клиенты ничего знают и послать в запросе не могут. Поэтому правила очень простые — поля только добавляются, и теги только инкрементируются, все новые поля — необязательные. Если любое из этих условий выполнить невозможно, то создается новая точка RPC (т.е. новая процедура или метод), но старая должна продолжать работать пока есть хотя бы один клиент ее вызывающий.

[@BOOTLOADER]

У меня лично опыт негативного нет gRPC. Но у меня все инфраструктура новая на одной версии. Я пытался с ними связаться, чтобы получиться какие-то точные пояснения ошибок, но пока безуспешно. Насчет добавления удаления полей есть Reserved Fields которые вам позволяют избежать ошибок, но как я сказал — пока нет информации были ли причины именно в этом.

[@Dmitri-D]

Reserved Fields которые вам позволяют избежать ошибок

Ошибка возникнет, если например вы использовали необязательное поле «customer_id» с тегом 1. А затем вы удалили это поле из выдачи, а потом ввели поле допустим «order_id» и присвоили ему «свободный» тэг 1. Все старые клинеты начнут читать order_id думая что читают customer_id.
Что бы этого не произошло вы добавляете поля с новыми тегами, и никогда не переиспользуете удалённые ранее. Так же никогда не удаляете то, что было хоть 1 раз объявлено как обязательное. Вот и вся премудрость. С протоколом там всё в порядке.
Не в порядке с асинхронным режимом. Впрочем, я интенсивно тестировал прошлым летом. Может, с тех пор что-то и изменилось.

[@BOOTLOADER]

В спецификации так и написано, если вы удаляете или комментируете поле, используете reserved fields, чтобы избежать колизий.

Reserved Fields

If you update a message type by entirely removing a field, or commenting it out, future users can reuse the tag number when making their own updates to the type. This can cause severe issues if they later load old versions of the same .proto, including data corruption, privacy bugs, and so on. One way to make sure this doesn't happen is to specify that the field tags (and/or names, which can also cause issues for JSON serialization) of your deleted fields are reserved. The protocol buffer compiler will complain if any future users try to use these field identifiers.

message Foo {
reserved 2, 15, 9 to 11;
reserved «foo», «bar»;
}

[@Dmitri-D]

Да, это об одном и том же. Просто reserved — это способ показать остальным _пользователям_, не gprs, что тег некоего поля был ранее использован.
Но, если вы сам девелопер некоей rpc коммуникации, т.е. вы пишете классы-сообщения, — ваши пользователи и так не смогут переиспользовать удаленные теги. Поэтому вы можете с тем же успехом и не объявлять их reserved, а просто сам с собой договориться, что пользовать те номера уже нельзя. Как это сделать наиболее простым способом? Инкрементируя некий счётчик тегов. Т.е. для новых тегов использовать последний номер + 1, о чем я и говорил в начале.

[@spein]

Используем go-micro в проекте, как по мне, очень неплохая альтернатива grpc, если считать его альтернативой, ведь он поддерживает grpc. Стандартно работает по http/1.1 и обладает всеми перечисленными преимуществами даже более: github.com/micro/go-micro

[@awesomer]

gRPC — это протокол обмена данными.
go-micro — это фреймворк для создания микросервисов, который берет на себя решение многих и многих проблем, в том числе и страшно далеких от протокола обмена данными.

go-micro — это не альтернатива gRPC.

Это инструмент для других целей.

[@spein]

godoc.org/google.golang.org/grpc
Я не спорю, что grpc это название протокола, но все-же это и библиотека одноименная. Я говорил о библиотеке и об ее функционале. В статье вроде не протокол же рассматривается?

[@awesomer]

А че, в Go есть и альтернативные реализации gRPC?
go-micro использует всю ту же библиотеку, что вы и напрямую бы стали.

[@imanushin]

А есть сравнение — какая разница в скорости работы простых http вызовов против gRPC/Twirp ?

Еще интересно — какой вообще порядок величин, по сравнению с дальнейшей десериализацией?

Интересует именно цифры, естественно.

[@BOOTLOADER]

github.com/rpcx-ecosystem/rpcx-benchmark

[@awesomer]

то скорее всего начали использовать Protobuf и и его реализацию от Google gRPC

Protobuf — и есть реализация Google.

А gRPC — это протокол построенный поверх Protobuf

[@BOOTLOADER]

Да, вы правы — получить не совсем корректно. Просто есть реализация от Google, есть вот от Twich и от многих других: github.com/google/protobuf/blob/master/docs/third_party.md

[@awesomer]

gRPC — это вовсе не «реализация протокола Protobuf»

Написано неграмотно.
Ну чтобы вам было понятно, это как сказать: «http — это реализация протокола TCP/IP».
То, что TCP/IP лежит в основе http не делает http его реализацией. «Реализовать http на основе TCP/IP» — так сказать можно.

[@BOOTLOADER]

Да, gRPC использует Protobuf как язык описание интерфейсов, но такая форма не совсем понятная, поэтому для просто я использовал как «реализация протокола Protobuf».

[@slonpts]

Статья хороша, но awesomer верно заметил, что фраза

Protobuf и и его реализацию от Google gRPC или Go-Kit от Peter Bourgon

будет путать следующие поколения программистов еще много лет. Наверное, лучше заменить на

RPC фреймворк поверх Protobuf, например, gRPC от Google или Go-Kit от Peter Bourgon

[@BOOTLOADER]

Поправил. Спасибо.

[@acmnu]

Не совсем понимаю, почему все эти протоколы делаются поверх HTTP, а не голого TCP, если уж так важна скорость.

[@awesomer]

gRPC использует http/2. А он — бинарный с поддержкой мультиплексирования нескольких соединений в одном TCP. То есть довольно быстрый.

Тогда уж не TCP, а UDP, если вам нужна максимальная скорость.
Вам никто не мешает гонять Protobuf или MsgPack поверх UDP.

Только вот но.
Например, gRPC — законченное решение. В частности, полагающееся на защиту https/tls.

Полагаю, http/2 выбрал в gRPC за ради универсальности. Он хорошо проходит через NAT/proxy/firewall. Для него есть стандартное шифрование. И пр. и пр.

[@acmnu]

Тогда уж не TCP, а UDP, если вам нужна максимальная скорость.

Тогда коррекцию ошибок надо писать, что не всегда выгодно.