Re[2]: Нужен ли service mesh?
От: andsm Россия  
Дата: 28.10.20 14:42
Оценка:
Здравствуйте, Дельгядо Филипп, Вы писали:

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


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

ДФ>Задачи про перекодирование видео? Или зачем еще несколько десятков серверов на 10k rps?

Не видео. Но для ответа на некоторые запросы нужно до 90 сек одного ядра и 2-3 Гб памяти. Но это нечасто, обычно 1-2 сек и 100-200 Мб. При этом и запрос, и ответ — примерно 1-2 кб.

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


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

ДФ>Какие задачи будет решать service mesh? Кстати, если брать Istio, то тут уйдет где-то с десяток ядер на 10k rps, оно точно надо?

ДФ>Вообще, современные меши или медленные и функциональные или медленные и нефункциональные, так что нужно точно понимать, для чего нужен меш.
Десяток ядер от нескольких сотен ядер норм, планируем брать машины с большим количеством ядер
Linkerd он вроде как быстрее, но менее функционален.
Все же, непонятно как добавление меша скажется на квантилях. Графики, что видел, не очень. Хотя можно не так сильно грузить отдельные сервера.

Что хочется от меша:
1. Автобалансировка. Это и без меша для gRPC можно сделать, на L7 прокси. Но не проще ли на меше?
2. Наблюдаемость, метрики.
3. Балансировка трафика между версиями, мирроринг.
4. Circuit breaker, для подтормаживающих инстансов.

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