🚀КАК С НУЛЯ РАЗРАБОТАТЬ МИКРОСЕРВИСЫ, КАК В 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 разработчиков.
__________________________

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

👩‍💻 ВНУТРЕННЕЕ УСТРОЙСТВО ПЛАНИРОВЩИКА GO!

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

📆 23 апреля в 19:00 по МСК мой коллега по цеху, Владимир Балун, проведет бесплатный открытый урок по внутреннему устройству планировщика Go.

Если вы давно хотели разобраться как устроен Go под капотом — это отличная возможность! В программе открытого урока множество тем, которые обычно любят задавать на собеседовании.
Не пропустите такую возможность, регистрируйтесь на открытый урок!

Регистрация доступна по ссылке.

📌 Частый вопрос на собеседование про SQL: последовательность выполнения SQL команд.

Обратите внимание, что LIMIT и OFFSET выполняются в самом конце. Т.е если вы делаете пагинацию через LIMIT+OFFSET, то БД будет проделывать всю выборку и только потом ограничивать выдачу запроса.

На эту тему есть хорошая статья про пагинацию в PostgreSQL.

👩‍💻 PostgreSQL - СОВЕТЫ ПО ЭФФЕКТИВНОЙ РАБОТЕ.
ЧАСТЬ 1.

PostgreSQL - в настоящая время одна из самых популярных СУБД на рынке. Все компании и разработчики любят Posgtres за его надежность, производительность, поддержку ACID транзакций и многое другое. Я бы сказал что PostgreSQL - это швейцарский нож в кармане любого уважающего себя backend-разработчика.

PostgreSQL - тот инструмент, который легко внедрить и использовать в production решениях. Но с ростом проекта и нагрузок на первый взгляд может показаться, что производительности PostgreSQL уже не хватает. На самом деле это не всегда так. И вот верные способы выжать ПО МАКСИМУМ из этого прекрасного слоника:

1️⃣CONNECTION POOLER

ОБЯЗАТЕЛЬНО используйте пуллер соединений. Для чего он нужен? Когда у вас много инстансов вашего приложения, становится очень сложно контролировать количество соедиенеий к Postgres, а на каждое соединение СУБД тратит не мало ресурсов на их обслуживание. Пуллеры соединения решают эту проблемлему: они становятся прокси серверами между вашим приложением и БД и контролируют заданное число соединений, да еще и утилизируют из по максимум. github.com/yandex/odyssey - один из самых лучших пуллеров соедиеней на сегодняшний день.

2️⃣НИКАКОЙ БИЗНЕС ЛОГИКИ В БД

Откажитесь от триггеров, хранимых процедур, внешних ключей, лишних и жестких сonstraint-ов, которые лишний раз валидируют то, что должно валидировать ваше приложение! В 2024 году ваше приложение должно заботиться о валидности и консистетности данных. БД - просто инструмент для хранения и получения данных. Помните: приложение масштабировать (скейлить) сильно проще, чем вычислительные ресурсы БД.

3️⃣ИЗБЕГАЙТЕ ШИРОКИХ ТАБЛИЦ

Если в вашей таблице 40+ колонок, вы что-то явно делаете не так. Дело все в том, что Postgres хранит записи таблицы в файлах по строчно друг за другом, и когда вы делаете обновление строк, на самом деле это запись новой версии строки, и, если обновляете 2-3 поля, остальные ваши поля кочуют баластом. PostgreSQL на много лучше управляет относительно небольшими строками, а если они еще и фиксированной длинны, тогда место на дисках и в кеше экономится значительно больше. Также лучше все колонки переменной длинны располагать в конце таблицы.

4️⃣ИЗБЕГАЙТЕ ТАБЛИЦ С ГИГАНТСКИМ КОЛИЧЕСТВОМ СТРОЧЕК

Тут все просто - чем больше записей в таблице - тем больше размер индекса. Чем больше размер индекса - тем больше файлов индекса требуется прочитать БД. Если индекс весит несколько гигабайт, он не умещается в оперативной памяти Postgres и тогда происходит уже чтение с диска, а это довольно медленная операция. Но как быть если записей и правда много и нам все их надо хранить? Ответ кроется в следующем пункте.

👩‍💻 PostgreSQL - СОВЕТЫ ПО ЭФФЕКТИВНОЙ РАБОТЕ.
ЧАСТЬ 2.

5️⃣РАЗДЕЛЯЙ И ВЛАСТВУЙ

При проектировании схемы БД и модели данных сразу прогнозируйте объем данных через год-два. Если вы понимаете, что число записей сильно переваливает за миллион, стоит задумать о том по какому принципу стоит делить эти данные. Например, если у вас интернет магазин и вы храните записи о заказа клиента, скорее всего заказы сделанные давно вам редко будут нужны. В этом случае поможет партиционирование таблицы по временному интервалу (в данном случае ключ партиционирования - время создания заказа). Postgres будет иметь набор условно маленьких табличек, каждая из которых содержит свои маленькие индексы. в 90% случаях вы будете работать со свежими заказами, и все запросы будут идти в последние партиции, которые уже полностью могут помещаться в кеш Postgres. Вы можете выбрать ключом партиционирования что угодно, главное, чтобы партиции были +- одного размера и обращения происходили к минимальному их количеству.

6️⃣RAM - НАШЕ ВСЁ

Берегите оперативную память Postgres. Не бойтесь накидывать больше оперативной памяти кешу Postgres - чем больше он, тем больше данных там поместится, и тем меньше будет чтений с диска, и, соотвественно, меньше задержек. Но оперативная память нужна не только кешу, она нудна также для обработки запросов приложения. Следите за потреблением памяти вашими запросами, старайтесь доставать как можно меньше данных из БД. По максимум фильтруйте записи, где это возможно. Не делайте 10 JOIN-ов ради того, чтобы обогатить ответ парочкой полей, которые могли бы хорошо закешироваться в вашем приложении.

7️⃣ДЕНОРМАЛИЗАЦИЯ ДАННЫХ

3-я нормальная форма - это конечно хорошо, но если 90% запросов в БД - это чтение с постоянными одними и теме же JOIN-ами, то стоит задуматься о денормализации данных. Денормализованные данные сложнее обновлять, но довольно просто получать по одному ключу.

8️⃣ДОЛГИЕ ТРАНЗАКЦИИ - ЗЛО

Любая транзакция несет много накладных расходов, а долгоживущая транзакция - это ноша, которая тяжелеет с каждой новой параллельно выполненной транзакцией. Долгая транзакция также не позволяет пуллеру переиспользовать соединение с БД для других запросов. Также не стоить делать большое число изменений/удалений в рамках одной транзакции, это может вызвать bloat.
Маленькие быстрые транзакции лучше себя ведут.

9️⃣МАСШТАБИРОВАНИЕ

Postgres можно мастшабировать двумя способами:

1. За счет добавления реплик и чтения из них. В этом случае не стоит использовать мастер только на запись, так как Postgres собирает статистику использования данных только с мастера. Эта статистика очень хорошо помогает при планировании исполнения запросов. При чтении с мастера эта статистика попадет в реплики и они начнут более эффективно строить планы запросов.
2. За счет шардирования. Тут все просто, вы разделяете ваши данные по разным инстансам и контролируете где какие лежат. К сожалению из коробки PostgreSQL не умеет шардировать данные и вам скорее всего придется использовать сторонние решения.

🔟 МОНИТОРИНГ

Ну и последний совет: собирайте статистику и метрики, которые предоставляет Postgres. Обеспечьте мониторинг вашей БД 24/7 и своевременно находите узкие места. Анализируйте запросы. Не увлекайтесь ненужными индексами, они не всегда ускоряют запросы. Создавайте индексы под определенные частые запросы.

Вот и прошли майские праздники 📆

Давно не ходил на конференции, да и некогда особо...
Наткнулся на онлайн конференцию по любимому 👩‍💻 - Podlodka Go Crew (кстати, темы там не только по Go). Взял себе билет🎫Конференция идет всю неделю по 2 доклада в день.

Решил, что буду всю неделю делиться своим мнением по докладам тут. Вы тоже можете в комментариях делиться свои мнением)

Сегодня уже было два доклада:
1. «SQLite как основная база данных» / Никита Галушко (ВКонтакте)
2. «Мокирование vs предзаполнение базы данных» / Павел Вирский (Озон Банк), Глеб Карпушкин (Ozon Fintech)!

Естественно онлайн я пропустил, приходится ночью досматривать записи)

По первому докладу могу сказать, что идея использовать в простых системах SQLite может быть оправдана. Но на мой взгляд, если поддержка инфраструктуры (IaaS, DBaaS) в компании автоматизирована и на высоком уровне (как например в Ozon), то проще развернуть маленький Postgres по клику кнопки, чем потом с SQLite слезать при масштабировании сервиса.

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

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

Ну и в общем-то я понял, что задачи разработчика глобально можно разделить на 3 типа:

1️⃣Разработка новых решений с нуля (ресерч)

Это то, о чем мечтают многие разработчики и спрашивают на собеседованиях у работодателя. Конечно, в разработке с нуля есть ряд плюсов:
✅не надо разбираться в чужом коде,
✅можешь спроектировать космолет по всем правила и канонам сам
✅и вообще применить все свои наработки, подходы и т. д.
Но также есть и минусы таких задач: очень много вопросов о конечном продукте (чаще всего новые проекты - это какие-то MVP, которые не всегда понятно как будут расширяться потом и куда пойдут).
Можно уйти в долгую полемику выбора архитектуры, проработки API, схемы БД (ведь хочется сразу все сделать универсально и на века!). Также вы можете столкнуться с проблемой, которую никто до вас еще не решал, и это может стать настоящим rocket since (но есть и те, кого это драйвит).

2️⃣Поддержка и развитие существующего проекта, технологии

Вообще таких задач, как правило, больше остальных.
➕Из плюсов: уже есть устоявшаяся архитектура, подходы и технологии. Могут попасться изящные примеры и подходы в коде, на которых можно всегда научиться и поднять свою экспертизу.
🌟Из минусов: как правило, требуется не мало умственных усилий на погружение в проект, уменьшается гибкость разработки новых фич. Иногда приходится ломать голову, как не сломать все и при добавлении новой функциональности (тут требуется скилл ювелирного внедрения).

3️⃣Поддержка легаси

Легаси - это что-то старое, страшное, запутанное, мало освещенное, но худо-бедно работающее решение.
Ночной кошмар для большинства разработчиков: ты пришел в новую IT компанию, чтобы разрабатывать новые крутые проекты, а тебе дают ЭТО... И вот 3 бессонные ночи ты отлаживаешь код, чтобы понять, что тут вообще происходит и что автор кода пытался донести.
Но и в таких задачах можно найти жилу радости и успеха: переписывание легаси! Если сделать его качественно, быстро, да еще если это закроет существующие проблемы... Оооо, вам обеспечено место на доске почета в компании, такое точно запомнят!

Самое смешное, что как только надоедает один тип задач, хочется другой. Но и он тоже надоест, и так по кругу... Одна из причин ухода разработчика в другую команду/компанию, как правило, становится как раз "однообразие задач".

Если всегда давать задачи на ресерч или создание с 0 космолетов, разработчик просто выгорает. Если давать задачи на развитие сервиса - рано или поздно развитие проекта может затормозиться. Такое бывает, когда кардинально новых идей нет и все задачи сводятся к точечному улучшению функционала. Это быстро надоест, так как нет особо развития новых компеценций у разработчика. Ну и легаси: поддержка легаси приемлема, когда это временная мера, пока не появится что-то новое и лучше. Если продолжать трогать и расширять легаси код, то скорее всего к вам в команду потом никто не придет.

📌В общем, совет руководителям: следите за разнообразием задач у разработчиков.
Разработчики - не бойтесь просить у лидов смену характера задач, когда понимаете, что уже начинает надоедать. Уйти всегда можно)

❔А какой тип задач сейчас у вас на данный момент?

👨‍💻Junior Go разработчик:

for i := range jobs {
    job()
}

👨‍💻Middle Go разработчик:

var wg sync.WaitGroup
for i := range jobs {
    wg.Add(1)
    go func(job jobType) {
        defer wg.Done()
        job()
    }(jobs[i])
}
wg.Wait()

👨‍💻Senior Go разработчик:

var workersNum = runtime.NumCPU()

var (
    wg sync.WaitGroup
    in = make(chan jobType, workersNum)
)
for i := 0; i < workersNum; i++ {
     wg.Add(1)
     go func() {
         defer wg.Done()
         for job := range in {
             job()
         }
     }()
}

for i := range jobs {
    in <- jobs[i]
}
close(in)
wg.Wait()

🧠Lead Go разработчик:

import "github.com/sourcegraph/conc/iter"


iterator := iter.Iterator[jobType]{MaxGoroutines: runtime.NumCPU()}

iterator.ForEach(jobs, func(job jobType) {
   job()
})

Да, асинхронность в 👩‍💻 довольно изящна и проста (если сравнивать с другими языками). Но все же она требует от разработчика внимательности и хорошего знания языка. А в случае ошибки вам будет обеспечена утечка памяти или deadlock.

Что отличает ведущего (Lead) разработчика от других? Он пишет эффективные решения довольно быстро, а главное эти решения надежные и, в идеале, изящны. Часто это достигается путем использования проверенных инструментов.

Одним из таких инструментов - github.com/sourcegraph/concНа мой взгляд это то, чего не хватает в стандартной библиотеке Go. Максимально изящная асинхронность, спрятанная за синтаксическим сахаром. С этой библиотекой шансов словить утечку памяти резко уменьшаются, а скорость проведения код ревью увеличивается.

Делайте вещи проще! (KISS)

УБИЙЦА GO И RUST?

Пока 👩‍💻 и 👩‍💻 разработчики спорят друг с другом чей же язык круче и лучше, Marco Sampellegrini, автор книги The Simple Haskell Handbook и разработчик системы непрерывной интеграции Quad CI,
написал новый язык программирования — Borgo.

Borgo пытается быть более выразительным, чем Go, но менее сложным, чем Rust. Он комбинирует лучшие черты Go и Rust, восполняя недостатки каждого из языков. Компилятор написан на Rust. Сам язык совместим с пакетами Go (можно вызывать гошный код).

Что-ж, там есть enum :)

go:use fmt

enum NetworkState {
    Loading,
    Failed(int),
    Success(string),
}

let msg = match state {
    NetworkState.Loading => "still loading",
    NetworkState.Failed(code) => fmt.Sprintf("Got error code: %d", code),
    NetworkState.Success(res) => res,
}

Начнут ли все переходить на Borgo? Думаю, вряд ли… Пиар команда слабая и нет локомотивного комьюнити. Но мб это хороший толчок к скорому Go 2.0🤔

А вас заинтересовал Borgo?
Ставь:
🔥 - да
❤ - Go one love
😎 - пошел писать дальше на Rust

👩‍💻 Docker заблокировал доступ к своему главному репозиторию Docker Hub для пользователей из России!

Что ж... еще одна компания придерживается принципов "демократии", "свободы слова" и за справедливость во всем мире!

Docker - не первый и не последний, кто уходит из РФ или блокирует доступ:
- Redis
- Buf.build
- Swagger
- Jetbrains
- ...
Список можно продолжать бесконечно...

Холодная война в самом разгаре, что еще нам заблокируют...? Вопрос риторический. Тем не менее выход разработчики всегда найдут 😉
_________

Инструкция по восстановлению доступа к Docker Hub для пользователей из России

🔗 Читать статью
🔗 Зеркало

ЗАПИСЬ ОТКРЫТОГО УРОКА ОСНОВЫ gRPC В GO❗️

👉ссылка тут 👈

Ставь 🔥, если хочешь узнать больше о gRPC!

❗РАБОТА С PROTOBUF НА ОТРАСЛЕВОМ УРОВНЕ. ЧАСТЬ 1.

1️⃣ В любом современном языке есть средства форматирования, например prettier для 👩‍💻, gofmt для 👩‍💻 и rustfmt для 👩‍💻. К сожалению долгое время форматирования в protobuf отсутствовало на должнем уровне. И вот в CLI buf появилась функцию format, которая позволяет форматировать Protobuf файлы в соответствии с отраслевыми стандартами.

Вот пример отформатированного файла:

syntax = "proto3";

package moguchev.my.awesome.package.api.users;

import "google/api/field_behavior.proto";
import "protoc-gen-openapiv2/options/annotations.proto";
import "validate/validate.proto";

option csharp_namespace = "Moguchev.My.Awesome.Package.Api.Users";
option go_package = "github.com/moguchev/my/awesome/package/pkg/api/users;users";

// GetUsersRequest - GetUsersRequest request
message GetUsersRequest {
  option (grpc.gateway.protoc_gen_openapiv2.options.openapiv2_schema) = {
    json_schema: {
      noscript: "ListServicesRequest"
      denoscription: "ListServices request"
      required: [
        "pagination"
      ]
    }
  };
  // pagination - пагинация
  Pagination pagination = 1 [
    json_name = "pagination",
    (google.api.field_behavior) = REQUIRED,
    (validate.rules).message.required = true
  ];

  // ids - идентификаторы сервисов
  repeated uint64 ids = 2 [json_name = "id"]; // query param: ?id=1&id=2
}

Форматирует buf реально круто, но есть нюанс - нет возможности настроить правила форматирования. Разработчики buf посчитали, что отформатировать .proto файл можно лишь единственным образом. К сожалению инструмент еще не завезли в VSCode 👩‍💻 и IntelliJ 👩‍💻, но обещают в скором времени добавить. Ждем!)