Всем привет. Про API GW и зачем он нужен проговорили выше. Также обсудили основные паттерны API GW.
Отдельно проговорили про NGINX. У него ещё есть функция балансировки.
Вот тут возникает вопрос: что будем балансировать и зачем? Если с акробатами и балансировкой всё понятно, то тут, мне кажется, стоит обсудить подробнее.
Начнём слегка издалека.
Вспомним про масштабирование. Часто раньше спрашивали, что такое горизонтальное и что такое вертикальное масштабирование на собеседованиях.
Напомню: вертикальное масштабирование — это когда добавляются ресурсы имеющемуся серверу (ядра, память); горизонтальное масштабирование — это добавление количества экземпляров.
Например, вместо одного микросервиса B2C у вас будет три таких экземпляра. И вместо 1000 запросов в секунду можно будет на B2C отправлять 3000 запросов в секунду, но главное — на разные экземпляры.
Кто будет определять, куда отправлять запрос?
Вот так и подошли к балансировщику, который по какому-то заданному алгоритму распределит запросы.
При этом есть разные варианты, кто будет выполнять балансировку.
Может после API GW стоять отдельно балансировщик = Load Balancer (или встроенный механизм балансировки Kubernetes), может быть общий компонент, который выполняет функции API GW и LB. Всё зависит от конкретных решений, которые выбрали в той или иной организации при проектировании архитектуры.
Варианты алгоритмов, по которым LB может распределять трафик:
Статические алгоритмы
Балансировщик распределяет трафик согласно заданным правилам.
Round Robin
Распределяем просто по очереди:
1-й запрос → server1
2-й запрос → server2
3-й запрос → server3
Weighted Round Robin
Например:
server1 — вес 5
server2 — вес 3
server3 — вес 2
Тогда server1 получит 50% трафика, server2 — 30%, server3 — 20%.
IP Hash
По IP пользователя считаем хеш и направляем запросы на один и тот же сервер. Это позволяет сохранять привязку клиента к серверу, но при изменении набора серверов распределение может измениться.
Динамические алгоритмы
LB следит за актуальной нагрузкой на серверы и принимает решения на основе этой информации.
Least Connections
Отправляем туда, где сейчас меньше всего активных соединений.
Weighted Least Connections
Учитывается и вес сервера, и количество активных соединений.
Подходит при неравномерной нагрузке и разной производительности серверов.
Least Response Time
Отправляем туда, где сервер отвечает быстрее всего (на основе измерений response time).
Если говорить про System Design интервью, то обычно балансировщик отдельно не рисуют. Можно проговорить, что нарисованные API GW и LB находятся в одном квадрате и назвать его адаптер или коннектор.
Были у вас кейсы с балансировкой?
Да —👍
Нет —🙈
Полезно -🦅
Отдельно проговорили про NGINX. У него ещё есть функция балансировки.
Вот тут возникает вопрос: что будем балансировать и зачем? Если с акробатами и балансировкой всё понятно, то тут, мне кажется, стоит обсудить подробнее.
Начнём слегка издалека.
Вспомним про масштабирование. Часто раньше спрашивали, что такое горизонтальное и что такое вертикальное масштабирование на собеседованиях.
Напомню: вертикальное масштабирование — это когда добавляются ресурсы имеющемуся серверу (ядра, память); горизонтальное масштабирование — это добавление количества экземпляров.
Например, вместо одного микросервиса B2C у вас будет три таких экземпляра. И вместо 1000 запросов в секунду можно будет на B2C отправлять 3000 запросов в секунду, но главное — на разные экземпляры.
Кто будет определять, куда отправлять запрос?
Вот так и подошли к балансировщику, который по какому-то заданному алгоритму распределит запросы.
При этом есть разные варианты, кто будет выполнять балансировку.
Может после API GW стоять отдельно балансировщик = Load Balancer (или встроенный механизм балансировки Kubernetes), может быть общий компонент, который выполняет функции API GW и LB. Всё зависит от конкретных решений, которые выбрали в той или иной организации при проектировании архитектуры.
Варианты алгоритмов, по которым LB может распределять трафик:
Статические алгоритмы
Балансировщик распределяет трафик согласно заданным правилам.
Round Robin
Распределяем просто по очереди:
1-й запрос → server1
2-й запрос → server2
3-й запрос → server3
Weighted Round Robin
Например:
server1 — вес 5
server2 — вес 3
server3 — вес 2
Тогда server1 получит 50% трафика, server2 — 30%, server3 — 20%.
IP Hash
По IP пользователя считаем хеш и направляем запросы на один и тот же сервер. Это позволяет сохранять привязку клиента к серверу, но при изменении набора серверов распределение может измениться.
Динамические алгоритмы
LB следит за актуальной нагрузкой на серверы и принимает решения на основе этой информации.
Least Connections
Отправляем туда, где сейчас меньше всего активных соединений.
Weighted Least Connections
Учитывается и вес сервера, и количество активных соединений.
Подходит при неравномерной нагрузке и разной производительности серверов.
Least Response Time
Отправляем туда, где сервер отвечает быстрее всего (на основе измерений response time).
Если говорить про System Design интервью, то обычно балансировщик отдельно не рисуют. Можно проговорить, что нарисованные API GW и LB находятся в одном квадрате и назвать его адаптер или коннектор.
Были у вас кейсы с балансировкой?
Да —👍
Нет —🙈
Полезно -🦅