Вопрос архитектуры коммерческого сайта

Question

Я должен написать пример архитектуры, но есть некоторые вещи, которые я не знаю, поэтому я хотел бы добавить несколько указателей на следующее:

Сайт должен обрабатывать 5 тысяч пользователей одновременно. Бэкэнд состоит из коммерческого программного обеспечения, некоторых веб-сервисов, некоторых очередей сообщений и базы данных.

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

Я также хочу порекомендовать калитку для фронта (не в этом суть).

Чего я не знаю, так это: должен ли я установить переднюю и заднюю часть на один и тот же сервер Tomcat или два разных? и я испытываю желание поставить два сервера для фронта, с балансировщиком нагрузки (нет необходимости для репликации сеанса в этом случае). Но если у меня есть два передних сервера, должен ли я иметь два задних сервера? я не хочу создавать какое-то узкое место.

Исходя из того, что я прочитал в этом блоге , действительно огромная плата взимается одним котом только за первый упомянутый сайт. Но я не могу найти какую-либо информацию по этому поводу, поэтому я не могу сказать, кажется ли это правдоподобным.

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

Спасибо:)

Answer 1

Вероятно, есть две основные причины наличия нескольких серверов для каждого уровня; высокая доступность и производительность. Если вы не делаете этого по причинам HA, то неудачный ответ - «это зависит».

Наличие двух серверов переднего плана не заставляет вас иметь два сервера. Будет ли бэкэнд находиться под достаточно высокой нагрузкой, что потребует двух серверов? Это будет во многом зависеть от того, что он делает, и лучше всего будет раскрыто при нагрузочном тестировании и / или профилировании. Для сайта, который одновременно обрабатывает 5000 пользователей, я думаю, что да ...

Answer 2

Это полностью зависит от вашего приложения. Насколько тяжелы ваши сеансы? (Калитка известна тем, что много вкладывает в сессию). Насколько тяжелы ваши бэкэнд-процессы.

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

Измерение - это лучшее, что вы можете сделать. Создайте сценарии JMeter и узнайте, где ломается ваше приложение. Построил план оттуда.

Answer 3

Чтобы расширить мой комментарий: продумайте типичный процесс, с помощью которого клиент делает запрос на ваш сервер:

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

Итак, при проектировании вашей архитектуры вам нужно подумать о таких вещах, как:

• сколько соединений вы можете одновременно держать открытыми на вашем сервере? если вы используете Tomcat или другой стандартный сервер с одним потоком на соединение, у вас могут возникнуть проблемы с 5000 одновременных потоков; (архитектура на основе NIO, с другой стороны, может обрабатывать тысячи соединений без необходимости использования одного потока на соединение); если вы находитесь в общей среде, вы можете просто не иметь столько открытых соединений;
• если клиенты не держат свои соединения открытыми в течение «сеанса», каков правильный баланс между количеством запросов и / или временем на соединение, учитывая накладные расходы на создание и закрытие соединения (инициализация зашифрованного сеанса, если это необходимо, сетевые издержки при создании соединения, порт "перегружен" на некоторое время после закрытия соединения)

Тогда, в более общем смысле, я бы сказал, рассмотрим:

• в какой бы архитектуре вы ни выбрали, как легко вы можете реструктурировать / заменить определенные компоненты, если они оказываются узкими местами?
• для каждого компонента / фреймворка «черного ящика», какую реальную проблему он решает для вас, и каковы его ограничения? (Не используйте Tomcat, потому что лучший друг вашего босса рассказал им об этом в пабе ...)

Я бы также согласился с тем, что сказали другие люди - в какой-то момент вам не нужно быть слишком теоретическим. Разработайте что-нибудь разумное, затем запустите тестовый стенд, чтобы увидеть, как он на самом деле справляется с вашими ожидаемыми объемами данных. (Возможно, у вас не полностью построено приложение, но вы можете начать делать прогнозы о том, что «у нас будет X клиентов, отправляющих Y запросов каждые Z минут, и p% этих запросов займет n миллисекунд и запишет r строк в базу данных »...)