Паттерны проектирования микросервисов: Как построить устойчивую систему

Здарова, бандиты! 👋 Сегодня хочу накинуть вам про паттерны проектирования микросервисов.

Когда я впервые окунулся в мир микросервисов, я подумал "какой же я тупой?!". Миновало три года и я уже точно могу сказать "какой именно я тупой"ахаха Все эти мутки с микросервисами напоминают то, как я в детстве с бабушкой пазлы собирал на 1000 штук. Сначала вообще не понятно, что к чему. Но потом на помощь приходят мама с папой и дело уже идёт хорошо. Вот такими мамой с папой для микросервисов и есть эти паттерны, про которые было в заголовке. Такие себе проверенные временем рецепты для типичных проблем.

Начнем что-ли с API Gateway. Представьте, у вас куча микросервисов, каждый со своим эндпоинтом. Без API Gateway пользователи бы сходили с ума, пытаясь добраться до каждого сервиса, ну или фронтендеры бы разбрызгали свой раф в попытках найти нужный адрес. API Gateway – это как консьерж в отеле, который управляет всеми запросами, обеспечивает безопасность и даже может кешировать ответы, чтобы всё работало быстрее.

Следующий важный паттерн – Service Discovery. В мире микросервисов сервисы появляются и исчезают, как грибы после дождя. Service Discovery помогает им находить друг друга автоматически. Это как на вечеринке, где каждый гость постоянно меняет место, а хост всегда знает, кто где сидит. Короч, чтоб не завязываться на конкретный IP мы просто юзаем сервис дискавери, а тот сам всё разыщет кого надо)

И, конечно, Circuit Breaker. Этот паттерн спасает, когда один из микросервисов начинает тупить. Circuit Breaker – это как предохранитель в электропроводке: если где-то сбой, он не даёт всей системе рухнуть. Он просто начинается дропать запросы, пока сервис не раздуплится и не будет готов к дальнейшей работе.

Эти паттерны только верхушка айсберга. Их гораздо больше, и каждый решает свою конкретную задачу.

А вы такие или подобные паттерны юзаете или всегда велосипедите в своих сервисах?

Накидывайте клубничек, если хотите прочесть про другие паттерны)

Сгонял к ребятам из Cloud.ru на подкаст:) Поговори про много что) И про гошку, и про микросервисы, и про курс и даже про проблемы женщин:)

Подключайтесь к стриму с опытной IT-рекрутеркой. Мы уже начинаем)

Планируем обсудим, как попасть в IT в 2024 году, разберем популярные стереотипы и мифы о найме в этой сфере. Думаю будет увлекательная беседа о том, как разработчики и рекрутеры видят процесс трудоустройства, с чего начать карьеру в IT и как выделиться среди конкурентов.

Залетайте на стрим и задавайте свои вопросы в прямом эфире!

https://youtube.com/live/QJnkx5bHvRI?feature=share

Скоро новый поток курса, куда хочу добавить пару новых тем: работу с Redis и Kafka. Сегодня уже успел накодить кайфовых примеров с редисом, теперь кафка на очереди, но там думаю побольше будет возни) А потом ток записать останется)

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

Шемик уже три года пишет на гошке и тоже, как и я, работает в Авито:) А вообще мы оба учились в одном классе и сидели за одной партой:) Также у него крайне интересная история жизни и тернистый путь попадания в IT, о котором можно почитать в его канале.

Хоть у Шема и хороший опыт в гошке, я перед тем, как его брать ревьювером на курс, заставил его целиком пройти курс самостоятельно😂 Чтоб он на своей шкуре почувствовал каково это ахахаха А самое главное, он весьма эмпатичный человек, который помогает советами по коду, пока не увидит, что человек понял и начал шпарить прогу дальше) Кажется это очень важно для того, кто дает тебе фидбек

А в преддверии запуска нового потока мы хотим поотвечать на ваши вопросы:) Можно про курс задавать вопросы, про го, да и в целом на общие темы) Пишите их в комменты и мы там же будет отвечать на них кружочками:)

P.S. На фотке мы показываем на свой родной город:)

🌹Rate Limiter: что, как и нафига

Го поговорим о Rate Limiter. Это штукень, которая ограничивает количество запросов к серверу за определённое время. Типа как раньше еду по карточкам давали, вот и тут та же картина с запросами к серваку. Вариков как именно ограничивать трафик много, глянем на четыре из них.

ВИДЫ АЛГОРИТМОВ

1. Fixed Window: Всё просто — допустим допускается 100 запросов в минуту. Но на границе интервалов возможны пики, и тогда сервер офигеет. Типо 99 запросов прилетит в последнюю секунду первой минуты, и в первую секунду второй минуты. В итоге за 2 секунды прилетит 198 запросов.
- Плюсы: Легко реализовать.
- Минусы: Возможны пиковые нагрузки на границах интервалов.

2. Sliding Window: Этот варик поумнее. Считает запросы в скользящем окне времени, так что пики сглаживаются, и сервер не перегревается.
- Плюсы: Сглаживает пики, равномерно распределяет нагрузку.
- Минусы: Сложнее реализовать, требует больше ресурсов.

3. Token Bucket: Это буквально ведро с токенами. Каждый запрос берёт один токен. Токены восстанавливаются со временем. Если токенов нет — запрос дропаем. Навалили в ведро 100 токенов и раз в 1/100 минуты докидываем новый токен на фоне. Если трафик летит быстрее этого темпа тут уж сорян, се ля ви.
- Плюсы: Гибкость, равномерное распределение нагрузки.
- Минусы: Может быть сложным в настройке.

4. Leaky Bucket: Ещё одно ведро, только с дыркой!)) Запросы вытекают с постоянной скоростью, а если их слишком много — всё льётся через край, и сервер рад не будет. По сути это очередь, каждый элемент которой обрабатывается через равные промежутки времени. И если очередь переполнится, то лишние запросы начинаем скипать.
- Плюсы: Предсказуемое поведение, стабильная обработка запросов.
- Минусы: Не так гибок, может отбрасывать внезапные пиковые запросы.

RATE LIMITER VS CIRCUIT BREAKER

Рейт лимитер похож ещё на один паттерн, который ограничивает трафик - сёркет брейкер. Вопрос только в чём между ними разница. Фишка в том, что Rate Limiter ограничивает количество запросов за определённое время, а Circuit Breaker предотвращает дальнейшие запросы, если предыдущие попытки завершились ошибкой.

Короче говоря, Rate Limiter юзают, чтоб предотвратить проблему с перегрузкой сервака, а Circuit Breaker, когда жопа уже наступила ахаха

Rate Limiter:
- Плюсы: Предотвращает перегрузку сервера, защищает от DDoS атак.
- Минусы: Не шарит за ошибки внутри сервиса.

Circuit Breaker:
- Плюсы: Изолирует ошибочные компоненты, предотвращает каскадные отказ системы.
- Минусы: Не предотвращает перегрузку, работает только после возникновения проблемы.

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

ПРИМЕР ТЕСТОВЫЙ, В ПРОД ТАКОЕ НЕ ТАЩИТЕ!

Писали когда-нить свой рейт лимитер или всё готовые юзали?

P.S. На фотке держим ведра с токенами😁

А какая технология вас прет больше всего?:)

Вопрос возник к вам. Мы вот каждый день чего-то там кодим и используем разные инструменты. Тут тебе и всякие протоколы а-ля http и grpc, и всякие базы типо постгреса и редиса, брокеры типо кафки, докеры, куберы и так далее)

И мне вот интересно: а какая из технологий нравится вам больше всего в плане использования? Ну чтоб вот работаешь с ней и на душе тепло)

И второй вопрос: а с какой технологией бы очень хотелось познакомится?)

P.S. Это может быть язык, инструмент, концепция и все такое

Подготовка к стриму идет полным ходом:) Прикупил 5 книжек кайфовых, которые разыграем в эфире!)

Напомню, что стрим будет:
29 июня в 19мск, а в 20мск уже можно будет купить курс:) Но стримить то мы на этом не прекратим, нам еще яйцо кощея разыгрывать😂

Норм книги выбрал?)

Сегодня выступаю на гошном митапе с докладом о типичных ошибках в гошке:) Много кота и крутых анимаций обеспечено😂

В 19:00 мск подключайтесь! Я там и на вопросы поотвечаю:)

https://www.youtube.com/live/SJHRxVxNLPg?si=p7hAN7Gjh4-67i2n

Что такое OKR и зачем они нужны?

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

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

Важный дядька из бизнеса обращается к тебе и спрашивает:

- Олег, а подскажи пожалуйста, как разработка картофельной пушки улучшит наш продукт? Мы ж бл*ть банк!

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

- Все верно, мы банк! У нас есть коллекторы, которым нужно, чем пугать должников. Наша картофельная пушка идеально впишется в это направление.

Как правило, OKRы описывают не 100% работы на квартал, а только основную часть. Остатки уходят на форс-мажоры, тех. долг и всё такое.

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

🌭если юзаете OKR у себя на работе

P.S. На фото я пошел на завод окр планировать 😂

ТИПИЧНЫЕ ОШИБКИ В GOLANG

Ты пишешь на golang и до сих пор делаешь это? Да сколько можно, пора уже отучить себя от этих пороков! Смотри этот видос и узнаешь как делать в golang не стоит и почему. После видоса преисполнишься мудрости и сможешь пойти выпендриваться перед корешами.

А на какую из этих ошибок ты сам нарывался в работе?

Доп. материалы: https://t.me/olezhek28go/1308

СМОТРЕТЬ ВИДОС

Как подружить сервисы друг с другом?

Инженеры по всему миру навыдумывали всяких технологий, что башка кругом идёт, когда пытаешься во всём этом многообразии разобраться. Надо тебе намутить общение между сервисами - так одни говорят REST API юзай, другие крутят пальцем у виска и втюхивают свой gRPC, а кто-то сидит в уголке и натирает до блеска малоизвестный GraphQL. Ну и кого слушать?

Чаще всего технологии появляются, чтобы решить какую-то проблему, которую другие технологии или не решают, или решают фигово. Осталось понять, когда какую технологию применять, и будет нам счастье. Сейчас глянем на примерах, когда лучше юзать REST, когда gRPC, а когда и GraphQL можно расчехлить.

1. REST
Это как швейцарский нож в мире API. Он идеально подходит, когда вам нужно общаться с фронтендом. REST работает через HTTP/1.1, и браузеры отлично поддерживают этот протокол. JSON, который чаще всего используется в REST, легко обрабатывается на фронте, да и все к нему привыкли.

Есть у тебя магаз, где ты свои огурцы с кабачками продаешь. Заходишь ты на сайт магаза, и фронтенд запрашивает информацию о товарах с бэкенда. REST здесь нормас так ляжет. Ещё ж кайфово, если ребятки rest full поддержат, чисто по http методам будет ясно что делает та или иная ручка. Видишь patch метод и сразу всё ясно про это ваше обновление.

Несмотря на то, что JSON не самый лёгкий по весу формат и HTTP/1.1 не самый быстрый протокол, REST остаётся удобным и универсальным решением для большинства веб-приложений.

2. gRPC
А вот если ты вписался в мир микросервисов, то я тебе конечно соболезную, но надо как-то с этим жить. Запрос идёт с фронтенда, и чтобы собрать ответ, нам надо слазать в пяток микросервисов. Скорость тут уже начинает ролять сильнее. Надо мутить быстрый и эффективный способ обмениваться данными.

Тут-то и выходит на авансцену gRPC. Во-первых, он работает через HTTP/2, что уже делает его быстрее, так как умные ребята серьезно потюнили этот протокол с версии 1.1. Во-вторых, gRPC использует бинарный формат данных Protobuf, что уменьшает размер передаваемой информации. А коль сообщенька весит меньше, значит и летит по сети быстрее.

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

3. GraphQL
Решил ты сделать магаз с кучей фильтров, где можно по-всякому вертеть, какие данные отображать при поиске, а какие нет. Не будешь же ты каждый раз получать с бекенда все данные, а фильтровать их уже на фронте. Это шляпа какая-то, которая забьет тебе сеть. Надо быть хитрее и запрашивать только то, что действительно нужно.

GraphQL — это как SQL для API: вместо того, чтобы получать фиксированный набор данных, как принято в контрактах REST или gRPC, ты можешь запросить ровно то, что нужно. Это снижает нагрузку на сеть и ускоряет загрузку данных, особенно когда речь идёт о сложных и динамичных запросах.

Итого
REST — проверенный годами варик, особенно для взаимодействия между фронтендом и бэкендом. gRPC идеально подходит для быстрого и эффективного взаимодействия между микросервисами, когда важна производительность. GraphQL даёт максимальную гибкость в запросах данных, позволяя получать только то, что нужно, и оптимизируя взаимодействие между клиентом и сервером. Короче, как обычно всё зависит от контекста. Так что вникай в контекст и включай голову. Опять думать придётся(((

🔥 - мне REST больше всего по душе
🌭 - gRPC one love
🍌 - юзаю graphQL и не стесняюсь этого!

Твой опыт не влияет на зарплату

Очень часто я слышу о том, что люди в поте лица задротят алгоритмы и другие hard скилы. Они думают, что чем больше они шарят в технологиях, тем выше их ЗПшка.

Эту мантру говорят джунам, которые хотят залететь в айти. Позадроть литкод пару лет, сделай 4 pet-проекта, пройди 3 бесплатных стажировки. И только после этого ты имеешь морально право искать работу.

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

Всё это сказки, которые рассказывают те, кому выгодно сэкономить на нас деньги!

Конечно, хочется просто писать код и не вникать в социальные процессы, НО реальность диктует иные правила. Если желаешь расти по бабкам и находить интересные проекты, выход один - нужно постоянно мониторить рынок и ходить по собесам.

Думаешь сидеть в одной компании и старательно делать таски? Итог один - получишь прибавку процентов 10 за год, даже если поразишь всех на performance review. На собесах же ты имеешь шанс кратно увеличить свой доход за выполнение тех же задач.

Так было и у меня, когда я переходил в Озон, и когда из него уходил. Правда мой путь до оферов не был столь прост, как в этих строках. Я проваливал собесы, нервничал из-за неопределенности, офигевал от странных задач, и, конечно, тупил на торгах за зарплату.

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

А какие у вас провалы бывали на собесах?