Как запустить сайт с высоким потенциалом будущего роста. [закрыто]
Я надеюсь, что у меня простой вопрос. Поскольку я уверен, что шаги по настройке этого сложны, я хотел бы знать несколько вещей. У нас есть команда, которая работает над отличной платформой, которая уже почти готова к завершению. Мы разрабатывали на стандартной ламповой установке, ничего особенного. Проблема, с которой мы столкнулись при работе над схемой, заключается в том, как планировать рост конфигурации лампы. Легко просто купить сервер и загрузить на него приложение, но как нам спланировать, когда нам понадобится 3, 4, 5 серверов и продолжать наращивать эту схему, не ломая сайт и не выводя его из строя каждый раз? По сути, простоев нужно избегать. Мы предпочитаем приобрести собственные серверы и обслуживать их самостоятельно с совместным размещением.
По существу, как нам настроить сайт так, чтобы с самого начала он был создан для параллелизма (я думаю, это то самое слово?).
Надеюсь, у меня есть то, что прямой вопрос.
Извините, но это почти полная противоположность. Масштабируемость - это большой набор дизайнерских решений, которые необходимо реализовать с самого начала, если вы хотите, чтобы это было очень просто. Как правило, это требует много дополнительной работы, и если вы никогда раньше не создавали такую систему, ее обычно легче выучить с помощью «болезней роста».
Наш общий стандартный ответ на эти вопросы: займитесь масштабируемостью позже. Создайте свой сайт / приложение / что угодно и добавьте к нему более мощный сервер, насколько это возможно. Когда эта опция закончится, начните беспокоиться о том, как вы разделите логические слои (что обычно является самым простым), например, интерфейсный веб-сервер с сервера базы данных. Затем выясните, как запускать два веб-сервера одновременно и т. Д.
Основная проблема заключается в том, что, хотя я могу отказаться от своей руки и сказать «сегментирование базы данных» или «активно-активные кластеры», фактическая реализация это будет во многом зависеть от того, как ваше приложение работает внутри. LAMP даже не очень "стандартный" - я предполагаю, что вы имеете в виду PHP или Perl, ни один из которых не работает хорошо с параллелизмом из коробки (и, вероятно, будет одним из первых узких мест, с которыми вы столкнетесь; по крайней мере, они распространены проблемы, и есть много статей о том, как с этим бороться).
Обновление:
Основная часть проблемы заключается в том, что, хотя я могу отказаться от своей руки и сказать «сегментирование базы данных» или «активно-активные кластеры», их фактическая реализация будет во многом зависеть от того, как ваше приложение работает внутри. LAMP даже не очень "стандартный" - я предполагаю, что вы имеете в виду PHP или Perl, ни один из которых не работает хорошо с параллелизмом из коробки (и, вероятно, будет одним из первых узких мест, с которыми вы столкнетесь; по крайней мере, они распространены проблемы, и есть много статей о том, как с этим бороться).
Обновление:
Основная проблема заключается в том, что, хотя я могу отказаться от своей руки и сказать «сегментирование базы данных» или «активно-активные кластеры», их реальная реализация будет во многом зависеть от того, как ваше приложение работает внутри. LAMP даже не очень "стандартный" - я полагаю, вы имеете в виду PHP или Perl, ни один из которых не работает хорошо с параллелизмом из коробки (и, вероятно, будет одним из первых узких мест, с которыми вы будете иметь дело; по крайней мере, они распространены проблемы, и есть много статей о том, как с этим бороться).
Обновление: У меня возникли проблемы с поиском краткого изложения тем о масштабируемости. Я наткнулся на это:
- Приложение без сохранения состояния
- Слабая связь
- Асинхронность
- Ленивая загрузка
- Кэширование
- Параллелизм
- Разделение
- Маршрутизация
Аналогичная схема из другого источника :
- Разделение проблем (представление, логика / приложение, данные, транзит / маршрутизация, управление)
- Минимизация распределения состояний (т. Е. Состояние не пересекает вышеупомянутое разделение)
- Избыточность
- Раздельные среды (Dev, QA, Stage, Prod)
- Сборка
- Автоматизация (создание сценариев, сборка, управление и т. Д.)
- Управление конфигурацией
- Центральное управление идентификацией
- Управление развертыванием
- Выполнить
- Монитор
- Переоценка емкости, план
- Журналы, журналы, журналы
- Цикл непрерывного улучшения (Agile Dev в высшей степени)
Я мог бы написать книгу, выделив каждую из тем в первом списке в индивидуальные технологии. Для каждого из них может быть написана книга о реализации на различных платформах, различных моделях и многом другом (у многих уже есть книги о них).
Если кто-то хочет добавить что-то еще или добавить детали, не стесняйтесь.