Всем привет!

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

Расскажу немного о себе:
➡️мне 26 лет
➡️закончил университет им.Баумана, факультет Информационного Управления с красным дипломом
➡️проф.погружение в IT началось с 1.5 годового курса от Mail.Ru “Технопарк”
➡️в IT работаю с 2019г.
➡️ex. Golang-разработчик
➡️уже 3 года как TeamLead
➡️выпустил 4 потока обучения Go разработчиков в Ozon Школе “Route256”: прошел путь от тьютор до декана школы
➡️приглашенный спикер подкаста Reg.ru ▶️
➡️учасник golang meetup-а ▶️
➡️"человек который творил эту эпоху и сам стал эпохой" (ну вы поняли😉)


На данный момент являюсь Teamlead-ом команды DBaaS ScyllaDB в Ozon Tech в департаменте платформы.
До этого 2 года был руководителем команды в Логистике Ozon, а еще до этого - golang разработчиком в этой же команде. К слову, в этой команде мне приходилось проектировать сервисы, способные держать более 450k запросов пользователей в секунду. Highload-а было много.

Помимо разработки я также делился своей экспертизой в школе Route256 (школа от Ozon для разработчиков уровня middle). Сначала был тьютором, проверял домашние задания и консультировал учеников, далее был преподавателем и лектором, а после дошел до позиции декана в Route256.

Здесь в канале я планирую продолжать делиться своей экспертизой, а также выносить какие-то важные темы для обсуждения, советовать полезные, на мой взгляд, материалы и просто публиковать своими мысли 📢

Добро пожаловать!👋

🚀КАК С НУЛЯ РАЗРАБОТАТЬ МИКРОСЕРВИСЫ, КАК В BIGTECH?

📆 Уже сегодня в 18:00 по МСК я проведу бесплатный открытый урок по микросервисам!

🎥Трансляция будет доступна по этой ссылке.

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

Когда меня спрашивают, почему я выбрал 👩‍💻 в качестве языка разработки.

Я просто выбрал быть более продуктивным разработчиком⚡️

А вообще мой первый язык разработки 👩‍💻 и я 2 года на нем разрабатывал и он мне очень понравился, но как говорится, лучше больше, чем меньше.

📣 Вчера состоялся открытый урок по микросервисам! Спасибо всем, кто подключился, надеюсь вам понравилось!

📹Как и обещал, запись открытого урока уже доступна по ссылке.

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

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

👩‍💻 Язык Go не стал исключением и я подробно погрузился в его устройство. Что я узнал:
🟠Go написан на go - да, как бы странно это не звучало, но всем, чем мы пользуемся в go, написано на нем же, все исходные файлы открыты и их можно изучать.
🟠Go не просто язык программирования, go - это целая экосистема!
🟠Основные 3 кита, делающих go таким, каким мы его знаем: планировщик, сборщик мусора и устройство памяти, и netpoller.

У меня ушло немало времени, чтобы разобраться во всех тонкостях устройства данного языка. По итогу я собрал самые лучшие материалы раскрывающие подробно все нюансы Go и решил поделиться ими с вами в своем репозитории: https://github.com/moguchev/golang. Периодически я актуализирую данный список источников, добавляю новые статьи, видео и новые темы, поэтому советую добавить в избранное🌟

А какие технологии хорошо знаете вы?

#go

‼️ЗАДАЧА О ДВУХ ГЕНЕРАЛАХ. ЧАСТЬ 1.

Зачем я спрашиваю на собеседовании у Senior разработчиков задачу о 2-ух генералах?

Давайте начнем с самой задачи:

Две армии, каждая руководимая своим генералом, готовятся к штурму города. Лагеря этих армий располагаются на двух холмах, разделённых долиной. Единственным способом связи между генералами является отправка посыльных с сообщениями через долину. Но долина занята противником и любой из посыльных может быть перехвачен. Проблема заключается в том, что, генералы заранее (пока была связь) приняли принципиальное решение о штурме, но не согласовали точное время штурма.
Для успешного штурма генералы должны атаковать город одновременно. Штурм, предпринятый только одной армией, приведёт к катастрофическим последствиям для атакующих (фактически к поражению).
Требуется найти алгоритм обмена сообщениями, после которого каждый генерал был бы уверен, что они оба атакуют в указанное время.

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

ПРИЧЕМ ЗДЕСЬ РАЗРАБОТКА? Все просто: в большинстве микросервисных системах так или иначе используются брокеры сообщений (тот самый посыльный). Когда два сервиса обмениваются асинхронно сообщениями, они как 2 генерала на двух холмах, не знают дошло ли сообщение или нет.

‼ЗАДАЧА О ДВУХ ГЕНЕРАЛАХ. ЧАСТЬ 1.

Конечно технологии идут вперед и брокеры сообщений пытаются обеспечить надежную доставку сообщений, но нет 100% гарантии. Поэтому при работе с брокерами сообщений очень важно понимать следующие семантики:

➡️ at least once («хотя бы один раз») - если мы не получили подтверждение от «посыльного», мы можем отправить еще одного через какое-то время. В чем тут проблема: получатель может получить оба этих письма, и хорошо если в них одинаковые сообщения, а если разные?)
➡️ at most once («не более одного раза») - если мы не получили подтверждение от «посыльного», мы ничего повторно не отправляем, дабы избежать путаницы в сообщениях у получателя. Тут проблема, что часть посланий получатель может не получить, а это может оказаться критичным для ряда случаев (например при штурме замка, или если вы отправляете событие в логистику о создании заказа)
➡️ exactly once («строго однократная доставка») - то чего, как мы поняли из задачи, добиться очень тяжело. Если мы отправим несколько посыльных, получатель должен получить только одно письмо. Чаще всего это достигается с помощью специальной «пометки» на письме - ключа идемпотентности. Получатель (или коллективный разум посыльных, если такой бы был) по этой метке понимает, является ли данное сообщение дубликатом уже прочитанного сообщения или нет, и игнорирует его.

Одним из инструментов, позволяющим реализовать любую из данных семантик, является Apache Kafka. Это довольно гибкий и производительный брокер сообщений. Но за счет его гибкости на разработчика возлагается БОЛЬШАЯ ответственность при разработке системы: от выбора семантики обмена сообщениями, до выставления необходимых настроек на клиенте и брокере. Поэтому, я считаю, что понимание данных основ обязательно для Senior разработчиков.
__________________________

❓А каких еще брокеров сообщений вы знаете, и какие семантики они способны обеспечить?