Написание многосерверного кода

Question

Я давно задумался; Как веб-сайты, такие как код Facebook, могут иметь несколько серверов?

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

Или веб-сервер, возможно, справляется с этим независимо от кода?

Answer 1

Делясь и общаясь. Код «должен» быть одинаковым для одного или нескольких серверов.

Вы можете обмениваться данными через Базы данных, память с такими вещами, как Memcache, нагрузка с балансировкой и т. Д. Если вы специализируете серверы, как это делает Google (некоторые выполняют выборку URL-адресов, некоторые удерживают данные, некоторые пересекают числа и т. Д.), Оборудование на руку можно лучше утилизировать.

Код может использовать логику диспетчеризации (обычно абстрагированную через API), чтобы он работал одинаково, если существует один сервер или миллионы из них.

IPC (межпроцессное взаимодействие) может быть включено по сети и обеспечивать более «тесное» соединение услуг. У Google даже есть проект буфер протокола , чтобы помочь с этим.

По сути, серверы должны делиться, чтобы получить какие-либо реальные преимущества (помимо аварийного переключения / резервного копирования), код должен использовать уровень абстракции, чтобы помочь с совместным использованием. Фактическое совместное использование обычно использует Round-Robin или Map / Reduce logic.

Answer 2

Базовым шаблоном архитектуры является «архитектура без общего доступа». Идея состоит в том, чтобы построить наиболее интенсивно используемые части архитектуры таким образом, чтобы она могла быть распределена, и чтобы распределенные одноранговые узлы не должны были ничего знать о других одноранговых узлах, поэтому им не нужно общаться друг с другом. Таким образом, их можно масштабировать, добавляя других пиров.

Обычно для этого требуется некоторая маршрутизация трафика (балансировка нагрузки) для подачи общих компонентов и некоторая синхронизация состояния и / или состояния.

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

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