Что входит к созданию веб-сайта, который должен масштабироваться?
Я планирую создать приложение, которое получит большой объем трафика. (Не говорите, что я не получу трафик, это для внутренней сети, таким образом, трафик будет там. Просто стараясь избегать 'Вы не получите так много трафика, не волнуйтесь об этом.)
Что касается какого трафика я ожидаю, пользователи просмотрят различный динамично созданный (на основе деталей учетной записи пользователя). На тех сайтах пользователь может отправить вводы текста. И загрузка страниц и обработка ввода данных пользователем поразят базу данных. Загрузки, очевидно, будут чтениями, но обработка входа потребует обоих чтений и записей. Исходные данные могут также влиять на другие пользовательские представления. Если это произойдет, то я должен буду уведомить других пользователей для обновления страницы.
Какие виды вещей я должен сделать так, чтобы это просто не отказывало при загрузке большого количества пользователей?
Что становится ограничивающими факторами? Материал базы данных? Ввод-вывод с фронтэндом?
Я действительно никогда не разрабатывал серьезное веб-приложение прежде, и ищу некоторую справку.
Править: Я рассматривал использование Erlang для бэкенда, так как я использовал его немного и действительно как весь материал параллелизма. Это было бы жизнеспособным выбором, или я должен попробовать за что-то более традиционное?
5 ответов
Это очень большая тема, и вы, вероятно, захотите провести столько исследований, сколько позволит время. Следует рассмотреть несколько важных тем.
Хранение состояния сеанса. Очевидно, что хранилище сеанса занимает память или дисковое пространство. У вас должна быть стратегия для правильного хранения информации о сеансе таким образом, чтобы ее могла использовать веб-ферма.
Кеширование. Надежная стратегия кэширования может значительно снизить нагрузку. Проведите много исследований о том, когда, что и где следует кэшировать.
Масштабируемость и нагрузочное тестирование. При каждой операции выборки ресурсов необходимо уделять особое внимание, чтобы убедиться, что она выполняется столько раз, сколько необходимо. Нагрузочное тестирование и профилирование кода могут помочь выявить здесь узкие места, если вы используете хорошие инструменты.
Оптимизация базы данных.Убедитесь, что вы понимаете, как правильно оптимизировать вашу базу данных для тысяч (миллионов?) Операций в минуту. Если ваше приложение требует большого количества операций записи, вам может потребоваться рассмотреть возможность хранения старых данных, которые больше не нужно включать в индексы, чтобы ускорить операции записи.
Путь обновления. Будет ли со временем расти ваш трафик? Убедитесь, что вы понимаете, как вы могли бы подключить больше серверов и памяти к своему приложению, если / когда это необходимо, и что для этого потребуется.
Есть много книг, в которые вы могли бы вложить деньги и которые, вероятно, окупились бы большими дивидендами. Выполните поиск по запросу «создание масштабируемых веб-приложений» на Amazon или в главах, и вы, вероятно, найдете множество текстов, как специфичных для технологий, так и независимых.
В дополнение ко всему, что здесь упоминалось, вы должны следить за временем вашего трафика. Является ли он относительно постоянным во времени? Или же это происходит пачками, при которых вы получите гораздо больший объем трафика за короткий период времени?
В общем, вы захотите разработать систему, которая может изящно справляться с пиковыми нагрузками (хотя и не обязательно на идеальном уровне производительности). Если ваш трафик очень нестабильный, вам придется приложить больше усилий для его масштабирования, чем если бы вы постепенно получали тот же объем трафика.
просто не делайте больше, чем вам нужно. если вы будете придерживаться этого, вы сможете справиться с большинством вещей, кроме эффектов метаблога.
Что касается Erlang: это звучит как приемлемо хороший язык (исходя из того немногое, что я о нем знаю), но это определенно не волшебная палочка, которая дает вам масштабируемость. Необходимо учитывать десятки различных факторов и продуктов. Выбор языка - лишь одна из них ... и, вероятно, одна из наименее значимых.
Возможно, вам будет лучше использовать то, что вы уже знаете, и научиться масштабировать его, чем переходить к новой / неизвестной технологии и надеяться, что она масштабируется для вас.
Внутреннее хранилище, работа с базой данных, внешнее динамическое содержимое и кэширование - это одно. Другое дело - учет провайдера услуг хостинга и доступной пропускной способности сети.
Уточните у хостинг-провайдера лимит пропускной способности, максимальное количество памяти, выделяемое на один запрос, максимальный размер загружаемых файлов и максимальное количество запросов к базе данных. Если ваш текущий хостер не предлагает дешевых услуг, соответствующих вашим требованиям к масштабированию, переходите к другому хостеру, пока вас не закрыли или не застали врасплох трехзначным ежемесячным счетом за превышение выделенной пропускной способности.
Edit: только что перечитал и уловил вашу ссылку на "внутреннюю сеть". Итак, в этом случае, вероятно, администратор сети не выставит вам счет на несколько сотен долларов, но он все равно может отключить вас. Обязательно держите открытыми линии связи с администраторами сети и администраторами любых других служб, с которыми взаимодействует ваш сайт, иначе вы быстро сделаете их врагами. Другими словами: хороший сетевой этикет.
Кроме того, если вы действительно владеете сервером и создаете его, убедитесь, что ОС, программный стек и аппаратное обеспечение поддерживают только стабильные версии ПО и прошивок, способны выдерживать нагрузку и постоянно контролируются для бесперебойной работы.
Edit #2: Я знаю, что вы спросили, как именно ваше приложение может справиться с нагрузкой, и, возможно, я просто разглагольствую не по теме, но вы также должны подумать, сможете ли вы и ваши товарищи по команде справиться с нагрузкой. Пропускная способность рабочей силы не менее важна, и если вы будете обескуражены рабочей нагрузкой, это будет причиной провала подобных проектов. Пиво - лучший друг программиста, особенно при решении сложных и творческих задач программирования, но оно может привести к серьезным проблемам с алкоголем при неправильном управлении рабочей силой или нехватке трудовых ресурсов. Кто ответит на уведомление об отключении в три часа ночи? Кто будет отвечать на письма ненависти от религиозных фундаменталистов или троллей, или рыться в законах и патентах, чтобы проверить, не является ли это уведомление об отключении фиктивным? Если только это не работа, которая может оплачивать счета, скорее всего, большинство людей не могут уделять ей много времени и энергии. Я вовсе не хочу отговаривать вас, и надеюсь, что вы уже разобрались с этим.