Масштабирование: разделение труда или избыточность? - PullRequest
Новая
       37

Масштабирование: разделение труда или избыточность?

0 голосов
/ 24 декабря 2009

Это то, о чем я всегда задумывался. Я понимаю, что горизонтальное масштабирование - это добавление большего количества машин в микс. Но я могу придумать два подхода к этому. Предположим, у меня есть 20 серверов, которые я хочу использовать (плюс база данных). Я могу:

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

Номер 1 кажется более распространенным и более простым для понимания, но номер 2, по-видимому, считается «наилучшей практикой» (поскольку в основном это n-уровневая архитектура). Как выбрать между этими двумя моделями? И каковы плюсы и минусы каждого подхода?

1 Ответ

1 голос
/ 24 декабря 2009

Это зависит от задачи и от того, какие у вас будут узкие места.

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

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

Однако выбор №2 лучше для большинства сайтов, особенно если вы заранее не знаете, какие серверы станут узкими местами. Если вы не разрешите масштабирование для каждого типа сервера, вам придется переписывать исходный код во время неожиданных скачков роста. Тогда вам придется принимать трудные решения, такие как «Какие функции мы должны отключить, чтобы сайт продолжал работать, пока мы работаем над масштабированием?»

Честно говоря, я бы не стал тратить слишком много времени на беспокойство о масштабируемости. Как только вы достигнете точки, когда нагрузка на ваш сервер станет слишком высокой, вы сможете позволить себе некоторые изменения в исходном коде. Либо через недавно обнаруженные источники финансирования, либо за счет прямой прибыли с сайта. Показательный пример: у Twitter все еще отлично.

...