Pull to refresh

7 стадий развития веб-приложений

Lumber room
Translation
Original author: John Engates
это отредактированный перевод со слайдов презентации тов. John Engates
формат: номер слайда, краткое содержание и (мои редкие каменты)
  1. Этапы становления веб-ресурсов
    автор: John Engates
  2. Регламент:
    • Что мы ждём от веб-приложений
    • Как это бывает
    • Неплохие примеры
    • Вопросы и ответы

  3. Чего мы ждём от сайтов

    • Масштабируемость
    • Высокая отдача
    • Эффективность
    • Простота управления
    • Низкая стоимость (обслуживания, в том числе)
    • Изобилие рюшечек Богатый функционал
    • И что он будет нам делать бабло, много бабла!

    Это и есть семизначная мантра клиента-директора, думающего о заказе корпоративного сайта
  4. Высокая готовность. Определение:
    Высокая готовность (High Availability HA) — это такой подход к проектированию и реализации, который бы гарантировал известную степень уверенности в их (проектирования и разработки) непрерывности. Так-то!
    Как это выглядит на примерах:
    • ваш сайт всегда работает и доступен
    • юзеры счастливы
    • вы не теряете денег из-за технических простоев
    • (и это не увеличивает затраты на обслуживание сверх необходимого)
    Это была мантра техдира проекта
  5. Что на самом деле называется масштабируемостью
    Масштабируемость (расширяемость) — это ожидаемое свойство системы, которое показывает её возможность к росту доходов в приятной форме, или легко наращивать функционал по необходимости
    (Дядька загнул круто. Я реально запарился с переводом. Короче, масштабируемость — это способность системы к расширению и росту. Ну и увеличению доходности, да)
    Вариант от pika здесь

    Чем не выражается масштабируемость:
    • чисто наращиванием мощностей (2МГц -> 3МГц)
    • чем-то вроде операционных систем (Solaris vs Linux)
    • особенностью софтовых технологий (Java — Python — Rails)
    • особенностями платформ (Intel — AMD)
    • оптимизацией кода (10 строк против 1000, утверждает этот дядька, ничего не решает)
    • выбором технологии хранения (SAN vs NAS)как я и догадывался, это разные инфраструктуры хранения данных. см. каменты ниже

  6. большими красными буквами

    РАСШИРЯЕМОСТЬ И ПРОИЗВОДИТЕЛЬНОСТЬ — НЕ ОДНО И ТОЖЕ

  7. картинки с примерами
    красивые машинки, автомобильные развязки и писсуары
  8. картинки
  9. картинки
  10. картинки
  11. картинки
  12. картинки
  13. Истина первая:

    Ничто не может множится, если таковым не спроектировано.
    (Вариант: Ничто не может быть масштабным, если не спроектировано масштабируемым.)

  14. Истина вторая:

    Если что-либо было спроектировано как конструктор, может наращиваться без проблем.
    Вариант от pika: Даже если система спроектирована под масштабирование, все равно это будет больно.

  15. Очень интересная картинка «шкала боли» (игра слов с предыдущими пунктами scaling — scale, в адекватном переводе затруднился)
  16. Типовые сценарии развития

    Этап 1. Начало
    • Простая архитектура
      — файрвол и балансировщик
      — пара веб-серверов так и написано, не приврал
      — сервер БД
      — внутреннее хранилище

    • Невеликая сложность и проблемность, быстрая разработка, богато фич разного рода и всё быстро
    • Никакой избыточности (втч и в рабочей силе), низкая стоимость работ — прекрасный стартап!

  17. Этап второй, всё тоже самое, но чуть-чуть по-больше
    • Успешное ведение бизнеса — залог хороших отношений с законом
    • Добавим немного файрволов и балансировщиков
    • Добавим чуть больше веб-серверов для производительности
    • Устаканим схему БД и соптимизируем её с помощью DBA (консультанта)
    • Добавим баз
    • Переведём хранилище на SAN или DAS
    • Всё ещё просто, подходит для перспективных приложений

  18. Этап третий — Первые симптомы
    • Публичность
    • Устанавливается Squid или Vanish в режиме обратных прокси, или очень хороший балансировщик — для кеширования статичного контента
    • Добавляем ещё сколько-то веб-серверов (управление контентом уже доставляет немалый головняк)
    • Единственная БД не будет разделена когда-либо (раздельные операции чтения-записи имеются в виду — вся запись ведётся на единственный мастер сервер с несколькими вторичными серверами для чтения)
    • Может возникнуть необходимость чё-нить переписать в приложении

  19. Картинка «Расширяемость применительно к серверам баз данных»
  20. Этап четвёртый — Боли усиливаются
    • Кеширование на memcache
    • Репликация не работает для всего (единственная база для записи — много баз для записи — результат: репликация работает долго)
    • Приходит осознание необходимости разделения баз (конечно же, если ваша БД поддерживает этот механизм)
    • Приходит осознание распределённых хранилищ для контента
    • Необходимо серьёзное преобразование архитектуры приложения и базы (а разрабы могут не обладать подобным скилом)

  21. Этап пятый — Реально головняк!
    • Приходит м-р Паника и остаётся у вас жить.
      Разве мы не могли сделать всё это раньше? (Список этого:
      — Полное переосмысление приложения\бизнес-модели
      — И почему мы не запланировали расширяемость системы на момент принятия решений по архитектуре? )
    • Невозможность делимости как фичи приложения — что ещё мы можем использовать? (Варианты
      — Разделение основанное на географическом принципе, по фамилии, по userID, etc
      — Создание кластеров пользователей (пользовательская кластеризация)
    • Поведение приложения должно быть идентично на каждом пользовательском кластере
    • Использование стурктуры хешей или мастер-сервера БД для определения какого пользователя на какой кластер подключить

  22. Этап шестой — Приход, мал-мала полегчало
    • Расширяемая архитектура приложения и базы
    • Удовлетворительное быстродействие
    • Снова можно добавлять новую функциональность
    • Оптимизация чего-нибудь в коде
    • Продолжаем расти, но теперь вполне управляемо

  23. Этап седьмой — Исход в неизвестность
    • Где нас ещё поджидают узкие места?
      — Обеспечение питанием, площадь размещения
      — Каналы и прочее — насколько велик ваш хостер?
      — Проблемы систем защиты и балансировщиков нагрузки
      — Хранилища данных
      — Люди и проблемы
      — Технологические ограничения расширяемости баз данных — всё ещё хотите хранить данные по схеме ключ-значение?
    • Что там насчёт «все яйца в одну корзину»?
      — один датацентер
      — одна копия данных
      — проблемы репликации данных и балансировки по географичекому принципу

  24. Добрые советы
    • Не изобретайте колесо, скопируйте у кого-нибудь другого
    • Думайте просто
      — Все вещи, сделанные проще некуда — не так уж просты. — А. Эйнштейн
    • Думайте горизонтально… не вертикально… в любых случаях (может, это идиома какая?)Насколько затратно? — вместо — Насколько быстро?
    • Используйте подходящее обеспечение и оборудование
    • Решайте проблемы легко и просто
      — Приводите планы в действие
      — Разделяйте различные сервисы
      — Не проводите много изменений за один раз (это называется итеративность)
  25. Ещё немного добрых советов
    • Не тратьте времени на оптимизацию оптимизации («Преждевременная оптимизация преждевременна» ©#phpclub@undernet.org)
      — Возьмите вашу [правильно спроектированную] архитектуру, часто подстраивайте решения [под неё], и редко оптимизируйте (или никогда)
    • Проверяйте возможности к расширению подходящими нагрузочными тестами
      — Сделайте это привычной практикой до того, как вы начнёте думать об их необходимости
    • Используйте кеширование до того, как почуствуется необходимость
    • Много памяти и 64-битная платформа помогут вам (Use the Force, Luck! :)
    • Проверяйте новые возможности до того, как выбор между производительностью и масштабируемостью станет проблемой
      — Nice to have vs. have to have. И будет вам щасте:)

  26. Изменения и доступность сервиса
    • Нельзя недооценивать необходимость правильной постановки технологического процесса и документирования
    • Управляйте релизами!
      — Разработка — тестирование — выпуск
      — Наличие методик проведения этих действий
    • Используйте системы контроля версий
      — Понятно, да: RCS, CVS, Subversion
    • Отслеживайте выпуски (короче, issue tracking — добрый совет использовать трекинговую систему. имхо помощь в разработке оказывают специализированные системы багтрекинга, а не хлам типа trac — у него другие задачи. Если и использовать систему контроля, то это должен быть комбайн, в котором прозрачно отслеживаются таймлайны, что-то типа eGroupWare. этот совет дополняет предыдущий)
    • Используйте стандарты кодирования
    • Управляйте изменениями
      — Планирование — тестирование — реализация
      — Это критично для инфраструктуры с высокой готовностью (HA)
Дальше там реклама и спасибы.
конец

первый перевод здесь
переводил, т.к. тема интересна; оказалось более 1000слов, более 7500знаков. могу сделать статью, и продать! :) если найдутся покупатели. ничего особенно нового не узнал. надеюсь, кому-нибудь окажется полезным
Tags:переводыархитектура веб-системмасштабируемостьрасширяемостьпроизводительностья пиарюсьтиповые решениясвой луна-парк
Hubs: Lumber room
Total votes 8: ↑6 and ↓2+4
Views648

Popular right now

Top of the last 24 hours