Мы пока копали эту проблему, на части сервисов перешли на rest+protobuf, потребление ресурсов выросло на 30-40%. Цифры не маленькие, учитывая, что джаву и так критикуют за прожорливость, а в свете большого кол-во подов так и вообще. К GraphQL тоже присматривались, но так и не решились, уж больно много клиенту позволено.
Сразу оговорюсь, с Infiniband не работал, только с Ethernet сетями. По скоростным характеристикам особых проблем не вижу, затраты на открытие соединения будут только вначале, сериализация быстрая, так что должно хорошо получиться. Я бы только посмотрел в сторону стриминговой передачи с возможностью backpressure, чтобы можно с серверной стороны чуть прижать передающего, если серверная часть начнет захлебываться под нагрузкой. А с другой стороны возможность распараллеливания передачи, чтобы эффективно утилизировать канал.
что вместо поиска реальной проблемы пошли лепить одну заплатку на другую в надежде что это поможет вместо понимания что происходит и почему
Я даже отчасти рад, потому как смог передать настроение ) К сожалению, у нас именно так и было, много времени было потрачено на использование заплаток, чтобы хоть как-то улучшить ситуацию. Но в свою защиту могу сказать, что инфрой занимаются одни люди, а пишут сервисы другие люди и поиск проблем когда завязано несколько отделов это отдельный вид искусства . "И нельзя просто так взять и сделать дамп трафика" чтобы найти проблему, увы.
Если не сложно, то может быть у вас есть пример статьи с оформлением этого самого TL;DR? Попробую добавить. Я прямо скажу новичек в этом деле.
не стоит забывать, что grpc затачивался прежде всего под межсервисное взаимодействие, так что да, проблемы с UI у него очевидные. Обычно все через дополнительную проксю организуется. Насчет rsocket, пробовал лет 5 назад, не очень впечатлился + он сыроват еще был. Наличие protobuf под капотом grpc идет большим плюсом, так как это сразу готовый контракт. Использование же голого TCP не всегда является плюсом. В общем, grpc более консервативное решение, но всегда надо смотреть на задачу и инфру.
Уточнил у редактора, по правилам корпоративного блога статью не редактируют. Так что буду это учитывать уже на след-й раз (
интересная идея насчет кеширования, спасибо!
Мы пока копали эту проблему, на части сервисов перешли на rest+protobuf, потребление ресурсов выросло на 30-40%. Цифры не маленькие, учитывая, что джаву и так критикуют за прожорливость, а в свете большого кол-во подов так и вообще. К GraphQL тоже присматривались, но так и не решились, уж больно много клиенту позволено.
Сразу оговорюсь, с Infiniband не работал, только с Ethernet сетями. По скоростным характеристикам особых проблем не вижу, затраты на открытие соединения будут только вначале, сериализация быстрая, так что должно хорошо получиться. Я бы только посмотрел в сторону стриминговой передачи с возможностью backpressure, чтобы можно с серверной стороны чуть прижать передающего, если серверная часть начнет захлебываться под нагрузкой. А с другой стороны возможность распараллеливания передачи, чтобы эффективно утилизировать канал.
Если вылезут проблемы, я бы почитал )
привет, 100 гигов за какой промежуток времени? и какой тип нагрузки? более размазана или всплесками?
Спасибо за дополнение. Может у вас есть недавний опыт использования rsocket? особенно в связке с UI
Я даже отчасти рад, потому как смог передать настроение )
К сожалению, у нас именно так и было, много времени было потрачено на использование заплаток, чтобы хоть как-то улучшить ситуацию. Но в свою защиту могу сказать, что инфрой занимаются одни люди, а пишут сервисы другие люди и поиск проблем когда завязано несколько отделов это отдельный вид искусства . "И нельзя просто так взять и сделать дамп трафика" чтобы найти проблему, увы.
Если не сложно, то может быть у вас есть пример статьи с оформлением этого самого TL;DR? Попробую добавить. Я прямо скажу новичек в этом деле.
а как же интрига? + хотел показать решение проблем в динамике
не стоит забывать, что grpc затачивался прежде всего под межсервисное взаимодействие, так что да, проблемы с UI у него очевидные. Обычно все через дополнительную проксю организуется.
Насчет rsocket, пробовал лет 5 назад, не очень впечатлился + он сыроват еще был. Наличие protobuf под капотом grpc идет большим плюсом, так как это сразу готовый контракт. Использование же голого TCP не всегда является плюсом. В общем, grpc более консервативное решение, но всегда надо смотреть на задачу и инфру.