Занимаюсь проектированием новой системы.
Система будет на C# Core и микросервисах, gRPC. Еще ELK, Zabbix, PostgreSQL, Kafka. Ожидается примерно 10k rps. Пока что вижу примерно 10 микросервисов, хотя со временем их количество наверняка будет расти.
На вид, несколько десятков серверов должны справится с нагрузкой.
Развертывание и управление всего этого планируется через kubernetos. Нужно заранее предусмотреть канареечный деплоймент, откат на предыдущие версии.
Думаю, насколько необходимо ко всему этому добавлять service mesh? И если да, то какой?
Пока что вижу, что service mesh выглядит очень полезным. Подумываю использовать istio.
Есть у кого какие мысли, кто что использовал в похожих случаях?

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

A>Система будет на C# Core и микросервисах, gRPC. Еще ELK, Zabbix, PostgreSQL, Kafka. Ожидается примерно 10k rps. Пока что вижу примерно 10 микросервисов, хотя со временем их количество наверняка будет расти.

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

A>На вид, несколько десятков серверов должны справится с нагрузкой.

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


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

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

A>Думаю, насколько необходимо ко всему этому добавлять service mesh? И если да, то какой?
A>Пока что вижу, что service mesh выглядит очень полезным. Подумываю использовать istio.
A>Есть у кого какие мысли, кто что использовал в похожих случаях?

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

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

ДФ>А зачем 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, для подтормаживающих инстансов.

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

Здравствуйте, 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>Но уверенности в этом нет, вот и хочется понять, что другие думают и какие тут возможны проблемы.

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

Спасибо! Почитал, подумал, и решил не добавлять сервисную сетку в архитектуру системы. Может, в будущем будет добавлена, но не сейчас.

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

Что за сложности с большими объемами у ELK? У нас ожидается, в среднем, от 500 Мб до 2 Гб логов в секунду. Про "в секунду" не опечатка. Может получится писать в логи меньше, но пока непонятно, зависит от запросов бизнеса на аналитику.

ДФ>Ого, а что за задачи, требущие такого объема работ?
b2b система, напрямую с пользователями не работает. Система проектируется на замену существующей работающей системы. Существующая система уперлась в целый ряд проблем, поэтому решили ее переписать с нуля. На данный момент, она занимает, почти целиком, крупный датацентр.

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

Предполагается свой. Да, требование 24/7.
Почему свой кубер дорого? Вроде, взять двух девопсов на него, и норм? Ии что-то еще?
Про балансировщик — да, понятно. Плюс еще хочется мирроринг, а еще хочется тестирование прямо на проде, перед тем как выставлять новую версию микросервиса даже для части пользователей. Такое тестирование можно сделать на основе меток в метаинформации запроса. Видел такой метод в видео от Авито, выглядит очень полезным.

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

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