[Дизайн системы] Горизонтальное масштабирование — В двух словах (с примером кода ООП)

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

Рассмотрим систему, описанную в разделе Вертикальное масштабирование.

Мы собираемся масштабировать ту же систему по горизонтали. Но перед этим давайте разберемся, зачем это нужно?

Вертикальное масштабирование помогло нам масштабировать систему с меньшими усилиями и меньшими затратами.

Но проблема вот в чем,

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

Итак, Системе нужны дополнительные рабочие руки, которые будут работать, если что-то пойдет не так.

Теперь вернемся к проблеме. Ниже приведены фрагменты кода существующей системы.

Клиент: Код

Сервер: code

Теперь мощность сервера достаточно высока, чтобы обрабатывать максимум 5 тысяч запросов.

Чтобы масштабировать систему по горизонтали,

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

и фрагмент кода для серверной базы будет выглядеть

Теперь нам нужны какие-то алгоритмы распределения, которые Server Base может использовать для маршрутизации запросов между серверами.

Возможные проектные решения для распределения запросов (аналогично выделению памяти операционной системой)

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

Недостаток:

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

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

Недостаток:

1. Увеличение времени отклика по-прежнему является проблемой, поскольку серверная база должна найти следующий активный сервер и направить запрос.
2. Использование системы также увеличивается, но не до 100.

Нам нужно использовать какой-то алгоритм для согласованной маршрутизации запросов между серверами, что уменьшит время отклика и максимизирует использование.

Балансировщик нагрузки используется для таких случаев использования, которые внутренне используют согласованное хеширование.

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

Полный код Базы Серверов

Преимущества горизонтального масштабирования:

1. Проще запустить отказоустойчивость
2. Легко обновить
3. Infinite Scale может использовать бесконечное количество экземпляров для обеспечения безграничного роста

Недостатки горизонтального масштабирования:

1. Архитектурный проект очень сложен
2. Высокие коммунальные расходы, такие как (охлаждение и электроэнергия)
3. Увеличенная площадь и влияние на центр обработки данных
4. Требуется дополнительное сетевое оборудование, такое как маршрутизаторы и коммутаторы.

Источник кода: