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