Comments 12
Одна из самых неудобных частей серверного C++ API это uni-/bidirect стриминговые методы. Нет достаточно хорошего примера, как например обмениваться сообщениями между двумя и более клиентами. Я попытался реализовать нечто подобное в примерах для qtprotobuf, но по прежнему не до конца понятно как правильно осуществлять жонглирование контекстами и очередями сообщений. Думал будет немного освещено в статье, но к сожалению не увидел. В целом куда удобнее пользоваться Go lang серверным API.
UPD: Речь выше о WithAsyncMethod* серверах
Какой минимальный/средний оверхед у gRPC пакетов по сравнению с сырым protobuf payload (т.е. без HTTP/2 обвязки)?
Ответ очевиден, что это HTTP2 заголовок, который вы сами формируете + размер передаваемых данных(5 байт)
Но если вспомнить про то, что HTTP2 поддерживает gzip сжатие данных, думаю HTTP2 становится чуть привлекательнее чем raw protobuf payload.
Проблема текущих реализаций gRPC, как мне кажется, в том что они гвоздями прибиты к Protobuf и не поддерживают других сериализаторов.
В ситуациях где есть очень большая нагрузка использовать Protobuf становится достаточно накладно. По крайней мере в Go десериализация вызывает много мусора даже на gogo-protobuf. И если поток данных большой то процессор больше времени проводит собирая мусор чем делая полезное дело. На плюсах в режиме reuse вроде бы ситуация получше, но все равно не очень.
В Cap'n'Proto дела получше, но, по крайней мере в Go-либе, аллокации все равно есть на каждое сообщение разобранное.
В итоге мы уехали на flatbuffers вместо protobuf в своем проекте и не имеем проблем с накладными расходами. Но у нас не gRPC, да и использовать flatbuf довольно неудобно местами.
gRPC в качестве протокола межсервисного взаимодействия. Доклад Яндекса