Как запустить сайт с высоким потенциалом роста в будущем.

Я надеюсь, что у меня есть простой вопрос. Поскольку я уверен, что шаги по настройке этого сложны, я хотел бы знать несколько вещей. У нас есть команда, которая работает над великолепной платформой, которая почти готова к завершению. Мы разрабатывали на стандартной установке лампы ничего особенного. Проблема, с которой мы столкнулись в схеме, заключается в том, как спланировать рост для конфигурации лампы. Легко просто купить сервер и загрузить приложение на них, но как мы планируем, когда нам нужно 3, 4, 5 серверов и продолжать добавлять к этой схеме, не ломая сайт или не отключая его каждый раз? По существу, следует избегать простоев. Мы предпочитаем приобретать наши собственные серверы и обслуживать их самостоятельно в одном месте.

По сути, как нам настроить сайт так, чтобы с самого начала он был сделан для параллелизма (я полагаю, что это слово?).

Источник

1 ответ

Решение

Я надеюсь, что у меня есть простой вопрос.

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

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

Основная часть проблемы заключается в том, что, хотя я могу отказаться от своей руки и сказать "сегментирование базы данных" или "активно-активные кластеры", их фактическая реализация будет во многом зависеть от того, как ваше приложение работает внутри. LAMP даже не очень "стандартный" - я предполагаю, что вы имеете в виду PHP или Perl, ни один из которых не очень хорошо работает с параллелизмом из коробки (и, вероятно, будет одним из первых узких мест, с которыми вы столкнетесь; по крайней мере, это распространенные проблемы). проблем и есть много статей о том, как с этим бороться).

Обновление: у меня возникли проблемы с поиском краткого описания тем для масштабирования. Я столкнулся с этим:

  • Заявка без сохранения состояния
  • Слабая связь
  • асинхронность
  • Ленивая загрузка
  • Кэширование
  • параллелизм
  • Разметка
  • маршрутизация

Аналогичная схема из другого источника:

  • Разделение проблем (представление, логика / приложение, данные, транзит / маршрутизация, управление)
  • Минимизировать распределение государства (то есть государство не пересекает вышеупомянутое разделение)
  • избыточность
  • Отдельные среды (Dev, QA, Stage, Prod)
  • строить
    • Автоматизация (создание сценариев, сборка, управление и т. Д.)
    • Управление конфигурацией
    • Центральное управление идентификацией
    • Управление развертыванием
  • Бежать
    • монитор
    • Переоценка мощностей, план
    • Логи, Логи, Логи
    • Цикл непрерывного улучшения (Agile Dev на пределе)

Я мог бы написать книгу, разбивающую каждый из предметов в первом списке на отдельные технологии. У каждого из них может быть написана книга о реализации на различных платформах, разных моделях и т. Д. (У многих уже есть книги о них).

Если кто-то хочет добавить больше к этому или добавить детали, не стесняйтесь.

Источник
Другие вопросы по тегам