Здравствуйте, andsm, Вы писали:

A>Здравствуйте, Дельгядо Филипп, Вы писали:

ДФ>>А зачем Zabbix и ELK? Да и gRPC вызывает сомнения.

A>ELK — для сбора логов и анализа. Zabbix — для визуализации. Можно подумать задействовать Grafana, чтобы было то же что и у istio, но какой-то инструмент визуализации нужен.
A>Почему gRPC вызывает вопросы? Вроде наоборот лучше REST, потому что contract first. Да и более скоростной. Задачи балансировки, с учетом особенностей gRPC, как раз можно при помощи service mesh решить. Можно конечно и просто на прокис, типа envoy, но сетки дают больше функционала.

ELK на больших объемах не очень удобен, лучше уж vector+Clickhouse+Lighthouse/Grafana
Zabbix — это уже совсем старое решение, для мониторинга лучше прометеус, а картинки — в той же графане
gRPC — это довольно странное решение для моноязыковых проектов, приходится все упихивать в protobuf, а он не самый удобный и хороший формат. Да и не поддерживается нормально заметной частью service mesh/балансировщиков. Для нескольких сервисов gRPC не даст заметного выигрыша.


ДФ>>Задачи про перекодирование видео? Или зачем еще несколько десятков серверов на 10k rps?
A>Не видео. Но для ответа на некоторые запросы нужно до 90 сек одного ядра и 2-3 Гб памяти. Но это нечасто, обычно 1-2 сек и 100-200 Мб. При этом и запрос, и ответ — примерно 1-2 кб.

Ого, а что за задачи, требущие такого объема работ?

Ф>>Хм, а зачем Kubernetes, какие задачи он решит? Канарейку и откат с помощью Кубера не сделать, все равно нужно будет свои скрипты писать.

A>Канарейку можно сделать с помощью istio, для части случаев. Это за счет маршрутизации трафика для сервисов без состояния, между версиями сервиса.
A>Для развертывание на пусть и всего лишь паре десятков серверов кубер выглядит полезным. Как без него делать бесшовный деплоймент и т.п.? Можно, но сложнее.
A>Да, бесшовный деплоймент это одно из требований к системе.

Эээ, кубер предполагается свой или чужой? Если свой, то это очень дорого в поддержке, особенно при требовниях 24*7 (а бесшовный деплоймент, как мне кажется, предполагает 24*7).
Но кубер не дает никаких особых возможностей для деплоймента без остановки (как и истио). Все равно нужно писать свои скрипты управления балансировщиком...


ДФ>>Какие задачи будет решать service mesh? Кстати, если брать Istio, то тут уйдет где-то с десяток ядер на 10k rps, оно точно надо?
ДФ>>Вообще, современные меши или медленные и функциональные или медленные и нефункциональные, так что нужно точно понимать, для чего нужен меш.
A>Десяток ядер от нескольких сотен ядер норм, планируем брать машины с большим количеством ядер
A>Linkerd он вроде как быстрее, но менее функционален.
A>Все же, непонятно как добавление меша скажется на квантилях. Графики, что видел, не очень. Хотя можно не так сильно грузить отдельные сервера.

Плохо оно скажется, увы.


A>Что хочется от меша:
A>1. Автобалансировка. Это и без меша для gRPC можно сделать, на L7 прокси. Но не проще ли на меше?

Это умеет делать любой балансировщик, хоть голый nginx

A>2. Наблюдаемость, метрики.

Это можно делать на том же nginx, тем более что метрики нужно все равно снимать и с конечных приложений. Метрики с меша не очень полезны.

A>3. Балансировка трафика между версиями, мирроринг.

Тут да, меш помогает (писать руками скрипты на nginx сложно), но платить за это istio+kubernetes — получается еще дороже, увы.
Тут стоит прикинуть все требования к инфраструктуре, а уже потом думать про service mesh.

A>4. Circuit breaker, для подтормаживающих инстансов.
Хм, там мало circuit breaker, там еще много что нужно, по идее. И даже в istio всего нужного нет.
Вообще, удобнее это реализовывать через библиотеки на клиентах. Для rest их много, про gRPC не в курсе.


A>И еще момент с мешем. Все выглядит, как будто со временем меши станут практически обязательной частью хорошей микросервисной архитектуры. Не знаю, так ли это, но такое у меня сложилось впечатление, после прочтение множества всего по мешам и микросервисам. Передаем часть задач с разработки на платформу с мешом, снимаем ряд задач с разработчиков. Повышается производительность разработки. Идея вроде выглядит здраво.

Ну, в теории — да. На практике — все существующие меши еще сырые и медленные, в продакшен их тащить сложно, а для небольших проектов (типа описанного) вообще нет смысла.
Иногда дешевле самому написать только то, что нужно..

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