Comments 28
но как минус имеем создание нового канала на каждое сообщение, почему бы не использовать Protobuf через WebSocket?
Скорость. При использовании gRPC данные передаются в двоичном формате, что увеличивает скорость. Данные, передаваемые в двоичном формате, намного быстрее и эффективнее, чем JSON или XML.
Это что значит? JSON или XML буквами передаются что ли?
Толсто ((( Понимаете-же, что речь о бинарном формате vs текстовом? Или gzip (условно) не используете никогда и нигде?
Вот и появилось поколение, которое не отличает текстовый формат передаваемых данных со своей разметкой (которую надо парсить) и текстовым представлением отдельных значений передаваемых параметров (которые надо конвертировать) от двоичного формата, для которого не нужен парсинг и даже может быть совсем не нужна конвертация типов.
В контексте микросервисов тема не раскрыта. Как вы собираетесь шарить idl между сервисами?
Как вы думаете помогли-бы в микросервих rpc без idl? Условно есть функция на сервере которая имеет имя и аргументы, а вся обработка вызова, упаковка - распаковка аргументов и результата вынесена в рантайм
Proto создает либо огромные проблемы с читаемостью (goto definition показывает сгенерированный класс, который читать невозможно) либо проблемы с межьязыкоровой совместимостью когда proto создается динамически по исходникам. Он конечно быстрый и все такое, но неудобный.
goto definition показывает сгенерированный класс, который читать невозможно
Зачем читать сгенерированный код? К протобуфам можно и нужно относиться как к POD.
либо проблемы с межьязыкоровой совместимостью когда proto создается динамически по исходникам
Зачем proto генерить по исходникам? По исходникам чего, вообще, и как вы это себе представляете? Не по исходникам же типов потому что типы генерируют сами протобуфы. Потом, откуда будут браться номера полей? Или при удалении поля едет совместимость?
Нет, .proto всегда single source of truth, это из него все генерятся. Да и независимо от того откуда взялся.proto, откуда взяться проблемам межьязыковой совместимости если именно и хон и решает?
А ваш комментарий только подтверждает мой :) Есть всего два способа работы с прото - proto first когда вы генерируете исходник по proto и code first когда соотвественно наоборот. Если код генерится по прото, то я ожидаю что когда я тыкну F12 в студии она покажет мне прото. Ан нет она показывает сгенерированый класс, который читать разумеется невозможно. Проблема это среды или прото? А какая разница? Это в любом случае моя проблема.
Не по исходникам же типов потому что типы генерируют сами протобуфы.
Как раз по ним! В простом случае вообще без аннотаций, а в пределе с аннотациями включающими ID. Proto как такового не создается, но gRPC сервер отдает описание нормально. Генерировать прото по исходника супер удобно и если у вас моно репа/один язык, то смысла писать прото отдельно достаточно мало.
А проблемы есть например между Java и C# - Java сервер не любит отсутствие обязательных полей. Таки да, это проблема что C# клиент не проверяет при отправке что не все заполнено, но какая разница? Видно это только в рантайме.
Тема не раскрыта. Утверждение что передача json занимает 200 мс, а protobuf 20 мс нужно проверить. Напишите хотя бы простейший перф тест.
Как будто сводку от chatGPT прочитал ... . Одна вода
Ещё можно сказать, что grpc хорош для случаев взаимодействия 1 к 1. А брокеры вроде Кафки и реббита для бродкастинга. Часто возникают задачи обработки одного события в множестве сервисов - пилить grpc в каждом - ад. Но как взаимодействие 1 к 1 grpc просто бескомпромиссный вариант.
Недавно дебажили проблему на стыке микросервисов на gRpc, очень весело, в ответ иногда приходит null и делай что хочешь, проблема где то в сишных исходниках
Все-равно узкое место - это база. А дебажить json намного проще чем бинарный формат. nuff said. Понятно что где-то в верхней части кривой Шипелёва и на не такое пойдешь для выжимания последних крупиц перформанса, но чаще всего в этом нет необходимости.
JSON с быстрым сжатием на lz4 покажет похожие цифры скорости и объема трафика. Плюс есть и бинарные форматы для сериализации json'а (но мои эксперименты с ними показали те же цифры что и обычный JSON с сжатием).
Эта статья пахнет ChatGPT
Не оговорены минусы:
1)Отсутствие возможности передать null
2)Тут зависит от экосистемы, но для java/kotlin плагины гугла генерируют весьма и весьма своеобразные DTO, с которыми работать крайне многословно
Выросло поколение не понимающее, что сетевой овкрхед только растёт от одной "серебряной пули" К следующей.
Напомню, что всё начинается с презентационного уровня клиента, где сообщение кодируется в формат grpc, bison, json, XML или куда ещё из внутренних структур клиента. Маппинг неизбежен.
Далее это разбивается на пакеты и уходит в сеть, обрамляясь описателями каждого следующего уровня. Да, да, с перекладываением тела пакета из буфера в буфер.
Сервер, принимая пакеты, проводит обратную работу, а дополнительно сборку сообщения из пакетов.
А далее.. Обратно раскодируем XML, json, grpc, bson в тот вид, который может обработать хендлер сервера..
И всё это зрятраты и оверхед. Можно оставить один сетевой оверхед и передавать бинарник, ровно такой который понимает вызов хендлера, кладя его напрямую на его стек. Достаточно вспомнить старые добрые времена 80-х..)
Ну и за транзакционную стойкость микро сервисной архитектуры.. Эх, молодо-зелено..)
Использую на проекте под нодой+nest.js где один из сервисов выступает фасадом. Чем понравилась связка protobuf + grpc конкретно на этом стеке - это возможность создавать контракты. Написал контракт - он скомпилировался в typescript интерфейсы, которые обязательны к реализации на других сервисах при использовании соответствующих декораторов.
Если бы не одно но: любой не скалярный тип становится опциональным полем + не подразумевается отправка пустых массивов.
Странная математика. Было 100мс стало 10мс значит (по статье) разница 10 мс. Как? 90мс разница
Микросервисы: Почему именно gRPC?