Существует целая куча брокеров сообщений и того, что может быть использовано в их качестве. Kafka, RabbitMQ, ActiveMQ, NATS. Продукты от AWS, Microsoft Azure, Yandex Cloud. Notify в PostgreSQL, Queue в Тарантуле, очередь в Redis и ещё куча других решений.

При выборе брокера сообщений я бы задал один вопрос:

Вам понадобится практически неограниченное горизонтальное масштабирование, чтобы можно было сдерживать нелинейный рост нагрузки, превышающей ~10 тыс сообщений в секунду? А если ещё раз подумать?

Если да - то ваш путь лежит в мир боли Кафку и экосистему Apache, практически без вариантов. Возможно, облачные поделия и не уступят ей, но это не точно, да и в 2023 в России уже не особо актуально.

Если планируемый рост нагрузки не столь страшен - отталкиваться можно от используемого стека. Все живёт в Azure? Берём их брокер. У нас целый зверинец продуктов Apache? Можно ActiveMQ или простенькую конфигураци Kafka. Пишем на Go? NATS отлично впишется в качестве подключаемого модуля, прямо внутрь вашего приложения, правда он не умеет сохранять опубликованные в нем сообщения после падения.

Ну а если нет какой-то такой специфики - берём попсовый RabbitMQ, знакомый практически каждому бэкенд разработчику, и не выпендриваемся.

Я пытался трудоустроится джуном в мск, я использовал площадку hh. И не использовал другие площадки (просто потому что мне было лень). По правилам своего эксперимента у меня было законченное высшее и не было никакого опыта работы.

К сожалению эксперимент получился не до конца удачным. Я потерял доступ к своему аккаунту на hh и не смог его восстановить без анальной верификации от которой я отказался. Так что к сожалению тут не будет пруфов, и планированная статья на хабр так же не состоится.


И того, изначально я составил простенькое резюме в которое я упихал свое ФИО и указал универ. т.к. более ничего у меня не было. С таким резюме я вышел на рынок и отправил 30 откликов отклики отправлялись на: стажировки, поиски разработчика, поиски разработчика без опыта, поиски джуниора, поиск разработчика с опытом 1-3. Так же дополнительно при отклике я прикладывал сопроводительное письмо, которое мне сгенерировал ИИ.

Из этих 30 откликов я получил 4 предложения пройти тестовое. Рассмотрев все 4, я решил что меня заинтересует только 1. (К нему мы еще вернемся).

Следующим шагом был большой спор в одном из чатов по результатам которого в резюме добавилось следующее: Фотография, ссылка на гитхаб с проектами, подробное описание технических книг, а так же в опыт было вписаны курсовые и дипломные работы. (Важно отметить, что я не врал и честно указал, что это именно курсовые и дипломные работы). С таким подходом я получил 3 года опыта. С новым резюме я отправил еще 30 откликов. Здесь все пошло куда живее, на каждый 3й отзыв я получал приглашение пройти тестовое задание.

И того я имел на руках 14 приглашений на 60 откликов.
Мной было выполнено 10 тестовых из которых я получил ответ на 4. Очень часто за тестовым заданием шло еще одно таким образом фильтр сузился до 2х собеседований.

На каждом из собеседований прогнали по основам языка, паттернам и немного sql, по итогам собеседований было получено 2 приглашения присоединиться к рабочим командам с примерной зарплатой в 50к рублей.

Важные замечания. Не нужно врать, но опыт должен быть заполнен. Вас никто не позовет на собес, без тестового, вы сделаете очень много работы в стол. Если не отчаиваться - то точно получится. Если вы тупы как пробка, будет сложно, возможно стоит еще поучиться.

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

Небольшая ремарка: на джуна собеседовался сеньор, скрывший реальный опыт работы, в остальном - не пытавшийся выглядеть джуном.

В общем-то я бы скидывал этот текст всем желающим сейчас вкатиться в IT, опыт крайне познавательный.

Совершил третий подход к библиотеке Quartz - инструменту для управления фоновыми задачами в шарповом сервисе. И таки познал его дзен. Первый раз я смотрел его джуном. У меня закипели мозги и я в ужасе закрыл его. Второй раз я уже был мидддом. Подумал: прикольно, но избыточно. И вот третий подход.

Предположим у нас есть сервис. Раз в секунду он совершает какой-то запрос. Повесили вечный цикл/таймер и живём дальше.

Спустя какое-то время нам потребовалось делать серию запросов куда-то раз в 5 минут. Мы все ещё живём на таймерах.

Добавилась необходимость содержать пару локальных кешей, обновляя/чистя их по расписанию. У нас таймеры, нам ок.

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

А потом добавилась длинная и тяжёлая задача задач, которая должна запускаться в 13:13 по пятницам 13 го. Длится она около 30 минут. Мы уже очень хотим красивое управление периодами с помощью Cron, но наваяли костылей и поехали дальше.

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

Чтобы не скатываться в такое есть специализированный инструмент, упомянутый выше. Периодичность выполнения можно конфигурировать как передавая Cron - выражение, так и единицы времени/интервалы. Можно настроить приоритеты задач, общее число доступных потоков и много чего ещё.

Но больше всего мне понравилась возможность сгруппировать задачи. Задача задач помечается как относящаяся к одной группе с теми, с кем совместно она кладет внешний сервис. И вот, в час Х она просто говорит одной строкой своей группе: поспите, пока я работаю. И они просто спят. А когда она оканчивает свою работу ещё одной строкой говорит: проснитесь!

Кроме Quartz есть ещё библиотека Hangfire, но мне она пока кажется избыточной, как Quartz когда-то:)

#кодинг
#csharp

Сегодня плотно познакомился с картографическим сервисом HereMaps.

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

Открыл документацию - все описано просто превосходно, снабжено примерами и комментариями. Довольно странный личный кабинет с системой выдачи ключей доступа к запросам, но я видел и не такое. И тут началось развлечение: оказалось, что новым пользователям не дают использовать хорошо документированную версию апи 7.2, только 8+.

А документации по ней... Тупо нет, только какие-то обрывочные примеры. И changelog, что изменилось при переходе с прошлой версии.

А изменилось многое, в запросе изохронов - и запросы и ответы. Вместо массива с парами координат - строка-абракадабра. И ни в changelog-е, ни в примерах не написано, а что это собственно за формат кодирования?

Base64? Нет. Wkt? Нет. Google encoded polyline? Хм, Бранденбургские ворота у нас находятся на 900й широте? Наверное всё-таки нет.

Спасибо доброму человеку, навёл на репозиторий HereMaps на гитхабе, где выложены кусочки кода, которые можно скопипастить себе в проект и которые декодируют строку в нечто человекочитаемое. Называется эта пакость flexible-polyline и является немного измененным алгоритмом Google encoded polyline.

В целом, подход красивый, объем исходящего трафика жмет неплохо и удобен для хранения изохронов в базе. Не хватило всего двух вещей: упоминания об этом формате в документации и пакета с готовым декодером вместо копипасты с репозитория.

#кодинг

Читаю я Рихтера, никого не трогаю. И тут мне открываются новые колдунства в организации межпоточного взаимодействия в c#, о котором я вообще не слышал, а в коде, даже в самом дремучем легаси, никогда не видел. Ключевое слово volatile, Volatile Read и Volatile Write. Дожили.

Пока до конца не осознал что это за звери и нужны ли они мне современном c#, но очень интересно открывать для себя что-то новое.

#Рихтер
#книги

Наткнулся на очень интересный инструмент для махинаций с кодом на c# на стадии пост-компиляции: fody.

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

#кодинг
#csharp

Я ранее пару раз упоминал систему сбора метрик Prometheus. Суть ее использования простая: на этапе написания приложения мы используем достаточно простые инструменты и развешиваем метрики вида:

1. Количество и время выполнения запроса1
2. Число ошибок при выполнении запроса2, и т.д.

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

Для обработки данных предусмотрено некоторое количество штатных функций: производная с указанием временного окна, разные варианты суммирования, логарифмы и т.д. Все это добро описывается на достаточно простом языке запросов - PromQL.

Столкнулся на неделе с интересной проблемой: надо было наладить сбор метрик с произвольного числа сервисов (100-200-300), раскиданных по произвольным местам в интернете. Сервисы оживают и умирают в своем ритме.

Обычно Prometheus сам ходит по сервисам и "скреппит" с них метрики. В данном случае такое невозможно. Но на помощь приходит push-gateway: рядом с прометеусом ставится ещё один сервис из экосистемы (в докере), куда все сервисы принудительно отправляют метрики. А прометеус уже сам опрашивает этот сервис.

Отдельно отличное впечатление произвела Graphana - средство для построения графиков и рисования дашбордов.

Указываешь ей: прометеус - там. И при создании графика она сразу на выбор предлагает выбрать одну из его метрик. Больше всего понравился визуальный конструктор запроса на PromQL, с помощью которого формируются данные для графика. Оно и так просто, а с конструктором запросов все низводится до уровня "для дебилов".

Я долгое время хотел сделать сложное преобразование с многокомпонентной метрикой (состоящей из нескольких временных рядов). Несколько раз подступался, но углубляться в недра PromQL и читать доки было лень. В итоге, в графановском конструкторе я нашаманил нужное преобразование за 5 минут.

В целом, экосистема Prometheus производит крайне приятное впечатление, рекомендую всем. Кроме сбора самопальных метрик, можно собирать метрики компонентов инфраструктуры: баз данных, брокеров сообщений. А ещё есть экспортёры системных параметров (CPU, RAM, диск). А в качестве вишенки на торте в экосистеме Prometheus есть система сбора и агрегации логов - loki, знакомство с ней меня ожидает в будущем.

P.S. И Prometheus, и Graphana, и push-gateway ставятся через docker-compose с помощью банальной копипасты из примеров, без включения мозга.

Kafka vs RabbitMQ, часть 1. Описание эксперимента.

Проводил интересный эксперимент: сравнивал между собой брокеры сообщений: Apache Kafka и RabbitMQ под нагрузкой на сообщениях разного размера. В этом посте - описание условий эксперимента, результаты - далее по тегу #kafkavsrabbitmq

Оба брокера брал as-Service, то есть администрирование берет на себя хозяин облака. Под капотом RabbitMQ as Service - 1 инстанс, под капотом Kafka as Service - кластер из 9 .

На 12 серверах раскидал клиентские сервисы: по 70 генераторов данных (Producer) и по 200 потребителей (Consumer). Producer-ы в один поток последовательно генерируют сообщение (массив случайных байт заданного размера), отправляют его в брокер и ждут заданное время до отправки следующего сообщения. Consumer-ы в один поток читают. Режим чтения в Kafka - latest, то есть топики вычитываются не сначала. Сделал центральный сервис конфигурации, куда скидываются POST-запросом настройки сервисов: адреса брокеров и текущие настройки эксперимента - размеры сообщения и задержка после успешной отправки сообщения для регулировки нагрузки. Сервисы раз в некоторое время (от 15 до 30 секунд) ходят за свежей конфигурацией, и, если она поменялась - перенастраиваются.

Данные распределяются по 120 "обменным точкам" - Exchange в RabbitMQ, Topic в Kafka. Доставляются в среднем по 3 раза, везде стоит автоматическое подтверждение получения сообщения Consumer-ом.

Со всех сервисов собирается ряд метрик:

- Сообщений отправлено
- Сообщений получено
- Байт отправлено
- Байт получено
- Время отправки сообщения
- Число ошибок при отправке
- Число ошибок при получении

Бомбил сообщениями следующих размеров:

- 150 байт
- 5Кб
- 100Кб

Для сбора и визуализации метрик использовалась связка prometheus-push-gateway, Prometheus и Graphana. Сервисам известен адрес push-gateway, они сами туда сбрасывают метрики, prometheus их вычитывает.

В общем, получил лвлап и кучу экспириенса: зверинец из 550 сервисов я ещё не пас.

#rabbitmq
#kafka

Kafka vs RabbitMQ, часть 2. Результаты измерений.

Измерялась сферическая производительность брокера в ваккуме, под конкретную задачу (под NDA).

В качестве измеряемой величины я использовал максимальное количество сообщений в секунду, которое брокер способен разослать сразу, не накапливая их в себе. Ниже приведены получившиеся лимиты для разных размеров сообщения, единица измерения - сообщений/с

Размер сообщения: 150 байт
Kafka - 3000
RabbitMQ - 5000

Размер сообщения: 5 Кб
Kafka - 1100
RabbitMQ - 3600

Размер сообщения: 100 Кб
Kafka - 580
RabbitMq - 1000

#rabbitmq
#kafka
#kafkavsrabbitmq

Kafka vs RabbitMQ, часть 3. Некоторые впечатления и наблюдения по результатам эксперимента.

1. На практике для себя подтвердил вывод из прочитанного ранее.
2. В отличие от RabbitMQ, для Kafka, даже as-Service всеравно нужен опытный, знающий человек который умеет готовить именно её.
3. При экспоненциальном росте нагрузки Kafka урезает отдачу, а RabbitMQ - прием сообщений.
4. Kafka подключает нового клиента довольно долго. При подключении потребителя в момент, когда Kafka находится в режиме приёма "цунами" сообщений, на клиента по началу вываливается целая куча сообщений, а потом поток урезается до общего уровня.
5. Расстановка метрик вообще, и Prometheus в частности - огонь. Не так много дополнительных приседаний и из нескольких дашбордов понятно происходящее в 550 микросервисах. Prometheus с push-gateway на прием очень экономичны по оперативной памяти (съедали не больше 4-5 Гб), но требовательны к CPU: съедалось на постоянной основе 30+% от 8 ядер сервера.

#rabbitmq
#kafka
#kafkavsrabbitmq

Сегодня продолжил трогать экосистему Prometheus.

Наконец дошли руки до системы сбора логов - Loki. Вообще, при развертывании "по фен-шую" между сервисами, генерирующими логи и Loki должна использоваться прокладка - Promtail. Promtail осуществляет сбор, анализ, агрегацию и ротацию логов, после чего укладывает их в Loki. Визуализация осуществляется, как и в случае с Prometheus с помощью Graphana.

Но я немного схалтурил и настроил прямую запись из приложения в Loki. Заводится все с ходу, на дефолтных официальных докер образах.

Для централизованной системы анализа логов важно построение поисковых индексов по логам, чтобы из безумного потока отбирать только важное. В ELK стеке индексы конфигурируются из UI при рисовании дашбордов.

В Loki в моей конфигурации об индексировании приходится думать на этапе разработки приложения: надо заложить в сообщения логов метки (например текст {errorType42}), и сообщить отправителю, что их надо индексировать.

А затем, в окне просмотра логов в любой момент можно быстро найти все errorType42 за определенный период времени. И с этой выдачей уже работать другими встроенными инструментами.

#prometheus

На неделе познал дзен DDD - domain driven design - подхода к проектированию ПО. Основная суть - разделение мух и котлет - бизнес логики (domain), технического кода по трансформации данных при движении по приложению (application) и взаимодействия с внешним миром (infrastructure).

Раньше во всех моих проектах был сильный перекос: в одном случае 90% проекта приходилось на domain, в другом - infrastructure с примесью application.

Сейчас мне повезло с проектом, где представлены все слои в равной мере и можно поупражняться в правильной архитектуре.

В общем-то самое главное, что даёт "познание дзена DDD" в моем случае - не запоминание догматики правильного построения приложения, а возможность осознанно посмотреть на задачу с новой точки зрения.

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

Система непрерывной поставки/развертывания с гитлабом выглядит примерно так: есть центральная машина на которой стоит гитлаб. На той же или на соседних машинах установлены Gitlab Runner-ы, выполняющие команды гитлаба.

Вариантов использования Runner-ов масса, я пока остановился на самом простом: выполнение последователльности консольных команд, забитых в скрипте CI/CD.

При коммите Runner, отвечающий за сборку образов, собирает новый образ и сохраняет его в хранилище. Если сборка и сохранение прошли успешно - в дело вступает второй Runner, на машине, где собственно крутится проект. Вытягивает последнюю версию, гасит старый контейнер, запускает новый из нового образа.

Изучать гитлаб можно бесконечно, он неисчерпаем, как электрон, но теперь мне хватает навыков для построения CI/CD на относительно небольшое хозяйство.

#devops
#gitlab

Sphagnum. Часть 1. Начало.
#sphagnum@eshu_coding

Начинаю новый пет-проект: свой брокер сообщений. Обозвал я его пока Sphagnum, проект планируется в качестве чисто образовательного, под лицензией MIT. Что я хочу получить на выходе:
1. По основному функционалу - клон RabbitMQ, возможно несколько урезанный.
2. Возможность встраивать брокер в другие приложения на .net для организации доступа к проходящим через брокер данным и уменьшению накладных расходов на передачу данных по сети.
3. Очень хочется кафкоподобное горизонтальное масштабирование.
4. Очень хочется возможность сохранения истории прошедших через брокер данных с вычиткой их с произвольного момента.
5. Очень хочется сделать шажочек в сторону работы с динамическими ip некоторых интстансов в системе.

В дальнейшем всё связанное с проектом будет публиковаться под тегами #sphagnum@eshu_coding или #sphagnum. В ближайшее время я буду читать всякое на смежные темы и выкладывать разные теоретические заметки. Код будет ориентировочно зимой.

Пока видится несколько этапов:
1. Отработка основных шаманств по передаче данных, скорее всего поверх сокетов.
2. Реализация хранения данных, думаю надо уметь как NATS - и на диск в самопальные файлики и в базу данных.
3. Админка, видимо в двух вариациях: через rest api и что-то интерактивное, с ui, на базе blazor как вариант.
4. Тесты и оптимизации, оптимизации и тесты. Если удастся догнать RabbitMQ - это будет отличным результатом.
5. Выкатывание проекта в открытый доступ: nuget пакет для установки, несколько образов на docker hub, клиентские библиотеки для основных языков программирования - c#, java, js, python, golang

#проекты

Sphagnum. Часть 2. Зачем, а главное нафига?
#sphagnum@eshu_coding

1. Саморазвитие. Читать умные книги это очень познавательно, но намного лучше я усваиваю информацию, когда решаю какую-то задачу, интересную мне. А тут ожидается и изучение существующих архитектурных решений, и выдавливание максимума производительности из c# кода.

2. Для встраиваемого брокера сообщений в экосистеме .Net вполне найдется место. Я вижу как минимум две ниши:
a) Организация сетевого взаимодействия в геймдеве на Unity или в мобильной разработке с использованием MAUI.

b) Онлайн анализ протекающих через брокер данных: например поиск ключевых слов в потоке логов/текстов, которые отправляются на архивирование. Можно конечно ответвить поток данных на отдельного потребителя, осуществляющего анализ. Но в случае цунами из данных, анализ может произойти слишком поздно. А со встроенным брокером - просто скопировать данные (или вообще ссылку на них) внутри процесса. Если бы я запускал #палантир@eshu_coding сейчас, я бы точно не отказался от такого инструмента.

Послушал открытый урок Otus по некоторым особенностям оптимизации работы кластеров PostgreSQL. В целом, получилось очень познавательно: некоторые из услышанных вещей, упомянутых лишь краем, вызвали реакцию "хм, а так было можно?"

Вот перечень запомнившихся моментов:
1. Оптимизация скорости работы базы данных за счёт разнесения разных таблиц по разным дискам с помощью указания табличных пространств (tablespace). Я про что-то подобное мельком читал во время работы над Палантиром #палантир@eshu_coding, но воспринимал эти махинации исключительно с т.з. размещения большой базы, не влезающей на диск.

2. Оптимизация путем указания стоимости операции одиночного чтения с произвольного места диска. С классических hdd намного быстрее читать последовательно записанные данные. Потому в случае соотношения размера таблицы к размеру индекса 4 к 1 читать с hdd всю таблицу может быть быстрее, чем сканировать индекс и брать нужное из таблицы. А вот на SSD такой разницы нет, и выставив параметр конфигурации random_page_cost=1 мы ощутимо ускорим чтение данных.

3. Махинации с типом репликации. В случае, когда производительность на запись/изменение совсем поджимает, можно пожертвовать надёжностью реплицирования, но выиграть до порядка по быстродействию, переключив репликацию с синхронной на асинхронную. А ещё можно делать реплику, на которую изменения с мастера будут применяться с установленной задержкой, например - час. И в случае катастрофы, например - удаления базы целиком, будет какое-то время оживить систему с меньшими потерями, чем из вчерашнего бэкапа.

4. Узнал про возможность конкуррентного переиндексирования. Предположим, индекс раздулся и начал тупить и есть много места. Можно его удалить и перестроить с нуля. Но "на живую" это приведет к большим проблемам. А оказывается можно запустить фоновое переиндексирование.

5. Узнал, что в постгрес таки есть механизм подсказок планировщику запросов, что ему делать. Для этого нужно расширение pg_hint_plan.

6. Услышал оговорку "обычно балансировку запросов между мастером и репликами у нас делают сами приложения". А так было можно?! Полез читать - оказывается, у стандартного шарпового коннектора Npgsql и балансировщик и координатор выборов нового мастера в случае сбоя есть под капотом.

Курс я конечно покупать не буду, но за 1.5 часа времени информация получена очень полезная.

#postgresql

Когда я занес ногу в пятый раз, уже на другом проекте на другой работе - я попустился и таки сел писать генератор тестовых данных.

Дочитал Рихтера до типов перечислений (enum) и наткнулся на дополнительное направление их применения, которое я многократно использовал в чужих библиотеках, но ни разу не задавался вопросом, что там под капотом?

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

А тут я осознал, что можно использовать enum как битовые флаги, дополняя битовые операции человекочитаемостью! Достаточно пометить свой enum атрибутом [Flags] и можно развлекаться с байтиками, не отправляя читателя кода в недра клинописи вида 0x5A3 | 0x5A4. Отличный пример приведен мы официальной доке от MS:

[Flags]
public enum Days
{
None = 0b_0000_0000,
Mon = 0b_0000_0001,
Tue = 0b_0000_0010,
Wed = 0b_0000_0100,
Thu = 0b_0000_1000,
Fri = 0b_0001_0000,
Sat = 0b_0010_0000,
Sun = 0b_0100_0000,
Weekend = Sat | Sun
}

Помнил бы я об этих махинациях год назад - поэкономил бы байтиков от души.

#Рихтер
#книги

P.S. Другой вариант записи enum-а из примера:

[Flags]
public enum Days
{
None = 0,
Mon = 1,
Tue = 2,
Wed = 4,
Thu = 8,
Fri = 16,
Sat = 32,
Sun = 64,
Weekend = Sat | Sun
}

На прошлых выходных был на конференции по экосистеме .Net, к которой относится мой основной язык - c#: DotNext.

В первый день прослушал 4 доклада, во второй - 5.

Далее будет серия постов по прослушанным докладам, с тегом #dotnext@eshu_coding

#conf