Но тут дело ведь не только в потере сообщений. Консьюмеры не получат ничего, что было опубликовано в момент, когда они были отключены: например, в следствии бага, а момент редеплоя или каких-либо других работ.
А какую топологию кластера натса вы в итоге используете?
Мы в своих внутренних исследованиях обнаружили нестабильность работы NATS при кластером сетапе в 5 нод и использовании Jetstream (один баг даже зарепортили). В частности это проявляется в нестабильном создании стримов, "отключении" консьюмеров.
Также нас не очень устроила скорость работы Jetstream: при 300-400k RPM латенси записи начинает очень сильно уступать кафке. Ну и с масштабированием стримов тоже есть вопросы.
Общий наш вывод в том, что nats без Jetstream хорош, но с ним - пока слишком молод и нестабилен.
Разница между RPC и REST лишь в понятийной области. Вполне можно использовать REST, но обычно сложно уложить многообразие действий в парадигму REST, да и не особо нужно.
В нашем случае, да, у каждого сервиса свой набор эндпоинтов, которые вызываются другими. Другие сервисы, разумеется, знают в какой сервис они шлют запросы.
Производительность ниже, чем если бы это был монолит, но зато мы можем разрабатывать такие системы отдельно друг от друга. Также никто не отменяет кэши и другие оптимизации
Это один из паттернов возможных обменов. Например, недоступна шина, сервисы живут на одном физическом сервере или имеется особый характер данных, скажем вы выгружает видео файл и передаёте его другому сервису.
В общем смысле ответ таков. Каждый сервис занимается своими задачами, поддерживается отдельной командой и отвечает за выделенную предметную область.
Но различные процессы в одних сервисах могут запускаться как реакция на изменения в других. Именно для отправки сообщений о подобных изменениях и нужна шина данных
Не факт. Большая часть современной нагрузки - это нагрузка на сеть, когда процесс, обрабатывая входящий запрос делает какое-то количество исходящих запросов к другим системам, базам данных, очередям и прочему
Очень интересно, жду продолжения. Все, что связанно с логистикой и складом - супер интересная тема, ведь в ней айти встречается с реальным миром как никогда близко
Согласен с вами. Своим комментарием я имел в виду, что пульсар, имея в основе систему хранения логов, похож в этом на Кафку, но в отличие от нее добавляет поверх ещё ряд функций: отложенные сообщения, отсутствие ограничения на число консьюмеров и другое. Все то, что в случае с кафкой пришлось бы реализовывать самостоятельно. Но все это правда не бесплатно с точки зрения надёжности
Многие на собеседованиях любят гонять по последним фичам языка.
Эта фраза задаёт дух остальной части статьи: на собеседованиях спрашивают чушь, ведь большая часть сидит на старых версиях.
При этом из первого не следует второго. То, что на собеседованиях глупо спрашивать все распоследние фичи языка, которые легко посмотреть в чейнджлоге не означает, что сидеть на допотопных версиях языков и библиотек является хорошей практикой.
Оправдания в духе "у нас тут миллиард строк кода, нас некогда его рефакторить, нас надо фичи пилить" говорят лишь о том, что уровень разработки в компании низкий, а всем заправляют менеджеры, которые стремятся получить результат здесь и сейчас. Для компании такой подход может быть и оправдан, но для разработчика работа в таком месте является не всегда правильным решением.
Это как собеседования по алгоритмам: обычно они не имеют отношения к реальной работе, но это не значит, что разработчик совсем не должен думать о своей теоретической подготовке.
Если суммировать, то по-сути к увеличению частоты релизов привели выстраивание и нормализация процессов, появление автотестов и разбиение релизов на более мелкие.
Абсолютно правильный подход с точки зрения организации работы, вот только для команд в итоге это превращается в бесконечную гонку и работу на фича фабрике. Правда, с последним ничего не поделать наверное.
Статья хотя и рассматривает тему, которая в интернете и различных учебниках раскрыта уже множество раз, но все же может кому-то пригодиться.
Вопрос в другом: зачем у вас в компании для повышения на следующий грейд решать какие-то выдуманные задачи, если процессу повышения предшествует как минимум полгода работы сотрудника? Разве его результатов за период не достаточно для принятия решения? В чем ценность того, что человек смог написать алгоритм калькулятора?
Но тут дело ведь не только в потере сообщений. Консьюмеры не получат ничего, что было опубликовано в момент, когда они были отключены: например, в следствии бага, а момент редеплоя или каких-либо других работ.
Это не является проблемой?
Кластер же позволяет вам проводить работы на nats, пересетапливать сервера без простоя и т.д.
Как сейчас вы обеспечиваете бесперебойную работу?
Также, как я понимаю, вам не требуется персистивность сообщений после публикации продюсером?
А какую топологию кластера натса вы в итоге используете?
Мы в своих внутренних исследованиях обнаружили нестабильность работы NATS при кластером сетапе в 5 нод и использовании Jetstream (один баг даже зарепортили). В частности это проявляется в нестабильном создании стримов, "отключении" консьюмеров.
Также нас не очень устроила скорость работы Jetstream: при 300-400k RPM латенси записи начинает очень сильно уступать кафке. Ну и с масштабированием стримов тоже есть вопросы.
Общий наш вывод в том, что nats без Jetstream хорош, но с ним - пока слишком молод и нестабилен.
Разница между RPC и REST лишь в понятийной области. Вполне можно использовать REST, но обычно сложно уложить многообразие действий в парадигму REST, да и не особо нужно.
В нашем случае, да, у каждого сервиса свой набор эндпоинтов, которые вызываются другими. Другие сервисы, разумеется, знают в какой сервис они шлют запросы.
Производительность ниже, чем если бы это был монолит, но зато мы можем разрабатывать такие системы отдельно друг от друга. Также никто не отменяет кэши и другие оптимизации
Это один из паттернов возможных обменов. Например, недоступна шина, сервисы живут на одном физическом сервере или имеется особый характер данных, скажем вы выгружает видео файл и передаёте его другому сервису.
Файл это просто носитель информации
В общем смысле ответ таков. Каждый сервис занимается своими задачами, поддерживается отдельной командой и отвечает за выделенную предметную область.
Но различные процессы в одних сервисах могут запускаться как реакция на изменения в других. Именно для отправки сообщений о подобных изменениях и нужна шина данных
Не факт. Большая часть современной нагрузки - это нагрузка на сеть, когда процесс, обрабатывая входящий запрос делает какое-то количество исходящих запросов к другим системам, базам данных, очередям и прочему
Очень интересно, жду продолжения. Все, что связанно с логистикой и складом - супер интересная тема, ведь в ней айти встречается с реальным миром как никогда близко
Ещё один вариант, который очень простой, но довольно рабочий - использование байесовского классификатора.
Можно классифицировать на любое число классов, очень быстро работает
Можно сделать nack и настроить в пульсаре redelivery timeout: тогда оно будет предоставлено через заданный интервал времени
Да, все верно, используем в том числе отложенные сообщения
Согласен с вами. Своим комментарием я имел в виду, что пульсар, имея в основе систему хранения логов, похож в этом на Кафку, но в отличие от нее добавляет поверх ещё ряд функций: отложенные сообщения, отсутствие ограничения на число консьюмеров и другое. Все то, что в случае с кафкой пришлось бы реализовывать самостоятельно. Но все это правда не бесплатно с точки зрения надёжности
Пока их относительно не много. 1000+ партицированных топиков и соответственно 5000+ топиков-партиций
Конкретно pulsar — это кафка на стероидах. Тоже log внутри, но с добавлением некоторой логики сверху.
Pulsar тоже не очень любит. Как минимум размер пакета в протоколе по-умолчанию — 5 мегабайт.
Может быть в целом и не нужно слать такие большие задания? Положили пейлоад в сторадж, положили событие с его id в очередь и все
Благодарю за поздравления :)
Абстрактно отвечать не готов. Часто да, язык в дистрибутиве операционный системы не самый свежий.
Судя по комментариям именно в легаси монстрах этот вопрос и возникает.
Эта фраза задаёт дух остальной части статьи: на собеседованиях спрашивают чушь, ведь большая часть сидит на старых версиях.
При этом из первого не следует второго. То, что на собеседованиях глупо спрашивать все распоследние фичи языка, которые легко посмотреть в чейнджлоге не означает, что сидеть на допотопных версиях языков и библиотек является хорошей практикой.
Оправдания в духе "у нас тут миллиард строк кода, нас некогда его рефакторить, нас надо фичи пилить" говорят лишь о том, что уровень разработки в компании низкий, а всем заправляют менеджеры, которые стремятся получить результат здесь и сейчас. Для компании такой подход может быть и оправдан, но для разработчика работа в таком месте является не всегда правильным решением.
Это как собеседования по алгоритмам: обычно они не имеют отношения к реальной работе, но это не значит, что разработчик совсем не должен думать о своей теоретической подготовке.
Если суммировать, то по-сути к увеличению частоты релизов привели выстраивание и нормализация процессов, появление автотестов и разбиение релизов на более мелкие.
Абсолютно правильный подход с точки зрения организации работы, вот только для команд в итоге это превращается в бесконечную гонку и работу на фича фабрике. Правда, с последним ничего не поделать наверное.
Статья хотя и рассматривает тему, которая в интернете и различных учебниках раскрыта уже множество раз, но все же может кому-то пригодиться.
Вопрос в другом: зачем у вас в компании для повышения на следующий грейд решать какие-то выдуманные задачи, если процессу повышения предшествует как минимум полгода работы сотрудника? Разве его результатов за период не достаточно для принятия решения? В чем ценность того, что человек смог написать алгоритм калькулятора?