У меня есть приложение, работающее с:
- один экземпляр nginx в качестве интерфейса (обслуживающий статический файл)
- кластер приложений node.js для бэкэнда (с использованием модулей cluster и expressjs)
- один экземпляр Postgres в качестве БД
Достаточно ли этой архитектуры, если приложению требуется масштабируемость (это касается только HTTP/REST-запросов) для:
500 запросов в секунду (каждый запрос только извлекает данные из базы данных, эти данные могут быть размером в несколько тысяч, и после извлечения не требуется больших вычислений).
20000 пользователей подключены одновременно
Где могут быть узкие места?
решение1
Один экземпляр nginx может обрабатывать тысячи небольших статических файлов в секунду, не прилагая особых усилий.
Масштабируемость уровня приложения зависит от вашего приложения больше, чем от node.js — если оно хранит файлы/данные сеанса и т. д. локально, все может быть сложно, но если вы размещаете все хранилище в централизованном месте, например, в базе данных (или, может быть, в чем-то вроде Redis для хранения данных сеанса), то масштабирование уровня приложения путем добавления дополнительных узлов должно быть простым.
Базу данных почти всегда сложнее всего масштабировать; если вы в основном занимаетесь чтением, то в Postgres 9.1 есть несколько действительно хороших функций горячего резерва, которые позволяют вам иметь одну главную базу данных для чтения/записи и несколько подчиненных баз данных только для чтения, которые могут обрабатывать большую часть работы по чтению.
Развитие системы баз данных с большим объемом записи, вероятно, является самой сложной проблемой масштабируемости; когда один супермощный сервер баз данных не справляется, большинство людей в конечном итоге полностью переосмысливают и переписывают свои приложения (если только это не было запланировано с самого начала, но планирование нескольких основных баз данных усложнит и замедлит многие вещи поначалу, и это требуется очень редко — вся сеть StackOverflow основана на одной базе данных IIRC)