Я уже рассказывал о балансировщиках нагрузки и зачем они нужны, но вот вопрос: «а какие алгоритмы балансировки они юзают?».

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

1. Раунд-робин (Round Robin): Это как игра в "горячую картошку", только вместо картошки - запросы пользователей. Балансировщик по очереди передает запросы каждому серверу в группе. Чисто в тупую первый запрос к первому, второй ко второму и так по кругу.

2. Наименее соединений (Least Connections): Тут балансировщик нагрузки выбирает сервер, у которого меньше всего активных соединений и засылает на него трафик. Но тут может быть проблема в том, что соединения не равнозначные. Где-то 100 легких и серваку пофиг, а где-то и одно загрузит до сотки.

3. Источник IP (IP Hash): Каждый IP-адрес пользователя преобразуется в уникальный хэш, определяющий, к какому серверу будет направлен запрос. За счет этого мы можем мутить липкие сессии. То есть конкретный клиент привязан к конкретному серваку, пока адрес не сменил. Это может быть удобно, если есть какие-то локальные кэши, например.

4. Взвешенный (Weighted): Разные серверы могут обрабатывать разное количество запросов в зависимости от их мощности. Например, у одного 10 гигов оперативы, а у второго 40 гигов. Стало быть и трафик будет распределяться 1 к 4, то есть первому 20%, а второму 80%.

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

P.S. У меня с английским не очень, поэтому когда я первый раз увидал название раунд робин я подумал, что его какой-то Робин придумал 😂

А вы так не кринжевали и сразу знали, что Робин это Бетмен на минималках, а не автор алгоритма?)

Есть у меня подружая из Озона. Её зовут Маша и она работает в самом высоконагруженном сервисе маркетплейса. Там от RPS волосы дыбом, а она кэшами всё обкладывает🔥

https://youtu.be/5fTgseLQ0Rc?si=VlL1xR9IgD9fAIWU

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

Как департамент утилизации CPU превратился в департамент экономии железа, выдерживающий нагрузку в 1 млн RPS

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

Уже сегодня в 18:00(МСК) проведу открытый урок по теме "Микросервисная архитектура, как в BigTech".

Открытый урок пройдёт тут: https://youtube.com/live/TbveBv880PM

А если интересно узнать подробности, то залетайте на ЛЕНДИНГ УРОКА Там сможете найти поинты, которые мы разберём сегодня и отзывы на предыдущие уроки. А пока ещё есть время глянуть парочку предыдущих уроков.

* gRPC в Golang: Практическое Введение в Основы
* Чистая архитектура проекта на Golang

Через полчаса начнем:)

Мы начинаем, подключайтесь!
https://youtube.com/live/TbveBv880PM

Как и обещал, держите список материалов на почитать:

• Ричардсон К. - Микросервисы. Паттерны разработки и рефакторинга
• Microservice Architecture (отличный сайт)
• Martin Fowler - Статьи о микросервисах
• Martin Fowler - How to break a Monolith into Microservices
• Хононов В. - Изучаем DDD – предметно-ориентированное проектирование
• Microservices Observability: How, when, and what to measure?
• Understanding Microservice Pipelines
• Pattern: API Gateway / Backends for Frontends
• API Gateway vs. Reverse Proxy
• Service Discovery in Microservices
• Одна платформа, чтобы править всеми (опыт Ozon Tech)
• Implementing the SAGA Pattern in Microservices
• SAGA vs 2PC: An Exhaustive Exploration of Distributed Transaction Protocols
• Difference between SAGA Pattern and 2 Phase Commit in Microservices?
• Eventual consistency consequences in the event-driven system
• What is a Service Mesh?
• Проект «Феникс». Роман о том, как DevOps меняет бизнес к лучшему (кайфовый бизнес-роман)


Телега кота - https://t.me/kot_kotkins

Микросервисная архитектура, как в BigTech (микросервисы vs монолит)

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

Сайт курса по микросервисам - ПЕРЕЙТИ
Маркетинг маркетингом, но на тариф с проверкой реально всего одно место осталось. Я даже офигел, как так разобрали. Больше 20 человек не возьму, а то с ума сойду от ревью😁

В этом уроке ты:
- с нуля разберешься в монолитной и микросервисной архитектуре приложения;
- узнаешь, в чём разница между монолитом и микросервисами, их сильные и слабые стороны;
- поймешь, нужны ли в твоем проекте микросервисы и какие паттерны используют BigTech-компании.

P.S. Кот передает привет и благодарит за тёплые слова в его адрес❤️

СМОТРЕТЬ УРОК

Всё! Места на тариф с проверкой кончились:) Теперь только если без проверки залетать)

Предлагаю завтра вечерком собраться и пообщаться в уютной атмосфере тут:)

Сможем обсудить микросервисы. Может кто-то посмотрел урок в записи и вопросы появились. Расскажу как на курсе дела и на вопросы поотвечаю про него. Ну и как обычно просто за жизнь тоже поболтаем:)

Трансляция будет завтра, 5 февраля в 18:30мск, в канале «уютный микросервис»

Я как настоящий сеньор катнул в прод и зафакапил😢
Вчера главное такой говорю вам места на тариф с проверкой кончились и я выключил кнопку на нём, а сегодня утром смотрю кто-то купил. Сперва понять не мог как так вышло, а потом как дошло.

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

В целом конечно 1 человек это не страшно, я смогу всё как надо проверить, но там ещё висит 7 заказов в статусе ожидания. И вот если они ещё апрувнуться, то всё пойдёт совсем не по плану. Я лимиты то эти не случайно поставил, а ориентируясь на свои возможности по ревью, чтоб качество не просело.

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

По шкале от 1 до 10 насколько я факапнул, как думаете?

Трансляция началась) Это пост для вопросов и общения) пишите в комменты

Зачем нужны бекапы базы данных?

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

В итоге какой-то корнер кейс я не учёл и часть данных перетерлась какой-то фигней. И тут такое состояние наступает, что ты немножко начинаешь сомневатся в реальности. Ну не может же так быть, чтоб ты дропнул реальные данные, без которых нифига не работает. Чуть позже паника отпустила и я вспомнил про бекапы. Часик хлопот и данные восстановлены к прежнему состоянию)

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

Юзали бекапы или судьба была благосклонна к вашим муткам на проде?))

Микросервисы зло!

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

Например, сегодня мне нужно было протестировать одну новую фичу, которую я пару недель делал. Она затрагивает 4 сервиса. Сперва я всё проверил локально, развернув все сервисы на ноуте. Это было непросто, так как повылезала куча проблем интеграций сервисов.

Затем катнул все на стейдж и тут пошло веселье с инфрой, особенностями нашего продукта и того, как интересно трафик летает между сервисами. Короче говоря, задолбался я за сегодня изрядно😂 И ведь еще не до конца все удалось проверить)

Был бы монолит, ща бы уже шампанское открывал и таску в done переводил:) Но микросервисы как не крути от других бед спасают)

Как у вас денек?:)

Что мне ваши тесты, я код в прод качу!

Работал я как-то в конторе, где тесты не писались вообще и тестировщиков конечно тоже не было. Я по правде говоря и узнал то о тестах не в первый год работы в айти из-за этого😂 Мы просто тыкали руками типичные сценарии использования софта и ясное дело регулярно что-то упускали. Я тогда еще и не знал, что можно как-то иначе делать)

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

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

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

Тесты, как вы поняли, штука важная, поэтому на моем курсе мы им также уделяем внимание:) Видали как нативненько интегрировал😂

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

Сайт курса по микросервисам - ПЕРЕЙТИ


А какой вас процент покрытия тестами в сервисах?:)